In my view, this project itself shows some of the reasons why Wayland is the right path forward.
On X, we had Xorg and that is it. But at least Xorg did a lot of the work for you.
On Wayland, you in theory have to do a lot more of the work yourself when you build a compositor. But what we are seeing is libraries emerge that do this for you (wlroots, Smithay, Louvre, aquamarine, SWC, etc). So we have this one man project expecting to deliver a dev release in just a few months (mid-2026 is 4 months from now).
But it is not just that we have addressed the Wayland objection. This project was able to evaluate alternatives and decide the smithay is the best fit both for features and language choice. As time goes on, we will see more implementations that will compete with each other on quality and features. This will drive the entire ecosystem forward. That is how Open Source is supposed to work.
Because Wayland only does essential low-level stuff such as display and graphics it forced people to start coming up with a common Linux desktop (programming) interface out of nowhere to basically glue everything together and make programs at least interoperate.
Such an effort to rethink Linux desktop alone could've been a major project on its own but as having something was necessitated by Wayland all of it has become hurried and lacking control. Anything reminiscent of a bigger and more comprehensive project is in initial stages at best. If Wayland has been coming on for about ten years now I'll give it another ten years until we have some kind of established, consistent desktop API for Linux again.
X11 did offer some very basic features for a desktop environment so that programs using different toolkits could work together, and enough hooks you could implement stuff in window managers etc. Yet there was nothing like the more complete interfaces of the desktops of other operating systems that tied everything together in a central, consistent way. So, Linux desktop interface was certainly in need for a rewrite but the way it's happening is just disheartening.
Nobody has a user-space stick big enough to force things in the Linux world.
When Apple dropped the old audio APIs of classic macOS and introduced CoreAudio, they pissed off a lot of developers, but those developers had no choice. In the GUI realm, they only deprecated HIKit for a decade or two before removing it (if they've even done that), but they made it very clear that CoreFoo was the API you should be using and that was that.
In Linux-land, nobody has that authority. Nobody can come up with an equivalent to Core* for Linux and enforce its use. Consequently, you're going to continue to see the Qt/GTK/* splits, where the only commonality is at the lowest level of the window system (though, to Qt's credit, optionally also the event loop).
GNOME has enough weight to at least force most projects to accommodate them. But unfortunately this has mostly been for the worst, as GNOME is usually the odd one out with most matters of taste and design.
Maybe to some degree that's true. But let's take an example: GNOME is the only (afaik) desktop that requires client-side decorations. They've been like that for years, but nobody else is following them on that. Yes, the toolkits and a number of toolkit-less apps have added support for them. But it's not like they were actually able to employ their gravity to change the world over to CSD (thank goodness).
I don't think GP claimed that everyone copied everything about Gnome, just that every toolkit/program has to implement Gnomes way of doing things even if they continue to support others so you have that as a common (but often bad) interface. CSD is a good example of that - implementations of it have reached libraries like SDL that would rather not care about the desktop user interface at all but because of Gnome they have to.
You say that like it's a bad thing. If you have have an actually good design then you can convince people with those advantages instead of forcing them with a stick.
I think that's the main reason many of us use Linux actually - because we didn't like what the big stick corpos wanted to force on us.
But both Qt and GTK are entirely as well designed as, say, Apple's Core* frameworks for GUI development, yet neither has become the singular GUI toolkit on Linux.
One can view this as a benefit of Linux or as a disadvantage. Both are true.
Ah, if only! GNOME and even to an extent KDE both depend on systemd components, to the point that systemd-free distros are compelled to fork it if they want a GUI: https://wiki.gentoo.org/wiki/Elogind
Only yesterday I was wondering how it is that my brightness keys work in my desktop environment, when /sys/class/backlight/intel_backlight/brightness is only writeable by root. The (somewhat horrifying) answer is that applications can send a request to logind over DBUS, which checks the request against opaque and arbitrarily byzantine Polkit rules, and then writes to the sysfs file on the application's behalf, which it can do because it runs as root. It's unclear quite what this achieves that simply making the file writeable by the "video" group does not, but hey at least systemd gets to be involved.
Incidentally, the correct command to change the brightness as a normal user from the command line is as follows:
So simple, so easy to remember, so superior to "echo <brightness> > /sys/class/backlight/intel_backlight/brightness". Google it for a fun thread on why the --timeout=1 is neccessary (it won't work without it!) - although I suppose I should be thankful for that little foible, as without it the thread wouldn't exist and I would never have figured out the command in the first place.
As noted by others below, this has nothing to do with GUI desktop applications.
Sure, systemd is involved in running the system on which those applications run, but the discussion was about some sort of equivalent to the unified GUI stack offered by macOS (the Core* frameworks) which are used by essentially every GUI application on that platform. Linux doesn't have that, and there's nobody in a position to force that on developers. systemd has nothing to do with this.
Not exactly. Desktop environments (or whatever the program is that launches the application) decides to use systemd to run each application in its own cgroup.
Systemd is certainly relevant to the Linux desktop as a whole, especially regarding logind. But there's no specific relation to GUI desktop applications that I'm aware of at least.
As time goes on, we will see more implementations that will compete with each other on quality and features. This will drive the entire ecosystem forward.
Unfortunately there aren't enough developers to maintain all those duplicate implementations to the level users expect so a lot of features will be missing and a lot of maintainers will burn out. Not having a libcompositor remains Wayland's biggest mistake.
The other key element with Wayland is that the kernel does a ton of the work for you. There s GEM buffer management and DMA-BUF to manage and move around video & regular memory, there's kernel mode setting, there's incredibly good mesa drivers.
X didn't have any of that to build from. It basically was a second kernel, was the OS that dealt with the video card atop the OS actual. It talked to the PCI device & did everything.
Part of the glory of Wayland is that we have fantastic really good OS abstractions & drivers. When we go to make a display server, we start at such a different level now. Trying to layer X's abstractions atop is messy & ugly & painful, because it mostly inhibits devs from being able to use the hardware in neat efficient clean direct modern ways. You have to write an X extension that coexists with a patchwork of other extensions that slots into the X way, that can figure out how to leverage the hardware. With Wayland, most compositors just use the kernel objects. There's much less intermediary, much less cruft, much less wild indirection & accretion to cut a path for.
And as you beautifully state, competing libraries can decide what abstractions & techniques work for them. There's an ecosystem of ideas, a flux to optimize hone & improve, on a variety of different dimensions. The Bazaar free to find its way vs the one giant ancient Cathedral. It's just so so so good we're finally not all trapped inside.
Tl;dr: Wayland has a much higher level that it can start from. And trying to use gpu's & hardware well in X was a nightmare because X has a sea of abstractions - extensions that you had to target & develop around, making development in X a worst of both worlds low level but having to cope with a so many high level constructs you had to navigate through.
> On Wayland, you in theory have to do a late more...
This is vaguely a double-edged sword. Yes, more code duplication across disparate projects - but that also allows people who _really care_ (such as the xfce team) to roll up their sleeves and do more. Any WM will only ever be as good as the X11 baseline, Wayland servers have the opportunity to compete on this front.
Although I'm probably permanently stuck with the Niri workflow, I am looking forward to seeing what the xfce developers come up with.
By the time we get to that utopia someone will declare Wayland obsolete and we'll all be arguing over how Nextfad is the best/worst thing ever.
And technically, nothing has been stopping the xfce devs or anyone from making their own X11 server / X.org fork if the window manager interface was too limiting.
I have no doubt about it, but for my use-cases Wayland definitely is a step up. It's definitely a first-world-problem, but somehow typing feels more enjoyable at low latency - back when I still had a backup X11 session, I could instantly tell that I had left it on: the mouse cursor, input, everything felt like soup.
This is the same logic that led to rails being shoehorned into every company in 2006-2010, which spawned a whole ecosystem of people who specialized in rewriting Rails projects back to Java/C#.
Yes, the stack gets you most of the way there. No, you won't be happy if you need to actually make changes to any part of that other than the top layer.
On X, we had Xorg and that is it. But at least Xorg did a lot of the work for you.
On Wayland, you in theory have to do a lot more of the work yourself when you build a compositor. But what we are seeing is libraries emerge that do this for you (wlroots, Smithay, Louvre, aquamarine, SWC, etc). So we have this one man project expecting to deliver a dev release in just a few months (mid-2026 is 4 months from now).
But it is not just that we have addressed the Wayland objection. This project was able to evaluate alternatives and decide the smithay is the best fit both for features and language choice. As time goes on, we will see more implementations that will compete with each other on quality and features. This will drive the entire ecosystem forward. That is how Open Source is supposed to work.