LXQt 0.17 Released For This Lightweight Qt5 Desktop

[oiaohm]

And I'm usually not one to bet on a career ending horse (still standing though).

The reality is the end with open source software normally comes while the software is still working for users then 3-5 years latter when the software starts disappearing out of distributions.

I don't think I will ever feel at ease with some design choices or that fake smoothness of Mutter under wayland.

Horrible reality its not fake smoothness. There are lack of smoothness bugs with Mutter that don't show up with other Wayland compositors. Yes they are bugs.

https://gitlab.gnome.org/GNOME/mutter/-/issues/1455#note_929197

Different bugs with Mutter having been finding different smoothness problems under wayland and they are getting fixed. Please note how the person has tested there with KDE on wayland vs KDE on X11 vs Mutter on X11 and Mutter on Wayland yes some of Mutter issues are Mutter issues that don't effect KDE or Sway or Weston or any other Wayland compositor. Some of the problem is the old legacy X11 code in Mutter having hacks around so it can be used with Wayland. KDE Scenes work will have to come to Mutter at some point where they are getting properly rid of the X11 way of doing things.

Attempting to have generic code between X11 and Wayland with X11 Windows manager and Wayland Compositor ends up with problems.

There is a change in feel you will have to get use to you use sway or mutter or any other wayland compositor you do have to get use that they general make higher usage of the GPU so are less effected by system load and more effected by GPU load. Notice something here old school x11 server uses more CPU and less GPU so the balance has moved. So the user response feedback to system load has changed in the bugless Wayland implementations vs bugless X11 implementation this is purely because of having less cpu operations between input to user application and graphics from application to screen in the Wayland solution.

Remember using DMA BUF with Wayland going forwards (heck even the eglstreams option) means applications are using buffers in the format GPU expects under X11 you have the horrible X PixMap (XPM) and options like it that don't match the GPU at all so causes a lot of CPU processing. There is a need to end X11 because there is a lot of things in the protocol that were put in X11 protocol that seams like a good idea at the time that are absolute bad ideas.

[oiaohm]

But, yeah, KDE and XFCE have been pretty good about allowing the Window Manager to be swapped out and I'm gonna miss being able to mix and match components from desktops environments since I doubt that Wayland will allow it.

Some parts will be able to be swapped with Wayland compositors it is going to depend on the compositor. But the reality like with IceWM under X11 they did not allow all the parts they could to be swapped either.

https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/28

The sway/wlroots developer is pushing to add extension to Wayland to allow mix and match components back for Wayland compositors that want to support that. Yes the compositor will be able to advertise what parts it allows to be replaced this way. This should prevent some of the nightmares you would end up with X11 at times where two things would attempt todo the same feature at the same time and absolutely screw it up.

Yes this is really like history of X11 development all over again. First version of X11 you only had the absolute garbage Windows manager in the X11 server then extensions grew to allow mix and match. The extensions to wayland are being slow to-do because there are lot of experienced X11 people around who know how the X11 implement ion goes wrong and are demanding the Wayland way of doing the same feature does not have the same faults.

[birdie]

For a few years my setup of choice was XFCE+KWin. XFCE had a nice desktop environment; KWin whoops XFWM's ass. For shits and giggles also I've ran KDE+XFWM -- I don't suggest that one. KDE/XFCE with Flux/Openbox is always fun to tinker with since, IMHO, the problem* of the WM-Boxes is the having to piece together a consistent looking DE and being able to pull in KDE or XFCE makes that easier. *Or it's a source of fun depending on the day of the week.

But, yeah, KDE and XFCE have been pretty good about allowing the Window Manager to be swapped out and I'm gonna miss being able to mix and match components from desktops environments since I doubt that Wayland will allow it.

Wayland by design doesn't allow that :-( I really want to test MacOS and see how their WM works.

[oiaohm]

Wayland by design doesn't allow that :-( I really want to test MacOS and see how their WM works.

Not exactly. Wayland core design is not that restrictive. wlroots/sway is implementing with there ext-layer-shell system mostly the same way the ability to mix and match came to X11.
https://gitlab.freedesktop.org/wayla...ge_requests/28
Basically go read about it birdie. This extensions are usable in most wlroots based Wayland compositors today.

https://en.wikipedia.org/wiki/Quartz_Compositor

The reality birdie is Macos design has a lot in common with wayland. Yes the default MacOS windows manager is part of the Quartz Compositor. Yes that is display server, compositor and windows manager in 1. You do see third party windows managers for MacOS but they are doing all kinds of hacks there is no official interface for a Windows Manager on MacOS commonly exploiting the accessibility API.

Yes if the Quartz Compositor does crash there is no magic restart on MacOS either your work is just lost.

Basically zero difference between the way Gnome, KDE and Sway are implementing wayland compositor compared to MacOS.

PS is the MacOS is also CSD where the window decelerations are in fact being done by the toolkit the application is running not Quartz. Weston the reference wayland compositor basically ticks all the same boxes as the Quartz Compositor.

