> Although, I do not know for sure why the original Wayland authors chose to combine the window manager and Wayland compositor, I assume it was simply the path of least resistance.
Although I'm not sure if it was the least resistance per se (as a social phenomenon), but just that it's an easier problem to tackle. Or maybe the authors means the same thing.
(That and the remote access story needs to be fixed. It just works in X11. Last time I tried it with a system that had 90 degree display orientation, my input was 90 degrees off from the real one. Now, this is of course just a bug, but I have a strong feeling that the way architecture Wayland has been built makes these kind of bugs much easier to create than in X11.)
There were probably other ways to fix those issues, but it would still be a fair amount of churn.
X11's extension mechanisms can - and has - been used to enable backwards incompatible protocol changes. E.g. BigRequest changes the length and format of every single protocol request.
Very few client libraries are only capable of speaking "the existing" protocol if you take that to mean the original unextended X11 protocol.
Adding an X11 extension that when enabled cleans up a lot of cruft would not have been a problem.
> where ideally the window manager would make choices about things before the process continues
Nothing stops you from introducing an extension that when enabled requires the client to wait for a new notification type before continuing, or re-defines behaviour. That said, using my own custom window manager, I don't know what you mean here. My WM does decide the initial window placement and size, and it's the clients damn problem if it can't handle a resize before I allow the window to be mapped.
The X protocol is crusty in places, but it is very flexible. People haven't fixed these things because they chose to invent compatibility hindrances that weren't real when their response was to invent an entirely new protocol with no compatibility at all.
On a tangent, also very ironic that X (the successor of Twitter) has the exact same logo as X (the window system). It's like Elon Musk just Googled for the first X logo that came along and appropriated that and nobody seems to notice or care.
When there was the 90deg off bug, was that a bug in the compositor or in wlroots?
Wayland can use RDP and some other remote desktop protocols, but it is not what I want, I want a window, not a desktop. There is Waypipe now, I heard it works fine now, but I am still doing "ssh -X", because it just works.
The problem with Wayland is that it is very much "batteries not included". To all the things that worked well in X11, the response has been "it can be done, our protocol is very flexible, ask the guys writing the compositor", not "that's how is done". The result, Wayland is 18 years old and it is only starting to work well, with some pain points still remaining, and display forwarding is one of them.
It is funny you mention a "reasonable path" by the way, as it is exactly that problem, I don't want a "reasonable path", I want it to work, and after 18 years, I think it is a reasonable expectation. To their credit, it seems we are getting there: waypipe, and now window managers, we may finally have feature parity.
What gets me is how old Wayland is. It's now older than Linux itself was when Wayland started. It started in the era of 2.6 kernel series, when most software was still 32-bit, systemd didn't exist, when Motora Razr was more common than iPhones, when native desktop applications were still the norm, Node.js didn't yet exist and Google Chrome was a completely new beta browser. Wayland is now reaching feature parity and some kind of "it works out of the box, usually" state when it's from a completely different era of computing.
The nearest point of comparison is perhaps systemd, another Linux project that is very large in scope, complicated, critical and must interface well with lots of pre-existing software. Four years after Poeterring's "Rethinking PID 1" post that introduced systemd, it was enabled and in use on many distros. The conservative Debian adopted it within five years. Now it's been clearly a major success, but Wayland has been perhaps the slowest serious software product to be in development.
Or maybe it’s desktop environments pulling the ladder up behind them.
Now it will take another 15 years for people to settle down in a set of common protocols instead of writing their own extension protocols and others 15 years for window managers to mature at the same level of the X11 window managers.
Then, people who think they know better than everyone else will throw Wayland away and start from zero all over again.
I thought I still did as my travel netbook died, but then I ended up in UEFI mess, regardless of the distro, and decided in the end to give that role to a Samsung tablet with DEX support instead.
The "limitations" are political, not technical.
Whatever ideological debates there are underneath the X vs. Wayland divide, ultimately what I care about is things working as well as or better than other mainstream operating systems, and Wayland seems to deliver on that.
You can move the title bar around, and depending on the window manager either double clik to drop down again its contents, or by leaving the mouse pointer for a few seconds hover it, it will temporarly reveal its contents.
If you were an Xmonad user I feel pretty confident in saying River is the Wayland WM for you.
Also, when it was split up what did he call his window manager? Looks like the River repo is just for his display server/compositor
Simple example of how impactful this separation has been for me.
hy3?
https://github.com/outfoxxed/hy3
(I'm an ex i3/now sway user and hy3 is the only way I can bear using hyprland)
It doesn't introduce a new IPC, it uses the Wayland protocol with the river-window-management-v1 extension. The extension mainly defines new objects and verbs for them, but it's the same protocol.
Separate process means that the window manager can be written in any language (even, e.g.: Python).
https://en.wikipedia.org/wiki/NeWS
Everything old is new again.
Alan Kay on “Should web browsers have stuck to being document viewers?” and a discussion of Smalltalk, HyperCard, NeWS, and HyperLook:
https://donhopkins.medium.com/alan-kay-on-should-web-browser...
Window Management -- Overview: F R A Hopgood, D A Duce, E V C Fielding, K Robinson, A S Williams. 29 April 1985.
This is the Proceedings of the Alvey Workshop at Cosener's House, Abingdon that took place from 29 April 1985 until 1 May 1985. It was input into the planning for the MMI part of the Alvey Programme.
The Proceedings were later published by Springer-Verlag in 1986.
James Gosling: SunDew - A Distributed and Extensible Window System.
https://www.chilton-computing.org.uk/inf/literature/books/wm...
The X-Windows Disaster: This is Chapter 7 of the UNIX-HATERS Handbook. The X-Windows Disaster chapter was written by Don Hopkins.
https://donhopkins.medium.com/the-x-windows-disaster-128d398...
As a result, one of the most amazing pieces of literature to come out of the X Consortium is the “Inter Client Communication Conventions Manual,” more fondly known as the “ICCCM”, “Ice Cubed,” or “I39L” (short for “I, 39 letters, L”). It describes protocols that X clients must use to communicate with each other via the X server, including diverse topics like window management, selections, keyboard and colormap focus, and session management. In short, it tries to cover everything the X designers forgot and tries to fix everything they got wrong. But it was too late — by the time ICCCM was published, people were already writing window managers and toolkits, so each new version of the ICCCM was forced to bend over backwards to be backward compatible with the mistakes of the past.
The ICCCM is unbelievably dense, it must be followed to the last letter, and it still doesn’t work. ICCCM compliance is one of the most complex ordeals of implementing X toolkits, window managers, and even simple applications. It’s so difficult, that many of the benefits just aren’t worth the hassle of compliance. And when one program doesn’t comply, it screws up other programs. This is the reason cut-and-paste never works properly with X (unless you are cutting and pasting straight ASCII text), drag-and-drop locks up the system, colormaps flash wildly and are never installed at the right time, keyboard focus lags behind the cursor, keys go to the wrong window, and deleting a popup window can quit the whole application. If you want to write an interoperable ICCCM compliant application, you have to crossbar test it with every other application, and with all possible window managers, and then plead with the vendors to fix their problems in the next release.
In summary, ICCCM is a technological disaster: a toxic waste dump of broken protocols, backward compatibility nightmares, complex nonsolutions to obsolete nonproblems, a twisted mass of scabs and scar tissue intended to cover up the moral and intellectual depravity of the industry’s standard naked emperor.
Using these toolkits is like trying to make a bookshelf out of mashed potatoes. - Jamie Zawinski
X Myths
X is a colletion of myths that have become so widespread and so prolific in the computer industry that many of them are now accepted as “fact,” without any thought or reflection.
Myth: X Demonstrates the Power of Client/Server Computing At the mere mention of network window systems, certain propeller heads who confuse technology with economics will start foaming at the mouth about their client/server models and how in the future palmtops will just run the X server and let the other half of the program run on some Cray down the street. They’ve become unwitting pawns in the hardware manufacturers’ conspiracy to sell newer systems each year. After all, what better way is there to force users to upgrade their hardware than to give them X, where a single application can bog down the client, the server, and the network between them, simultaneously!
The database client/server model (the server machine stores all the data, and the clients beseech it for data) makes sense. The computation client/server model (where the server is a very expensive or experimental supercomputer, and the client is a desktop workstation or portable computer) makes sense. But a graphical client/server model that slices the interface down some arbitrary middle is like Solomon following through with his child-sharing strategy. The legs, heart, and left eye end up on the server, the arms and lungs go to the client, the head is left rolling around on the floor, and blood spurts everywhere.
The fundamental problem with X’s notion of client/server is that the proper division of labor between the client and the server can only be decided on an application-by-application basis. Some applications (like a flight simulator) require that all mouse movement be sent to the application. Others need only mouse clicks. Still others need a sophisticated combination of the two, depending on the program’s state or the region of the screen where the mouse happens to be. Some programs need to update meters or widgets on the screen every second. Other programs just want to display clocks; the server could just as well do the updating, provided that there was some way to tell it to do so.
The right graphical client/server model is to have an extensible server. Application programs on remote machines can download their own special extension on demand and share libraries in the server. Downloaded code can draw windows, track input events, provide fast interactive feedback, and minimize network traffic by communicating with the application using a dynamic, high-level protocol.
As an example, imagine a CAD application built on top of such an extensible server. The application could download a program to draw an IC and associate it with a name. From then on, the client could draw the IC anywhere on the screen simply by sending the name and a pair of coordinates. Better yet, the client can download programs and data structures to draw the whole schematic, which are called automatically to refresh and scroll the window, without bothering the client. The user can drag an IC around smoothly, without any network traffic or context switching, and the server sends a single message to the client when the interaction is complete. This makes it possible to run interactive clients over low-speed (that is, slow-bandwidth) communication lines.
Sounds like science fiction? An extensible window server was precisely the strategy taken by the NeWS (Network extensible Window System) window system written by James Gosling at Sun. With such an extensible system, the user interface toolkit becomes an extensible server library of classes that clients download directly into the server (the approach taken by Sun’s TNT Toolkit). Toolkit objects in different applications share common objects in the server, saving both time and memory, and creating a look-and-feel that is both consistent across applications and customizable. With NeWS, the window manager itself was implemented inside the server, eliminating network overhead for window manipulation operations — and along with it the race conditions, context switching overhead, and interaction problems that plague X toolkits and window manager.
Ultimately, NeWS was not economically or politically viable because it solved the very problems that X was designed to create.
Honestly, every time this topic comes up, I feel like the person complaining just doesn't want to put in the work and they are angry that they don't get an easy win. And maybe that's a good thing. Do we really need more half baked WMs?
> Although, I do not know for sure why the original Wayland authors chose to combine the window manager and Wayland compositor, I assume it was simply the path of least resistance.
why? because the compositor completely changed the geometry of the desktop. being 3-dimensional. now, today most wayland compositors are 2 dimensional, but they don't have to be. a window manager that works with a 2 dimensional compositor would not work with a 3 dimensional one and vice versa. the window managers listed in the article are only compatible with this particular compositor.
it seems to me that separating window managers from compositors from the start would have created the expectation that all window managers work on all compositors. that is not and will not be the case.
if all compositors start separating out the window manager then the result would be that as a user i now have to choose two components, a compositor and a window manager, and i have to make sure they are compatible.
Sure, X11 has warts but I can make it do basically anything I want. Wayland seems like it will always have too much friction to ever consider switching.
Furthermore, getting stuff like VRR on Wayland working is way easier than X.org. And, Wayland also supports HDR.
The migration was a one way thing. Lots of things are smoother and simpler, and not having to ever again touch Xorg.conf has improved my quality of life.
To this day, I still have different monitors with different scale factors.
Unfortunately you will never find yourself in a situation to actually use a mixed dpi X11 setup (you lose your homogeneous desktop) and Wayland is better at spoofing it (for whatever reason fractional scaling works better in Wayland).
http://wok.oblomov.eu/tecnologia/mixed-dpi-x11/
My favorite quote from that writeup.
"If you think this idea is a bit stupid, shed a tear for the future of the display servers: this same mechanism is essentially how Wayland compositors —Wayland being the purported future replacement for X— cope with mixed-DPI setups."
Doing some basic mathematics and xrandr command-line wizardry to apply scaling factors to each display, I was able to get Xorg to render to a virtual framebuffer and treat the monitors as appropriately scaled windows onto it, so that dragging applications from one screen to the other didn't result in any noticeable change in size.
Worked pretty well.
I haven't touched xorg.conf in decades. I suppose you might have to do it to configure some unique setup, but for me this hasn't been an issue in a long time.
Now with Wayland, instead of having to touch a single config file, we have to learn how each compositor/WM is configured, and do it there instead. It hardly seems like an improvement in that regard, IMO.
There's a type of input called "DeviceEvent" which is a bit lower level than "Window event". It also occurs even if the window isn't "active".
Windows and X11 support this, but Wayland doesn't except for mouse movement. I noticed my program stopped working on Linux after I updated it. Ended up switching to Window Events, but still kind of irritating.
Meanwhile if you have root you're still free to do so directly.
How does this make any difference if they're going to connect to the same IPC that handles input/display?
The display server must absolutely enforce some kind of security boundary between clients. Clients that are running untrusted code (e.g. a web browser) must not be able to hijacked into controlling a potentially privileged client (e.g. a root terminal).
X11 can't do high refresh rates every time that I've tried to do so.
That’s not a reason to do it of course, for me the driver was support for multiple monitors with different scaling requirements.
But obviously be pragmatic, if it doesn’t work for you because you have a particular requirement, or even if it doesn’t offer any improvement over what you have then don’t use it.
Granted, my requirements were simple, a laptop and occasionally one external monitor, though the issues I did run into were related to graphics drivers and NVIDIA shenanigans, but not to X11.
Now that I'm on Wayland, I do feel that visuals are slightly more responsive and crisper, but honestly, it wasn't worth replacing a bunch of my programs, significantly altering my workflow, and dealing with numerous new issues I didn't have to deal with before.
Unfortunately, the momentum is now fully with Wayland, and it's only a matter of time until X11 stops being supported altogether. The XLibre project is a noble idea, but a few contributors can't maintain an entire ecosystem on their own.
It will take years to reach the feature set of X11. And for what? From my perspective as both a developer and a user, I see no tangible benefits.
On top of that, it breaks software I rely on professionally. Code that worked perfectly fine under X11.
Meanwhile, I can still build and run Windows programs I wrote 30 years ago on Windows 11.
I am not saying all of the design is corporate-controlled. But a ton of propaganda is associated with how wayland was advertised, until some folks had enough with it and decided to stop buying the "xorg is dead" routine these corporations push on:
https://github.com/X11Libre/xserver
It will be interesting to see what will happen though. The GTK devs said they will help kill off xorg with GTK5. KDE also wants to kill xserver. It would be kind of cool if that would not happen - imagine if a non-corporate controlled ecosystem would emerge. Not likely to happen, but it would be a lot of fun. As well as more real competition with wayland. Wayland broke its biggest promise: that it is a viable alternative to the xorg-server. I don't want to lose any feature, so it is a drawback for me.
But already a majority of Linux desktop users have stopped using it. And it will be 90% in the next 2-3 years. GNOME, KDE, Budgie, and COSMIC are effectively Wayland only now and XFCE and Cinnamon will be Wayland native before then.
The GTK5 devs do not have to “kill off” X11. But it is not really worth their time either.
Keep using Xorg, or Xlibre, or Phoenix. It should keep working.
But don’t mind if the rest of us keep building on Wayland.
By the way, I use Niri, a very cool and absolutely non-corporate Wayland compositor. Not sure how that fits into your narrative.
I'm not anti-Wayland and I think X11 has enough issues that it's worth transitioning over to something better but this is a critical weakness in Wayland's design.
Or build on River as this article suggests.
https:/github.com/X11Libre/xserver
I don't really get why would it be a good idea to somehow mandate a specific architecture design from the standard.
Every "flexible" API turns into a leaky mess unless someone is paid to write the dullest test suite in existance, and nobody is. Mandating one design is ugly, but pretending composition is free is a fairy tale.
Wayland in general had a rather cavalier approach to doing away with things that X users take for granted, like, well, making screenshots. Eventually, under pressure, those in charge agreed that these features are actually very important for real users, so implementations appeared. It's an understandable way to discover the minimal usable subset of features, but the process of it is a bit frustrating for the early adopters.
Indeed - implementations, plural. Incompatible with each other, naturally.
As a concrete example, Emacs' EXWM package works by implementing an X11 client library in Emacs Lisp, then using it to talk to the X server (which is a separate process, so this works fine) and telling it how to position windows.
Whereas on Wayland, this is not possible without re-implementing a standalone compositor process, because otherwise architecturally it doesn't work. Emacs can't both do the drawing and be drawn.
So it is architecturally possible (but infeasible in plain Emacs Lisp).
For river (the thing this article is about) I wrote an Emacs WM, but also opted for a dynamic module for the Wayland protocol parts: https://code.tvl.fyi/tree/tools/emacs-pkgs/reka
This one could technically be written in plain Emacs Lisp, but I'm happy to use something that already has all the XML codegen stuff for Wayland figured out. Dynamic modules work pretty well, fwiw.
It's not easy and the major compositors (Gnome, KDE) are NOT wlroots based, making this point mostly moot anyway.
This protocol at least has a chance of using a custom WM with an advanced compositor (which wlroots is not).
I'm glad River is trying to create a bigger base here; this is way cool. And it sort of proves the value of Wayland: someone can just go do that. Someone can just make a generic compositor/display-server now, with their own new architecture and plugin system, and it'll just work with existing apps.
We were so locked in to such a narrow limited system, with it's own parallel abstraction layer to what the kernel now offers (that didn't exist when X was created). It's amazing that we have a chance for innovation and improvement now. The kernel as a stable base of the pyramid, wlroots/sway as a next layer up, and now River as a higher layer still for folks to experiment and create with. This could not be going better, and there's so much more freedom and possibility; this is such a great engine for iteration and improvement.
I wonder if there’s space for a project like xlibre (or x.org, if it were revived) to update the x11 protocol to fill whatever gap compositors were meant to fill.
For what it’s worth, I’ve been moving all my machines to lxde.
Apparently, I accidentally switched back to a compositor free desktop without noticing. High framerate, vsync/tear-free and high dpi work fine. So does fractional scaling, but I disable it.
Personally, I’d rather these hypothetical x11 devs focused on reverse engineering hdmi vrr (blocked by lawyers at the moment), and HDR / expanded color spaces.
Any gotchas or regrets?
Haven't used it in many years and now considering going all in on making it (scaffolding of) next DE. So looking at the same move.
note that compiz is also a windowmanager, so already then compositor and window manager were one unit.
The X windows paradigm was fine, and still works great with modern hardware.
However if you really really really wanna side step this you can look at keyd - https://github.com/rvaiya/keyd
A project that has a daemon run in the background as a root service and that can provide an appropriate shim to pass key strokes to anything you want.
And just to be clear the appropriate secure model is to have a program request to register a "global" hot key and then the compositor passes it to the appropriate program once registered. This is already a thing in KDE Plasma 6 and works just fine.
That's kind of a big sticking point. When GNOME, KDE, and eg. Sway all have different screenshot APIs, the (eco)system doesn't work.
In effect the modern desktop is wayland (window communication), pipewire (audio/video), and xdg-desktop-portal (compositor/environment requests) which all kinda have to be worked with for a desktop application.
I've been heard!
Separating the compositor and window manager feels like one of those ideas that seems obvious in hindsight, but the protocol/state-machine design here shows why it took real work to make it practical.
Lowering the barrier for writing Wayland window managers without forcing everyone to build a full compositor seems like a big win.
I've been working in the tech field for a while, but I'm new to HN. I'd never explored the platform in depth before, and recently decided to start participating and interacting with people here.
The discussions and knowledge shared here have already been very valuable to my own learning. So I hope to contribute to the community in the same way... but I felt I needed to be more active in the community before that.
If anyone is curious or still has questions, I can also share my LinkedIn or GitHub.
i'm a little thrown, because the Wayland diagram doesn't feel quite right. the compositor does lie between the kernel and the apps, but IIRC the apps have their own graphics buffers from the kernel that they are drawing into directly. the compositor then composites them together. to me, that feels more like the kernel is at the center of the diagram here: the wayland compositor is between the kernel and the output / input.
i don't think it has a huge impact on the discussion here. but this is such a key difference versus X, that i think is hugely under-told: Wayland compositors all rely on lots of kernel facilities to do the job, where-as X is basically it's own kernel, has origins where it effectively was the device driver for the gpu, talking to it over pci, and doing just about everything. when people contrast wayland versus X as wayland compositors needing to do so much, i can't help but chuckle, because it feels like the kernel does >50% of what X used to have to do itself; it's a much simpler world, using the kernel's built-in abstractions, rather than being multiple stacked layers of abstractions (kernels + X's own).
it means that the task of writing the display-server / compositor is much much much simpler. it's still hard! but the kernel is helping so much. there's an assumed base of having working GPU drivers!
author appears to super know their stuff. alas the FOSDEM video they link to is not loading for me. :(
one major question, since this is a protocol, how viable is it to decompose the window management tasks? rather than have a monolithic window manager, does this facilitate multiple different programs working together to run a desktop? not entirely sure the use case, but a more pluggable desktop would be interesting!
It's also possible to use hardware planes to get the actual graphics device to composite for you directly from its video memory, effectively reducing latency to the lowest possible.
Are you an AI bot? Modern X11 server using DRM are more than 20 years old. You are talking about how X11 servers worked in the 90's
To the previous a-hole, frak you: not an AI. That's rude as frak. Also, you manage to be incredibly wrong. Even an AI wouldn't overlook such an obvious error; maybe it'd be better to have it replace you. So rude dude! Behave!
It's vastly deeper than what Wayland does.
I switched to niri a few months ago, and while I like it for the most part, it feels too... busy for my taste. It defaults to a bunch of animations and decorations, all of which I've turned off. I'm happy with my current setup (aside from Wayland quirks[1]), but river's design and simplicity are very appealing. It reminds me of the philosophy of bspwm/sxhkd which I used for years on X11.
I do need scrollable tiling now that I've tried it, and I'm happy that there are a couple of options to choose from with river.
[1]: Seriously, why does copy/pasting sometimes simply not work?? I often have to copy twice for it to succeed. It's not related to Xwayland -> Wayland apps, and viceversa, or with copying from closed windows, etc. I don't use nor want a clipboard "manager". I just want my clipboard to work consistently. I've read many reports of this same bug on different distros and DEs, and nobody has figured it out. It's infuriating that such a basic feature is half-broken in a project that is 17 years old now!
I think that's pretty unlikely. The smaller compositors actually collaborate fairly well, and if sway, hyprland, niri, KDE etc. decide to implement this, I think they will probably work with river to create a standardized protocol that works across compositors. That has happened before. Hyprland is maybe more likely to do their own thing than the other, but if a standardized protocol caught on I think they would follow that.
Gnome though... I don't think there is a great chance they implement something like this even if several other compositors implement a standardized protocol for it.
Sure I agree that wayland (the project) could have provided these abstractions much earlier. But anyone else could have done it, too. We get all of this for free, so we shouldn't complain if other people don't do the work that we could do just as well.
They took a firm principled stance against screenshots to start with, which set them up for the COVID WFH wave. Then we've got this questionable design that seems hard to make accessible since accessibility is a security risk and we're heading right into Agentic AI which will be interesting. I've been avoiding the Wayland ecosystem for as long as I can after the initial burn and it'll be curious to see how well it supports bringing in new AI tooling. Maybe quite well, I gather that Pipewire is taking over the parts of the ecosystem that Wayland left for someone else and maybe the community has grown to the point where it has overcome the poor design of Wayland's security model by routing around it.
My guess is the frustration is coming from a similar perspective because it is a bit scary seeing Wayland getting picked up everywhere as a default and the evidence to date is they don't really consider a user-friendly system as a core design outcome. Realistically Wayland is 2 steps forward even if there is a step back here or there. The OSS world has never been defined by a clean and well designed graphics stack.
As ordinary user, I actually don't care about any of this. However, from another perspective, I think this is a bad thing—open source projects have become product-centered, defaulting to the assumption that users are ignorant fools. This isn't how community projects should behave, but those projects is not that community-driven anyway.
After all, for a long time, so-called security has only been a misused justification—never letting users make mistakes is just a pretty excuse, meant to keep users from being able to easily access something, and eventually from ever accessing it at all.
That they provide this stuff for free would be a good argument if the stuff wasn't pushed down people's throats with no working alternative and Xorg being discontinued.
because the devs actually have implemented things that i cared about
The problem isn't they "pushing stuff down your throats", it's nobody else (including you) making alternatives that you like better. You are voluntarily ingesting their stuff because your only alternative is starving.
It's a forcing of their narrow opinion on what should be allowed onto the ecosystem at large, because all of these things are connected. You can leave to a different DE/distro, but if every DE is doing its own thing for global hotkeys or whatever, then software in the ecosystem is going to be hacky/bespoke or have an unreasonable maintenance burden.
Even if you in particular can move elsewhere the ecosystem is still held back. We only recently got consensus on apps being able to request a window position on screen, which is something x11, macos, and windows all allow you to do. CSD and tray icons are other examples of things found everywhere else that they did not want to support. Some applications are just broken without tray icon support.
This bleeds over into work for folks releasing software for Linux in general. By not supporting SSD they were pushing the burden of drawing window decorations onto every single app author, and while most frameworks will handle this, it's not like everyone is using qt or gtk. App authors will get bug reports and the burden of releasing software on Linux needlessly climbs again.
Hard to convey how unreasonable I feel their stance was on tray icons / SSD. It should be the domain of the DE from a conceptual but also practical point of view, even from just the amount of work involved. It reminds me of LSP's enabling text editors to have great support for every language. And again, Gnome was the odd man out in this, they want extra attention and work when Linux is the lowest desktop marketshare by far, and they themselves are not the overwhelming majority but they are large enough that you really do need to make sure your software runs well on Gnome even if you want to support Linux.
People think Gnome push stuff down your throat because they have the power and influence to impact the ecosystem, and they use that power and influence to die on absolutely absurd hills.