I will preface that Xorg is obviously an unmaintainable mess of legacy decisions and legacy code, and I have both a machine that runs Hyprland and a machine that usually starts Plasma in Wayland mode so the Wayland situation getting to be more-or-less adequate with persistent irritations here and there… but Wayland is trauma-driven-development. It’s former xorg developers minimizing their level of responsibility for actual platform code, but controlling the protocol spec, and in the position to give up on X in time with their preferred successor.
Essentially all of the platform is being outsourced to other libraries and toolkits, who are all doing their own incompatible things (Which is why we have like 8 xdg-desktop-portal back-ends with different sets of deficiencies, because portals were probably designed at the wrong level of abstraction), and all have to figure out how to work around the limitations in the protocols. Or they can spend years bikeshedding about extensions over theoretical security concerns in features that every other remotely modern platform supports.
Some of that outsourcing has been extremely successful, like Pipewire.
Some attempts have been less successful, like the ongoing lack of a reasonable way to handle input plumbing in a Wayland environment (think auto-type and network kvm functionality) because they seem to have imagined their libinput prototype spun out of Weston would serve as complete generic input plumbing, and it’s barely adequate for common hardware devices - hopefully it’s not too late to get something adequate widely standardized upon, but I’m increasingly afraid we missed the window of opportunity.
Some things that had to be standardized to actually work - like session management - have been intentionally abdicated, and now KDE and Gnome have each become married to their own mutually-incompatible half solution, so we’re probably boned on that ever working properly until the next “start over to escape our old bad decisions” cycle… which, if history holds, isn’t that far away.
We’re 15 years in to Wayland, and only in the last few years has it made it from “barely a tech demo” through “Linux in the early 2000s” broken, and in the last year to “problems with specific features” broken … and it is only 4 years younger than the xf86->xorg fork.
Your issue is you’re assuming all things must be standardized in a monolithic fashion.
The whole point of Wayland is that monoliths are bad in an environment as diverse as the Linux desktop.
Either libinput will be improved or it will be replaced as needed.
I’d argue portals are deficient because Wayland implementations in general are not complete. An org like KDE or GNOME has a fair bit of man power but they’re still in a position where they need to keep X11 functional and they need to carry forward decades of features. Even if Wayland was flawless from the onset that’s a huge undertaking.
Wayland is one part of what needs to be a collection of specifications, but the point is to have a specification instead of an implementation. You can actually have implementations that make different trade-offs and optimize different use cases that way.
That doesn’t prelude something like mir or wlroots acting as a base layer for desktops that don’t want to build up from the specification … but it does allow KDE to write a compositor that does exactly what KDE needs/wants … instead of the X11 mess where you can “turn the compositor off” which results in effectively two classes of desktop, one of which is used for gaming, the other for general desktop use … or any of its various other issues.
They don’t have to be specified in a monolithic fashion, but some things - like the input plumbing and session management examples I made - do have to be specified for for software to work when running under different compositors. FD.o basically exists because we already learned this lesson with other compat problems, and solved it without putting it in the X monolith - it’s why things like ICCM and EWMH happened; there were more details than were in the existing APIs that everyone needed to agree on to make software interoperate.
Competing implementations are great, but once you have significant inertia behind competing implementations which are not compatible or at least interoperable, you’ve fragmented the already-small Linux market share into a maze of partially-incompatible micro-platforms. We’re not going to have compositing and non-compositing, we’re going to have 3ish (KDE/Qt [kde], Gnome/Gtk who aren’t even doing documented protocols, and Everyone else - mostly [wlr] extensions) incompatible sets of protocols for basic functionality.
Looking at the slow bitter process to extend or replace components once implementations that rely on them exist, that’s not something to count on. Remember how it took 15 years of contention to eventually transition to D-Bus after CORBA/Bonobo and DCOP? That’s whats about to happen with things like the incompatible gtk and qt session management schemes. And that resolution was forced by the old HAL system using it, not the other parties involved getting their shit together of their own accord.
One place we’re about to see innovation is wayland-stack-bypassing workarounds. Key remapping is currently in that category, the wayland protocols suite punted… so instead, keyd sniffing all the HID traffic at the evdev and/or uinput layer and outputting the rule-edited streams to virtual HID devices. That one does have a certain global elegance (works on ttys!), but it’s also layering violations with privileged processes.
I’m not going to say that there haven’t been balls that have been dropped on some things. Like, we should’ve come out of the gate with a protocol for remote desktop access as an example.
However, when all these X11 developers say it’s time to move on, I’m inclined to believe them.
We’ve already had the fragmentation between different desktops on various things, dbus APIs as an example have often been KDE or GNOME specific. It’s been a long standing complaint really. And well, as much as I’m sympathetic I think we get more from flatpak than we lose from Wayland. There are going to be specific niche programs that need to deal with specific APIs but in general, I think it’s easier than ever to ship “one package” and have it just work where you need it to.
Based on the inertia that wayland has I’d be shocked if it takes 15 years for one or two dominate APIs for various missing pieces to emerge with one becoming the standard.
So we’re calling just doing one thing “trauma-driven-development” now? Yeah, Wayland doesn’t do everything Xorg does. That’s a good thing. Xorg is a dying, dysfunctional mess because it does a thousand different totally unrelated things and nobody understands all of them and how they’re all tied together. We’re probably going to run into the same problem again eventually with systemd. Feature creep is toxic for open source software.
Wayland has problems, but not being X12 isn’t one of them.
It looks like the article's answer to the question in the title is essentially "yes, but someday, eventually, it won't."
Personally, I look forward to the day when "Wayland-and-Pipewire-and-Portals" is a mature platform, and I can switch over to it without too much fuss. Until that day comes, though, I'll be sticking with Xorg.
as long as software I use daily doesn’t work on it as transparently as it did to me as an end user on xorg then yes, to me as the enduser, Wayland does break things and no, Wayland is not ready
I am an enduser. I don’t care about the specifics, I expect things to work and not suddenly break.
For all the “year of the linux desktop” shouting, nobody wants to truly really think about or consider non-dev daily driver endusers who just want things to continue to work like they always have
For me, yes: Wayland doesn’t work at all and the only answer I can get is that it’s because of Nvidia. That’s stupid because until some update broke it, it worked. Most apps were just very buggy.
For years Nvidia tried pushing an alternative Linux driver called EGL, everyone told them it couldn't support Wayland
Eventually Nvidia tried to implement EGL backends to Gnome and KDE (this resulted in the buggy apps). Nvidia then declared their new cards would support GBM.
This leaves the 10xx-30xx cards stuck on EGL with no one supporting the EGL backends. Nvidia have made it so GBM support can't be added by outsiders to those cards either.
All of Wayland is based on EGL. What you are referring to are EGLStreams vs GBM which are both libraries using EGL. Nvidia drivers now support GBM for all supported GPUs via a support library that comes with the driver (libnvidia-egl-gbm https://download.nvidia.com/XFree86/Linux-x86_64/510.39.01/README/gbm.html). There should be no difference in the GPU generation used.
For troubleshooting, I recommend
For trouble shooting recommend https://community.kde.org/Plasma/Wayland/Nvidia, checking whether all kwin backends are installed (kwin-wayland-backend-* on Ubuntu). Sometimes there's also a problem with the missing OpenGL backends of Qt. An easy check to see whether there is a problem with the proprietary driver is to try out whether the problem also exists using nouveau.
Well, it’s a big upgrade underneath. They’re moving from qt5 to qt6. Tons of fundamental wayland fixes with the new toolkit/framework. You might be right that it’s not that dazzling of a visual overhaul, but it’s a mature product. We need more polish than overhaul
The migration to Qt6 and the work being carried out on Wayland, which is all going into Plasma 6.0, is going to allow massive changes that will be introduced over the 6.x series. There are some pretty cool features in 6.0, but the bigger changes will come over the next few point versions.
It is unlikely you will see any of these updates in Plasma 6.0, as they are more proof of concepts than finished, tried and tested features. But you will see them introduced over the next versions in the 6-x series.
Are you a KDE user? I switched from Gnome 3 when Plasma 5 was new, the very moment it seemed close enough to finished to expect reasonable stability. It was a huge departure from KDE4, and after trying literally every other DE to find happiness away from Gnome (that's all I'm going to say about that) over the course of several years, it was such a welcome relief.
Plasma 5 was not only a life preserver for folks bailing from Gnome, it also showed they'd learned from their own mistakes with KDE4, which many users felt was just as much a trainwreck as Gnome 3.
There's a lot going on under the hood with the change to QT6 as noted, and that alone merits a version number change, IMO. I haven't tracked a whole lot of specific features, but I know there are a lot of wayland refinements and HDR support coming, and I'm doubtful that the many pointieststick blogposts have been doing nothing but writing about bugfixes and menu changes, even if I haven't read every single one of them.
The general default look and feel maybe isn't being radically changed, but this is Linux, and more importantly KDE; we're all about theming and customization anyway, right?
Most importantly they aren't throwing out the baby with the bathwater. They did it (intentionally or not) with 4, and then (in my perception) they were forced to do it with Plasma 5 because of KDE4.
After living through the transition from Gnome 2 to 3, and KDE 3.5 to 4, then feeling the relief when Plasma 5 just absolutely crushed it, I'm very happy to see them upgrading the undercarriage and making things generally better instead of building it all from the ground up again.
@be_excellent_to_each_other@leopold@Fizz I’m actually 100% happy with just bugfixes. KDE is my choice, but, I mean, its still a fairly buggy desktop. It’s great, all it needs is the masses of bugs fixed, anything that does that is good. That’s all it needs.
Yeah I understand it’s a lot under the hood, but people seem to anticipate it like it’s the best and most exciting thing since the second coming of sliced bread. I kinda don’t get it. But it’s good that it’s coming along. I probably won’t even notice a difference.
because those two things are pretty much what Plasma needs the most at this point. the two most common complaints about Plasma are that it’s buggy and that it’s ugly.
Especially under load, KDE is a freezing mess. Copying back a backup (under 100GB) and I literally cannot move my cursor.
Meanwhile crashing programs make the shell unresponsive too. Like, there is no seperation?
The performance issues literally are so bad I considered moving back to Windows. Or GNOME with some Zorin/Oeron shell modifications. Probably GNOME, but many apps are unusable and they have no fractional scaling??
I am looking so much forward to cosmic, even though I dont see at all how it should be a complete desktop soon. But Wayland only, written in Rust, from scratch exactly for the modern use case… its awesome!
Like, KDE will never be memory safe, they are bound to Qt.
Yeah, Plasma isn’t great under heavy IO and as far as I can tell that’s not really getting fixed in Plasma 6. It’s one of the biggest problems I have with it right now. On faster storage it’s not really a problem, especially on SSDs, but on slower storage it can definitely be. I would recommend trying a different desktop.
GNOME is generally heavier than Plasma, but might indeed perform better in the scenario. You don’t have to use GNOME with GNOME applications if you don’t like them. You can easily use GNOME Shell and Plasma applications. There other desktops worth a try outside of GNOME and Plasma, tho. LXQt should be very fast. Enlightenment even more so.
Also, I don’t think memory safety is among KDE’s biggest concerns. Qt afaik handles a lot of the memory management and it is a professional toolkit which has received a lot of testing. It shouldn’t be too problematic. Writing memory safe code is also much easier in C++ than it is in C. Yeah, Rust is better, but it doesn’t seem to me like this is something that’s causing that many problems in KDE.
I remember trying just about every GUI calculator I could find and trying to get one I could actually tolerate. Any calculator which pointlessly hid what you’d written from you every time you added an operator like KCalc did was automatically out, which disqualified a surprisingly and disappointingly large amount of calculators. Any calculator without a standard skeuomorphic interface was also out, because I didn’t feel like relearning how to use a calculator.
I used GNOME calculator for a while, but switched away because I found the interface for programmer mode to be hella confusing when I really just wanted to have hexadecimal and binary modes. I also used Uno Calculator for a while, a direct port of the Windows 10 calculator, but the port was a bit rough and fonts didn’t work so well, otherwise it would’ve been perfect. I finally settled on Deepin Calculator. A bit basic and completely unthemable beyond switching between dark and light themes, but it was very easy to use and had all the functionality I needed. I can’t for the life of me remember why I didn’t just go with Qalculate!. I know for a fact I tried it and it seems like it would’ve been perfect. I’ll probably just be using KCalc from now on, tho.
Activities do a lot more. Virtual desktops are purely a window management feature. They contain windows and very little else. Activities can have different, panels, wallpapers, desktop icons, etc.
The way I explain it is that it’s virtual desktops that you can start and stop at will and run scripts when doing that as well as switching to and from activities. It also has different shortcuts like this other guy said
I get into phases where I use Activities, and I like the workflow, but then I forget about it for a while. I like having the separated workspace with no other thing showing up in the taskbar, but moving applications between the activities is a pain.
I’d like to see it stay but I don’t have the knowledge to maintain it, so I guess I’m at the mercy of the KDE team’s willingness to keep it on life support.
@ikidd@leopold
I use 4 work spaces & organize by my own system/categories as I start opening stuff after a weekly restart, a couple of vivaldi instances, firefox all with their own email & download locations
No special setup beyond me remembering my own scheme, easy to move stuff between work spaces
I finally found my use case for activities - switching between work and personal stuff. Having virtual desktops isn’t enough to separate the two for me, but activities does the job really well. Would miss the feature if it goes the way of the Dodo in the future.
I hope it sticks around and is refined further. I started using KDE maybe six months back, after not having touched it in probably 10ish years. Back then I hated KDE but now it’s absolutely my favorite DE. Having regularly used virtual desktops before my switch to KDE, activities are a pretty big part of what I’m loving about the experience. The feature can be clunky in certain ways (mainly moving apps between activities), and I’d love to see further refinement, but even at its current state of implementation it helps so much with my own workflow.
At the moment I run 6 activities: “Default” which generally has a web browser open to my Proxmox servers’ web panel, as well as a terminal, “Gaming”, “Media”, Work (Primary), Work (Secondary), and then “Other” for random crap that doesn’t fit any of the main activities. I have hotkeys set up to easily switch between them, and each taskbar has different pinned apps.
Unfortunately I’m not really a coder so I can’t contribute directly to maintaining it but I do hope the feature is either refined or merged into virtual desktops in a way that keeps its core benefits.
Exactly (at least in my experience). I have my gaming apps pinned in my gaming activity, and my work apps in my work activities. The only annoyance there is when certain apps open in the “wrong” activity. For instance, I pretty much always have the Kate text editor up in my gaming activity because I play games with a million mods and constantly have to fix things. Because of that, when I need Kate for work it’ll tend to open an instance in the gaming activity and I have to move it in the clunky way stuff gets moved between activities.
I know it has it, but at least for me I find activities to be more beneficial. I really like being able to customize them for each purpose. I’m also not sure if you can set custom hotkeys to go to a specific virtual desktop like you can with activities.
Obviously if activities get removed from KDE I’ll go back to using virtual desktops but until then I’ll make the most of them.
pointieststick.com
Oldest