We don't need more Wayland Compositors
07 XI 2024
6.9k
As we move off of X11 and into Wayland, there are a few people that lament their loss, as their WM of choice does not have a Wayland port. Some people complain about the seemingly small diversity.
The reality is that, although there are quite a few standalone Wayland compositors, you don't hear about most of them, because almost all of them suck in one way or another if you go beyond opening terminals.
The reason is simple: the architecture of Wayland makes the concept of having many WMs obsolete.
Whether you like it or not, Wayland will never have as many (usable) Compositors as X11 had window managers. Period.
In this blogpost, I'd like to argue from the other side, though. That this is a good thing and that it should stay so.
Let's dive into it.
X11 had a concept of a "window manager" baked into the spec. It was expected that managing the windows' placement, decorations, etc. was to be done by a separate program. However, this has many disadvantages, for example:
Wayland deals away with that (admittedly, dumb) idea in favor of every compositor being its own display server with its own rules and APIs.
This is why we don't call them window managers: they don't just manage windows. They also render the entire desktop. Talk to your kernel. Manage your HIDs. Run the actual protocol. So on and so on.
Does this mean writing a wayland window manager is not possible? Yes and no. More on that later.
since a WM was separate from the display server, swapping a WM would not utterly break the session. Sure, things could break here and there, but most core functionality did not.
(footnote: X11's design was so garbage that quite a few things could break in funny ways when switching WMs, but that doesn't matter here)
As stated before, Wayland Compositors are an entire display server. Think Xorg + WM + Picom all in one package. This means they are massive and responsible for tons of stuff.
In X11, you could switch a WM and barely notice it. On Wayland, switching a compositor can have much more severe consequences, as support for various core components might drastically differ. You could boot into a separate environment and find out that e.g. your Input Method doesn't work. Or your apps show up weirdly. Or monitors don't work exactly as they are supposed to. Or your scripts broke. Or some apps don't work at all. Etc, etc.
However, this has one massive advantage to the end user: performance.
All these components don't have to talk over wires to discuss literally anything, as they are one single process. If you've switched to Wayland, I'm pretty sure you've already noticed the instant improvement.
Neither provides a codebase even comparable to what Xorg used to be. Writing a Wayland compositor, even using either of these, is still a huge undertaking with limited docs, complex mechanisms and a steep learning curve. This will not work, as there are very few people who can even put the effort to do so, outside of companies and organizations like KDE or System76.
Furthermore, these libraries cannot provide you with "everything", because for one, we'll end up with Xorg2 where you have a printer server embedded into your display server, and two, different environments have vastly different requirements.
Opinionated development is yet another barrier for those libraries to be a one-size-fits-all solution.
Instead of creating 20 WMs, all replicating 90% of another, it's better to have a few bases serving as modern Xorg instances for our new way of thinking about WMs.
Most DEs provide a plugin API already, and have had "WMs" for ages. See the tiling extensions for Gnome or KDE.
For standalone desktops, Hyprland is undeniably your best base at the moment to write a window manager.
With a powerful plugin system, you can write your own new WM (or what is called a "layout") plugin for Hyprland in as little as 200 lines of code.
It has many advantages over Xorg WMs as well:
At the cost of, well, one drawback:
If you don't believe it, see some amazing WM plugins for Hyprland on Github,
You don't have to worry about supporting protocols, rendering fancy effects from scratch, etc, you can just focus on writing a WM, just like we did back in Xorg days.
Wayland is a vastly different approach to a desktop session than X was. It's much more modern and efficient, and thus will bring major changes to how things work. We can't escape that.
However, instead of lamenting at things we seemingly lost, instead, let's find solutions.
Your favorite tiling WM doesn't have a Wayland port? Pick up the initiative yourself and write a Hyprland plugin that makes it behave like your WM of choice.
When I lead Hyprland, I very much also try to help those that make plugins for it. If you have something in mind, but Hyprland is missing some changes in code to fit it, I am very open to helping you! See for example #8349 where there were problems with rendering some hyprscroller's windows, that did not affect Hyprland itself, which I was happy to help fix. (unlike some others like idk maybe some DE called Gnume or something)