LXQt 1.2 is here about seven months after LXQt 1.1 and it’s a major update to the lightweight desktop environment that introduces initial support for the Wayland display server in an attempt to keep up with the times and the new technologies most GNU/Linux distributions are adopting these days.
Still based on the long-term supported Qt 5.15 LTS open-source application framework, LXQt 1.2 also improves its file manager component with a new search history feature that offers separate lists for name and content searches. Users can search the maximum number of history items in Preferences > Advanced > Search.
I’m glad Wayland support is spreading out to smaller, less popular desktop environments too. Once you go Wayland, you stay Wayland.
Wayland is a perfect example of a transition made horribly wrong.
Microsoft replaced the entire graphics stack in Windows Vista, no one noticed. Everything kept on working including system applications utilizing the systray and other low level graphics features.
Wayland? Let’s fucking break everything, throw everything out of the window and make using Wayland a near impossible task for minor projects. LXQt? They don’t currently have their own Wayland compositor, they are testing others. We still have only Gnome and KDE fully supporting it. That’s ten years after the first Weston release.
Wayland has pushed the Linux graphics stack into the future while pulling it 30 years back. Yeah, it’s now in a worse shape than when we had several X11 servers implementations and then everyone settled on Xorg.
Yes, I find ludicrous that you need to write your own compositor for your window manager. There should be 1 official window server with 1 public API for these things.
I have some links for you.
https://www.apple.com
https://www.microsoft.com/windows
I’m sure the early Windows builds were just as broken. The difference is we can see the sausage being made. The Wizard isn’t hiding behind a curtain.
Thom Holwerda,
…unless it doesn’t support the tools you need. I really truly want to support wayland, but I’m really bothered that they simply chose to neglect critical features for so long and passed the buck to individual compositors to provide the missing functionality, which isn’t working consistently. Sometimes it just takes time to implement things and I accept that, but in wayland’s case leadership ended up shooting lots of users in the feet. Ubuntu rejected wayland initially because it fell short, and they said so. But eventually ubuntu gave in and made it the default, not because the problems were fixed but because they lowed the bar for wayland. This was problematic especially during the pandemic when work & school from home forced many of us to revert to X11 to get screen sharing tools to work. Last I checked a few months ago pipewire still doesn’t fill the functionality gap across all compositors. And to be clear, it is not that people like me are too stubborn to evolve from X11, I know X11 is dated and bloated, but wayland leadership didn’t listen to the community and unfortunately the community has suffered for it.
I’m glad wayland support is improving. I like that projects including wayland are pushing the industry to evolve. However community interests must be better represented in these projects. I’m just not sure that project leaders are learning any lessons to improve themselves.
Canonical saw an opening to build a proprietary display server on top of a FOSS kernel like Apple did. They didn’t have the engineering chops to pull it off, and the world is a better place.
AFAIK Ubuntu started Mir because Wayland did not accept theire patches to add theire convergence functionality. When Ubuntu droped this functionality and Unity and switched to GNOME – then they switched to Wayland.
“Once you go Wayland, you stay Wayland.” In the same way that once you get herpes, you stay infected.
Wayland is a solution to a problem that does not exist, arrogantly forced down our throats by devs who think they are qualified to decide what we need. It offers nothing that X11 doesn’t already offer. The most coherent argument for Wayland is that X11 is no longer actively developed. That’s true: that’s what happens when software becomes stable and feature complete.
Agreed, the big thing that Wayland was suppose to fix compared to X11 was security, yet OpenBSD was able to fork and secure X11 without throwing out the whole thing and starting over.
That would be the Xorg devs, or the devs formerly working on Xorg who now work on Wayland, if you prefer.
It’s funny. In de 10+ years that Wayland has been inching forward as the new Linux display solution, all I’ve heard is criticism and nay-saying that Wayland isn’t the solution. That X11/Xorg is all we need.
Yet no one has really stepped up to help maintain and modernize Xorg, when the core developers/maintainers said the monster had become too unwieldy and crufty to be able to be maintained. Would it be possible to gut and refactor Xorg into something that is modern(ized) and maintainable? Probably. If it isn’t possible to keep it largely X compatible, call it Y12. The trouble is, nobody stepped up and nobody came up with a feasible plan to refactor Xorg. No, it’s only grumbling for 10 long years.
It’s the same with systemd. A lot of griping, but no new project that touts the vaunted “Unix philosophy” and can deliver a highly modularised low level system suite that covers systemd’s use cases and more.
It’s simple in FOSS. Those that do and deliver get shipped in a distro. Those that don’t fill up comment threads.
systemd is a huge upgrade of a zoo of previous init systems and it does not break compatibility – you are free to run your sysVinit scripts all the way. Instead of thousands of lines of brittle bash scripts which break easily, and are nearly impossible to debug, now you have streamlined units with a ton of extra functionality.
Wayland fucking breaks everything and renders a ton of X11 applications completely dead while “solving” two “issues” which have not actually bothered people for at least decade: tearing (TearFree for AMD/Intel and ForceFullCompositionPipeline for NVIDIA) and the X11 protocol insecurity which has never been used to hack a single user out there.
Your comment and “arguments” are squarely off the mark.
Artem S. Tashkinov,
Quite a lot did break though, it’s just that most of the work happens upstream behind the scenes so it’s already fixed by the time it reaches normal users. This is good, but it would have been true of other init systems too.
r_a_trip,
That’s not really true though, there’s a lot of decent init systems, IMHO all of them are better than sysvinit including the one I built for my distro. And linux containers like LXC were even better than systemd. These simple tools that do one thing well and follow the unix followed the unix philosiphy are arguably better than the tentacle monster which is systemd. IMHO the problem with systemd in particular is how monolithic it is, displacing more specialized & capable tools in it’s wake.
That’s assuming meritocracy but the truth is that even in the FOSS world there isn’t equal opportunity. There is almost never a real democratic process, the choices are made behind closed doors and that fact is people including Poettering are able to exploit their privileged positions to push their work above others.
This is true. Those that do may get buried under politics or by better funded organizations which can spread money around.
That’s not the only problem. I rate it’s reliance on dbus pretty high on the list of dumb ideas. Making everything boot in parallel with pseudo sockets is really dumb. (These are server specific, by the way.)
There are nice things about it. Timers are nicer then cron jobs, and it replaces 2 services (anacron and cron). I like networkd better then NetworkManager. Resolved is a nice minimalist recursor.
I’m convinced many gripes about systemd would be better directed at the Linux kernel.
Nspawn containers are pretty nice, and do everything LXC containers do, as far as I can tell. (Bonus points for not having to rely on Canonical!) They use a lot of built in features of systemd, so not much needs to be installed.
According to the Xorg devs, no.
It should be mentioned it was the Xorg devs themselves which deprecated X for Wayland. Random people didn’t start Wayland, it was the people maintaining X who decided it would be better to start from scratch.
Re: Wayland
I prefer Wayland over X11 for a lot of reasons on my daily driver machines, but I do wish they had a standard library with a high level API for building compositors. libweston has had no activity on its master branch for a year, while wlroots moves so fast that each new version of a compositor based on it (e.g. labwc) tends to require a whole new version of the library. And Rust bindings for wlroots are now abandoned in favor of Smithay, which… seems still very incomplete? And there is libmutter I guess, IDK how easy that would be to build something on top of, but knowing Gnome I’d guess not very.
The security issues with X are real though. Main one isn’t code execution or privilege escalation, it’s that X makes keylogging very easy and severely breaks mandatory access control. Windows XP level vulnerability to information theft is, in fact, completely unacceptable in an era where even the dinkiest little tin pot dictatorship can buy zero-days,
Gnome is pretty good at being malleable. Writing extensions to customize Gnome Shell doesn’t seem to be that hard.
This must be very painful news for some people.
Why?
News about Wayland displacing Xorg seems to cause some people great pain.