There's already been quite a bit of hype surrounding the way Wayland has been developed over Xorg, see for example:
But a lot of the criticisms seem to stem from the limitations of Wayland right now, whether that's due to design decisions which Wayland have made in comparison to Xorg, or because Wayland has a feature which is similar to Xorg but not quite the same.
Most people seem to take it at face value that Xorg is slow and insecure, etc., with only anecdotal evidence to back it up, and hence just believe that Wayland is better because it has a different design.
But no one seems to really be talking about the deliberate choice Wayland have made compared to Xorg -- that being the loss of reparenting and drawing primitives.
Xorg's most top-level window is the root window. A window manager registers interest in observing events from the root window, such as when a window is created (or in Xorg parlance, mapped).
In such cases, a top-level window frame is usually drawn -- itself a direct child of the root window. When it is displayed, the original window is reparented away from the root window into the frame window.
graph TD;
subgraph Root_Window[Root Window]
subgraph Frame_Window[Frame Window]
direction TB
subgraph Child_Window[Application Window]
end
end
end
Hence, from that point on, the window manager is using the Frame Window to interact with the application window.
Because reparenting exists, it means window managers are able to draw their own frame, and to provide other features such as window buttons, a titlebar, etc. This concept is divorced from the application needing to provide this.
This has been a long-agreed standard through which applications register capabilities so that window managers can manage clients. It's via these agreed protocols that window managers are able to ensure correct behaviour with the windows they manage.
Historically, it was the ICCCM2 (Inter-Client Communication Manager) which defined this initial behaviour. Later on, a consortium of people across the X11 window manager space banded together to define an extension to the ICCCM2 which is referred to as the EWMH (Extended Window Manager Hints). This was a collaboration between window managers and desktop environments alike to define common client behaviour -- on top of what the ICCCM2 detailed.
In recent times though, there has been a shift towards clients providing their own styling -- such as buttons for maximisation, iconification, etc. These are known as CSDs -- or Client Side Decorations. This is where the application provides this functionality directly, including the style.
What this means for reparenting window managers is that a provided additional frame with its own buttons can look somewhat redundant because the frame window is doing double-duty to what the application window can provide.
As a mention in passing, it's worth noting that CSDs are wholly dependant on the widget library providing CSD functionality. Presently, GTK is the biggest proponent of this. By toolkits providing this, it simplifies compositors on Wayland.
In the true Xorg sense, this describes letting the server use its own drawing primitives to render the frame for the application window. Xlib's drawing primitives are rather comprehensive; providing all manner of abilities to draw points, arcs, lines, etc, and to provide colours, shadows, etc., to them.
In Wayland parlance, the compositor is both the server and the window manager. This therefore makes it responsible for managing events and rendering windows, etc., as well as supplying additional ancillary applications such as status bars, menus, etc.
These are what I would call an attempt at providing some equivalence to the EWMH, but albeit in haphazard attempt. I say "haphazard" only in that it seems at times to be contested and fraught with a difference of opinion:
- https://github.com/misyltoad/frog-protocols -- aims to alleviate the bottlenecks of wayland-protocols being stalled in purgatory;
- https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/269 -- the ability to change a top-level icon on a window.
I do have to wonder how many of the developers looking at Wayland understand some of the keystone features of the EWMH at this point -- and while I appreciate that just shoe-horning the EWMH into Wayland isn't the correct thing to do either -- the fact that some of these hotly-contested opinions stall proposals in way that just ends up bike-shedding things, really only highlights the fact that this is becoming an appalling example of design-by-committee.
Presently, there are some consensus on protocols -- and although they often start out in a certain compositor, to be then shared amongst others, because of this decentralisation, consensus becomes considerably harder to reach, requiring each compositor to be able to support their own specific quirks and desires.
I can see some of these becoming messy over time, given this.
However, when it comes to SSDs (Server-Side Decorations), there is an attempt at providing something, but it's considered unstable, despite being implemented across a number of compositors:
I think it does. But I would -- I'm the person who's written this.
There's a few key loses with Wayland. I've spoken about lack of reparenting. Without this approach windows won't be able to operate in any traditional sense of window management. I'm not just referring to MWM (Motif Window Manager), but also how other DEs on XOrg have typically worked (Openbox for example); I know labc exists as an experiment -- but its window decorations will be hampered by Wayland's choices -- xdg-decoration only works with both the client and the compositor allow for SSDs; I can't see how labc can therefore provide true compatibility with Openbox.
So if compositors cannot draw their own frame around an existing application window for the purposes of reparenting, what's left is what most compositors do now, which is to draw boxes as a frame around a window.
This sucks, primary because:
-
Such decorations are completely separate to the operation of the window. This means that the movement/resizing of the client window has to now take into account moving/resizing such boxes. I know that
wlrootsprovides an API for this -- but the fact remains that there's already been reports of odd placement issues between the two windows: -
Style. Some of us like to have control over how our windows look. Not just because it might emulate some existing WM from six eons ago, but without such options, it will mean that across different compositors on Wayland, everything is more-or-less going to look the same, flat, boring look -- converging on a "one style fits all"; without originality and the potential for personal flare, what's left? The way we use our computers might be changing, but that doesn't mean we shouldn't be left with some choice over how things look -- not everything is just about the applications we're using being the only reason we use computers.
-
Forced into a Hobson's Choice scenario. Sure, there might be a plethora of compositors out there -- some of these might provide some sort of feature or rather, but given the limitations I've outlined, you really are only left with one choice which doesn't offer much:
https://en.wikipedia.org/wiki/Hobson's_choice
Indeed -- now choice is governed by the toolkit in use; in having to select some Wayland Compositors, you're not just choosing a point of difference in how windows are being managed (tiling vs stacking), but rather the toolkit mostly dictating the style of the application and its behaviour.
-
Toolkits dictate the future. GTK5 has already laid down the gauntlet and said it's going to remove support for X11:
https://blog.gtk.org/2025/02/01/whats-new-in-gtk-winter-2025-edition/
Right now -- the only thing which keeps some of us using X11 given the changes in Wayland, is because we can still use whichever WM we like, and that irrespective of XServer's development dwindling, it doesn't really matter as it will continue to work, as will the applications. But the day certain widget/toolkit libraries stop supporting X11, and those applications switch to those versions, spells the death of anyone wanting to use a WM on X11. Primarily, I'm probably referring to the ability to use a web browser, but I could be speaking of any application.
I know this coupling of toolkit and Desktop Environment isn't new, this is -- to me -- highlighting a relationship between the two which has the potential to be unhealthy in the long-term.
-
XWayland is not an appeasement. I know XWayland exists -- and lovely-jubbly it exists for someone to run some random X application which has no Wayland support, etc, etc. For me, that'll be something like XTerm, or XClock, or anything from the x11cp project. That's great news.
But what it isn't, is the ability to run some random X11 WM under and expect that to someone provide an illusion of a working environment, effectively by-passing a Wayland Compositor entirely. That still has the same limitations as running something on X11 directly.
Maybe. But without reparenting, it's going to be difficult.
Assuming it were possible to look at SSDs in some concrete way, then the thing which matters here is ripping out the drawing primitives part of XLib, and making that a standard rendering library in its own right.
This would allow a given compositor implementing this to provide a "frame" around a window, albeit with the limitations I mentioned where the application window and the frame window could easily come out of sync with one another.
Indeed, libcairo exists as a means to potentially help here, but it is limited in its offering in terms of style/shading/etc., found on XLib, despite libcairo trying to replace some of that. It also hasn't seen much in the way of updates in a while. I know some Wayland compositors do use it to render SVGs to be able to provide frames around windows.
So one approach here could be for someone to start hacking on libcairo to support some of the equivalent functionality found in XLib for its drawing primitives. It could be feasible, but a lot of work.
If certain compositors allowed for SVGs to be used to draw frames, then a user might be able to be able to provide images which could be used to render such a style -- but even this is going to be fragile, and something which is a pain to change for the user, should they want to do anything on-the-fly in terms of theming, etc.
I know change is inevitable -- it happens all the time. For most people it's likely something they won't notice too much when things become Wayland-only. But there are still a number of people for whom, having grown up with computing in an era where choice and style were separate from applications, it doesn't just become a preference of look-and-feel, but also of a workflow; of managing windows in a way which was unique to a whole manner of different WMs.
And it's this which Wayland is going to kill. Because of the freedom that XLib offered on XServer, it gave rise to so many different environments all with their own ideas on handling windows. Just look at something like Giles Orr's list of window managers:
So when this does happen For Real (tm), I think it will be a sad day. A certain category of computing for many will be fundamentally over, where we are forced to choose between an inferior and bloated DE or some sort of tiling window manager, only providing the ability to look like everything else.
I think at this point, anyone wanting to try and keep certain things alive from XLib which aren't inherently a part of Wayland will have to get creative. I know I will look at this.
I initially had the idea that continuing to maintain XServer was the right approach -- I am not so sure on this. Although it will help keep certain applications alive, once toolkit libraries drop X11 support and newer applications take over -- how useful is this? I don't know.
So I might look at a different approach to all of this. I just know that there's enough people out there who might want this for me and others (hopefully) to try.
The first part of this is correct; there's no longer a separation between the two. However, compositor does not need to render status bars, docks, etc. In the case of GNOME, the developers decided that only they can implement this and third parties cannot, but that is a just design choice of a single implementation. AFAIK, no other compositor is developed with this deliberate restriction, and the protocol most definitely does not impose it.
If you want to write your own shell components, you can currently use wlr-layer-shell-unstable. This extension supported by wlroots-derived compositors (plus a few others), and is in the process of being standardised upstream.
BTW: unstable doesn't mean that "it might crash your compositor". It means that it hasn't been fully standardised and that it MAY change in backwards incompatible ways in future. Think of it as a draft RFC.
Regarding decorations: compositors can draw frames around windows (in fact, sway does exactly this). Sure, some compositors don't let you customise these at all, much like some Xorg window managers don't let you customise these at all either.
Xorg does allow having multiple programs running as window managers at a time, but I don't think that was ever a deliberate design choice: it sounds more like running all daemon a
root. Incredible flexibility due to lack of planning.Regarding XLib: there's plenty of other libraries out there which can render primitives, shadows, etc. You only need to draw bytes into an in-memory buffer (ideally, in GPU memory). There's no reason for which the compositor needs to implement this itself, much like there's no reason for the kernel to implement this itself. There might be some value in implementing an XLib shim, which exposes the same API for some drawing primitives, but renders them on a wl_surface. This would probably be quite useful for porting stuff.