No, not really. Everything that Wayland does is stuff that X11 compositors were already doing. With those the compositor is already taking on all processing of input, and the X11 server is only creating an additional unnecessary step by passing all the input through. Thus why that extra step was removed in Wayland.
But X is two things: a protocol and a de facto standard server that window managers could easily interface with.
I wonder if we’d be in a different place if Wayland as well as offering the protocol also offered a de facto standard server (not simply a reference implementation in weston) with a window manager protocol that more or less forwards on client <-> server messages that a window manager would care about. Client buffers shared with the server can also be shared with the (separate) window manager process which then shares its composited buffer with the server for final rendering.
What we needed was a server and a standard library. Not a barebones protocol for everyone to implement with a different set of bugs.
wlroots showed up too late to the game. Now we have GNOME, KDE, wlroots, and maybe some other implementations floating around out there.
I fail to see why it would not have worked for Wayland.
There is a remote possibility that some person comes along and builds a server and library that will work for everybody. But such things would probably be very large, much larger than systemd. Actually, the closest thing to what you describe is probably a web browser and HTML5, but building a desktop on that seems to be not popular aside from Chrome OS.
> X11 was fine
People with deep knowledge of this area (like Keith Packard) stated the exact opposite many times (that this mess cannot be simply cleaned up and they really did have to start from scratch), but whatever.
Here's one of those articles (I think, but it's been years and I don't want to re-read it just to check):
I put a lot of effort into using Sway and the experience sucked.
> People with deep knowledge of this area (like Keith Packard) stated the exact opposite many times (that this mess cannot be simply cleaned up and they really did have to start from scratch), but whatever.
I never advocated keeping X11 and just doing cleanup. But the solution probably should look more like X11 than it does.
For all that deep knowledge we have a project a decade old, with relatively low adoption and a number of critical blunders along the way (no forethought given to apps that need global keybinds, no forethought to screen capture).
Wayland is shaping up to be a fragmented mess instead of the successor standard that the Linux desktop needed.
Please see this pull request for a description of some of the current challenges with getting global shortcuts to work: https://github.com/flatpak/xdg-desktop-portal/pull/711
>no forethought to screen capture
The plan for a while has been to put screen capture in Pipewire, this is already working for apps that support it.
In any case, X11 also does not have any forethought in relation to hotkeys or screen capture. Technically it has no API for either of those, it has APIs that allow all applications to intercept all keys, and to allow all applications to read the contents of any window. Those APIs can be used to do hotkeys and screen capture in a rudimentary and somewhat broken way but they are not ideal. Just copying those (or an API that looks like those) into Wayland would be an unwise idea.
> The plan for a while has been to put screen capture in Pipewire, this is already working for apps that support it.
> In any case, X11 also does not have any forethought in relation to hotkeys or screen capture
IHMO screen capture and screen sharing are more basic functionality in 2022 than frame perfect. The reason is that if every frame is not perfect we can still understand what happens on our screens. If I can't make screenshots and I can't share the screen I can't work so I will use something else. X11, Windows, Mac, etc.
X11 eventually solved those problems (actually the solution derives by trusting every client of the server) and Wayland will solve them too. But as Wayland started in a world where screenshots and screen sharing were already work tools, one of the very first questions should have been: how do we design both a secure system and one that allows screenshots and screen sharing? If it was asked it wasn't given the right priority.
Having apps to collaborate with Pipewire (which was added later on if I'm not wrong) is bad design. The screen is there, I want to be able to grab it and share it no matter which app is on screen. Those pixels are mine, right?
That did already happen, Weston had a built in screenshot tool. Pipewire was adopted because it was an improvement on the Weston design.
Why is it unreasonable to ask that from a window manager in the general case? The protocol should provide for every basic feature suitable for the problem domain. But these things can be refactored out to third-party libs like wlroots, making a simple window manager implementation similarly easy as under X.
Sounds not like a very modular/orthogonalized approach, and also limiting the choice of the user.
Regarding the issue of "choice", please read this page: http://www.islinuxaboutchoice.com/
I tried to use Sway for a few months (as a regular user of i3) and I ran into too many frustrating issues to want to keep with it.
The greatest problem with the Wayland protocol is how much work a compositor has to do. Requiring every window manager to also have to take on tasks like processing keyboard and mouse input is a massive tradeoff for what Wayland offers.
IMO, we needed something not far off what X11 does. Really, X11 was fine but could use some rearchitecture for modern times and a purge of all the 80s drawing cruft nobody uses anymore. And address the input security stuff.