[Danielsan]

You can opt to put more than 10 comments on a page.
What you should get out of is this is that Wayland might not be the best way forward for smaller desktop environments because of poor design decisions.

Fair enough... This project started as made by an individual however if your mindset is only focused on projects backed by sponsors only is quite easy to forgot that exists a parallel word of projects that are 100% made exclusively by volunteers.

[oiaohm]

Fair enough... This project started as made by an individual however if your mindset is only focused on projects backed by sponsors only is quite easy to forgot that exists a parallel word of projects that are 100% made exclusively by volunteers.

There have been a long list of projects like openssl without organisational backing has end up in trouble due to not having CVE information access.

For a core part like X11 that has a networking part you really do need organisational backing due to information you will be locked out of without it.

[Mez']

The reality is the end with open source software normally comes while the software is still working for users then 3-5 years latter when the software starts disappearing out of distributions.



Horrible reality its not fake smoothness. There are lack of smoothness bugs with Mutter that don't show up with other Wayland compositors. Yes they are bugs.
https://gitlab.gnome.org/GNOME/mutte...55#note_929197
Different bugs with Mutter having been finding different smoothness problems under wayland and they are getting fixed. Please note how the person has tested there with KDE on wayland vs KDE on X11 vs Mutter on X11 and Mutter on Wayland yes some of Mutter issues are Mutter issues that don't effect KDE or Sway or Weston or any other Wayland compositor. Some of the problem is the old legacy X11 code in Mutter having hacks around so it can be used with Wayland. KDE Scenes work will have to come to Mutter at some point where they are getting properly rid of the X11 way of doing things.

Attempting to have generic code between X11 and Wayland with X11 Windows manager and Wayland Compositor ends up with problems.

There is a change in feel you will have to get use to you use sway or mutter or any other wayland compositor you do have to get use that they general make higher usage of the GPU so are less effected by system load and more effected by GPU load. Notice something here old school x11 server uses more CPU and less GPU so the balance has moved. So the user response feedback to system load has changed in the bugless Wayland implementations vs bugless X11 implementation this is purely because of having less cpu operations between input to user application and graphics from application to screen in the Wayland solution.

Remember using DMA BUF with Wayland going forwards (heck even the eglstreams option) means applications are using buffers in the format GPU expects under X11 you have the horrible X PixMap (XPM) and options like it that don't match the GPU at all so causes a lot of CPU processing. There is a need to end X11 because there is a lot of things in the protocol that were put in X11 protocol that seams like a good idea at the time that are absolute bad ideas.

Thank you for the information, it's a nice and understandable insight.

Just to be clear though, I'm not saying Mutter on wayland is not smooth, it's actually too smooth... on the surface.
It feels fast, but there's something weird about the way it's fast (kind of similarly to the kinetic scrolling in Firefox, which has too much inertia as well and keeps on going for a looong time after you've stopped scrolling).
It's coming from a feeling, so it's not something easy to express in words and narrow down so as to objectivize. So I apologize in advance if I'm not specific enough in my explanation.
Maybe as you point out it's just the balance between GPU and CPU that has changed but it feels like the compositing is too light compared to what goes on in the background (even when I'm at 1% CPU usage), hence why I'm saying "on the surface".
Others might find that smoothness just the way they like it. Just like some probably like the kinetic scrolling in Firefox, the difference being that you can deactivate this in Firefox.

[oiaohm]

Just to be clear though, I'm not saying Mutter on wayland is not smooth, it's actually too smooth... on the surface.
It feels fast, but there's something weird about the way it's fast (kind of similarly to the kinetic scrolling in Firefox, which has too much inertia as well and keeps on going for a looong time after you've stopped scrolling).
It's coming from a feeling, so it's not something easy to express in words and narrow down so as to objectivize. So I apologize in advance if I'm not specific enough in my explanation..

https://www.reddit.com/r/linux_gaming/comments/c0ly6b/linux_input_lag_analysis7des_tested_windows/

I know this is a old test but it shows how unstable X11 input latency really is.

It is important to try more than one wayland compositor there are bugs in Mutter that come from it sharing code with its X11 version and the wayland version makes the bug worst. Yes input lag can give appearance of firefox like kinetic scrolling. Notice something here Mutter design does not say it has kinetic scrolling of any form the fact even under X11 that it appears to have some its bug.

[Murdock2525]

I'm perfectly aware of that. Too bad this issue stands in the face of each minor DE which wants to support Wayland which kinda speaks volumes about Wayland, its design, usability and APIs. But Wayland proponents will say it's all working as intended. Is it working though? Even KDE/Kwin is still fixing issues although they started over two years ago and that's a major project with decent financial support. LXQt, XFCE, IceWM, JWM, Enlightenment all get zero funding.

I got some anonymous weed today.That was cool.errrr Qt.
Working on Ice