Wayland is bad design, and it shows in the users' and maintainers' attrition.
This is not something conceptual about Wayland, or intrinsic to it. Any display protocol can have multiple client/server implementations. It just so happens that most of the free desktop standardized around the X.org implementation for X11, but even for X11 there were multiple client and server implementations.
The second thing is that software duplication efforts have a well known, tried and tested solution: implement the duplicated effort in shared implementations or libraries [1] !
The thing I find hard to wrap my head around is that this complaint is given in a community that usually champions protocol-over-implementations and diversity of implementations. The people actually making a difference on the Linux desktop are damned if they do and they're damned if they don't.
What you want at that point is to agree where to read and write common configuration. I'm not sure this is likely to happen either, as gnome has gsettings/dconf and kde has simple files and you will now awaken the plaintext vs efficiency dragon.
The current situation is just how it coincidentally turned out - there's just not always a clear direction on the free desktop (and that's even what many people like about it). If wlroots or something similar had existed earlier, then this probably would have turned out differently but c'est la vie.
edit: looks like it might already be provided via wl_output::scale [1] except you get the wrong effect that way. You want to tell the client what DPI they should render at, so that you can keep scaling at = 1
[1]: https://wayland.freedesktop.org/docs/html/apa.html#protocol-...
Once that ship has sailed, what you want instead is a shared method of providing configuration. The goal is to have all 3 implementations read configuration (like DPI scaling etc) from one place. That way the user won't have to configure common things in 3 places to get any semblance of apps looking remotely close to eachother.
When people talk about "pushing stuff to the DE" what they mean is the Wayland project aggressively scoping the Wayland protocol to drawing surfaces and handling input events. They're not trying to become a generic desktop message bus for everything an application might want to do -- that's literally what dbus is.
Why not have a shared implementation?
The codebase could be re-engineered, sure, but a lot of people championing Wayland tend to see this duplication of effort as good for some reason, and at least last I engaged with them did not like the idea of a "new X11."
Personally I think something like that is an inevitability.
People seem to like that we have many browser implementations but when it comes to display servers it seems like they want Chrome to rule them all.
Diversity is great but equality in failure is not helpful.
X11 is a protocol. What you mean is that we end up with something like Xorg, an implementation of X11. Which is still incorrect because a major design goal of Wayland is to move as much logic as possible from the server to the client.
I wonder how long it'll take to have a Wayland server running on the AT&T Blit...
It'd still solve a lot of issues that X can't.
Wayland is trying to do one thing well, whereas Xorg did many things poorly. It's valid to feel frustration that the community doesn't coordinate to put those APIs in place, but it's very much not valid to blame Wayland developers for it.
Please be a little bit more charitable: I'm very candid about the usability problems on the Linux desktop, I'm just telling people where they need to send their time, money and concerns to fix it.
> "but that's not our problem!" when something breaks.
Which is the entire point of getting rid of X11. Wayland is a display protocol and does not intend to solve all of the problems that X11 ended up solving, same as the display stack in any OS designed after 1990 (like Windows, Mac OS X, BeOS, Android and ChromeOS) do not solve these problems either.
For a modern example of this in action, see Bluetooth and the madhouse of device 'quirks' you have to settle with day-to-day, since each device has subtly protocol-breaking opinions on how to implement it.
Wayland is a display protocol. Practically all of the pain people are experiencing has nothing to do with how Gnome/KDE/Sway really display things differently. The pain everybody experiences is that the realization that suddenly we need a new input stack too, a new way to screenshare, a new way to do clipboard access, a new way to do a bunch of other things. All stuff that also needs to made, standardized, and achieve maturity outside of the new display protocol.
It's tempting to call that fallout of other stuff that needs to be changed "Wayland" as well, but I'd say that misses the point completely and calling it that won't help anyone get this stuff fixed.
Mind that I have no formed opinion of Wayland myself, having not used it. Trying to deduce probable causes from hearing people duke it out here and elsewhere.
On Linux, there's X11 based desktops and "post-X11" desktops. "Post-X11" would involve implementations of Wayland and Freedesktop Portals [1], using libinput [2] - and some other things I'm forgetting. All these things don't depend on Wayland and run fine on X11 too (heck you can even run a Wayland compositor in an X11 window), but most of this stuff is pretty new, implementations have lots of QA issues, and application adoption is also not fantastic. On X11 you can just talk to the X11 socket directly for what you want as a workaround, but on post-X11 you have to adopt a new means of doing it. And that hurts.
[1]: https://flatpak.github.io/xdg-desktop-portal/portal-docs.htm...
But my requirements are different from yours.
If you've been shooting yourself in the foot all your life, eventually you'll stop noticing that your foot is bleeding.
It would have to rely on compositor and driver bugs in those other platforms.
If no implementation of Wayland is ‘there’, it seems pretty reasonable to say Wayland is not there yet.
I think it can be seen in OP's list that most of the issues that OP raised are actually not due to deficiencies in the display protocol. Specifically replacing of the X11 display protocol with the Wayland display protocol. But Wayland solves fewer problems than X11. So to replace things like standardized screen recording and input processing, you need other things on top of Wayland.
And that's where by far the most issues with "Wayland" come from - stuff that has nothing to do with the display protocol, but the tremendous pains it takes to replace X11.
[1]: It's worth pointing out for fairness that X11 based desktops are also pretty flawed even if you're used to some of the flaws.
Given this, it’s not surprising Wayland has become the name associated with the overall goal.
While technically true, that is a bit of deflection. In some cases none of the compositors have implemented certain things yet.
My biggest issue with gnome is that it doesnt remember where my windows were last time I ran an app. Someone over in way-land probably should have told them that would become a their-problem so it could be addressed it sooner. Same with window decorations, they should be handled by the compositor IMHO. Sometimes a new thing should come with recommendations for use.
Deflection is entirely my point here :) These things are real problems, but they should be fixed in Gnome/KDE/Sway/wherever you find them. Complaints should be addressed there, and not at "Wayland", because "Wayland" can't fix em!
There's a meta-lesson useful here for anyone who doesn't know it yet: modern software has network effects. And the same phenomena you see with other networks apply to software stacks. If everyone else has implemented a protocol wrong, for example, and your software comes along that has implemented the protocol correctly, but as a result your software doesn't work with the existing stack,
a) Odds are, the rest of the world will not change to work with your software
b) New users, using your software, will perceive the problem is your software doesn't work, not that the rest of the stack is wrong and you're the only one that did it right.
Maddening, but it's the nature of complicated systems built by thousands of people in a distributed fashion.
(I can't lay hands on the link right now, but there was an ex-Microsoft engineer who had a blog where he talked about the heroics MS developers would go to every major Windows release making sure their OS was compatible with popular user software. It didn't matter that they were the company setting the rules in their ecosystem... If the latest version of Windows broke Photoshop, they had to figure out why. In that particular instance, it was because Photoshop had gained some performance optimizations by baking binary images of default structs the OS gave it into their code instead of calling the right API to get a struct properly initialized, saving a library call. MS had to reimplement some C++ structures in C so they could maintain the memory image of the relevant structs to avoid breaking Photoshop).
Wayland here ends up often being the scapegoat of a Linux community that looks to want to change but can't sort itself out. The result of blaming these issues on Wayland instead of - mostly - Gnome and KDE means that we're not going to the right places to have this fixed. In terms of bug reports, and contributions of code and money.
[1]: I mean, if you can come to terms with the substantial architectural differences implied by Wayland w.r.t. to X11. But that's a discussion on another level.
People, especially people trying to work done on their computers, usually mean the former.
It still smells, because I cannot load my own web components library or/and my own CSS for use on all sites, so every site MUST reinvent wheel.
When Firefox for Linux used native GTK+ UI elements in web pages, with user theme applied, every web page looked like native applications. It was excellent. Then this feature was cut, because "every page must have the same look on every device/OS combination". F><k. Now every web application tries to reimplement the look of Gnome 2.x, and does it poorly.
Unknowing users can freely associate Wayland with bad vibes due to how KDE and GNOME chose to brand their new compositors but we can do better.
But if Kwin & Mutter aren't quite shit when it was combined with X, but are shit when combined with Wayland, how does that shape perceptions of Wayland?
In an alternative universe there would be Kwin the X11 display server which would replace Xorg. I’m sure it would just be as big riddled and feature incomplete in the early years of its development.
Wayland is the implementation detail in Sway to have a display protocol your Gtk, Qt and XWayland apps use to draw themselves, really no need to draw more attention to it than necessary. It's the Sway implementation that does all the magic.
What most people mean when they "switch to Wayland" is that they're switching from Gnome on X11 to a "pure Gnome" stack that uses Wayland and a bunch of other Freedesktop standards for interopability. There is absolutely no code from the "Wayland project" running there, because the Wayland implementation is Gnome's own (it's called Mutter). Similarly, KDE's implementation is in KWin itself. The source article is from an author of yet another window manager (Sway) implementing Wayland.
What you're observing is not "Wayland not being there yet", it's Gnome not being there yet. All of these deficiencies have nothing to do with Wayland itself: they're general QA issues that plague an underfunded Linux desktop that's making a slow technology transition.