[codingkoi]

> the Wayland server

This is the core problem I have with Wayland. There is no "Wayland server", just as there are no window managers. It's _just_ a protocol.

Wayland has conflated those two concepts by making every Wayland compositor have to do both roles. I think most casual users haven't realized this. KDE in Wayland and Gnome in Wayland most likely share zero lines of code (I haven't looked, so I don't know for certain).

That makes targeting it, whatever "it" actually is, with tools for accessibility all that much harder. That's on top of the Wayland protocol's hostility to things that would make that job easier. We've "secured" the system against use by anyone who doesn't have working eyes or hands. There's no malice there, just the unintended consequence of a system designed by able-bodied people. I'm not even sure X is better in this regard, except that there are solutions like Talon that work there.

There are shared libraries like wlroots that can help with consistency, but it doesn't implement everything and not every compositor is using it. Something like accessibility shouldn't be an extension protocol but a core part of the design.

[rollcat]

> This is the core problem I have with Wayland. There is no "Wayland server", just as there are no window managers. It's _just_ a protocol. > > Wayland has conflated those two concepts by making every Wayland compositor have to do both roles.

This is fine. Every windowing system in common use (and a dozen others) took that path. X11 is the odd thing here.

IMHO the actual strategic mistake for Wayland was that they prioritized writing standards over iterating on a working reference implementation that was usable as a daily driver. You shouldn't need an alternative window manager any more than you would need an alternative trackpad firmware. It's supposed to be invisible. Draw the window borders using a plugin/subprocess, because your existing user base demands shallow "customization". Cover the 99% use case, and expose an API for extensions to do stuff like auto-tiling or shader effects. Focus on what users actually need from the applications (like: working screen capture).

X11 - the platform with more window managers and terminal emulators than actual apps. Wayland needn't repeat the same mistakes, but here we are on that trajectory.

> KDE in Wayland and Gnome in Wayland most likely share zero lines of code (I haven't looked, so I don't know for certain).

Close enough. We have kwin, Mutter, and wlroots (the last one effectively doing what Weston should have done from the start) - three disjoint codebases.

Gnome telling SDL2 to link to libadwaita to draw clientside window borders is just cherry on top.

[yjftsjthsd-h]

I'm going to partially agree and partially disagree, I think...

> Every windowing system in common use (and a dozen others) took that path. X11 is the odd thing here.

Every other graphical system did so by tying the protocol to an entire specific software stack; Windows/Android/MacOS/Haiku all require you to use their single official compositor and window manager. I get that you're arguing that's a good thing, but I pretty strongly disagree.

> IMHO the actual strategic mistake for Wayland was that they prioritized writing standards over iterating on a working reference implementation that was usable as a daily driver.

Hard agree, 100% yes; even if they'd just focused on shipping a single working example desktop environment, at least it would have forced them to figure out all the protocols that need to exist.

> You shouldn't need an alternative window manager any more than you would need an alternative trackpad firmware. It's supposed to be invisible. Draw the window borders using a plugin/subprocess, because your existing user base demands shallow "customization". Cover the 99% use case, and expose an API for extensions to do stuff like auto-tiling or shader effects.

I'm less convinced of that; people aren't asking for shallow customization at all, and I am skeptical of the idea that any one window manager could accommodate the needs of GNOME, compiz (yay cubes), and dwm. You'd also bake in technical choices that would sit badly with chunks of the population; odds are that we would have ended up baking most of GNOME into the graphical server and being stuck using javascript for everything, or gone the other way and committed to using C forever.

But overall, I tend to agree; personally I would have liked wlroots to effectively become the unifying point and have been part of the initial release, along with actually shipping most of the needed protocols up front rather than effectively leaving everything except drawing windows as a TODO.

[bee_rider]

From an outsider point of view it looks like the ecosystem would have been much healthier if KDE and Gnome had used wlroots. Get everyone talking in the abstraction so plugins can be written.

[michaelmrose]

Whereas Wayland originated in 2008, sway didn't exist until 2015, Wlroots 2017. This is not when they were ready merely when development begun.

Furthermore it was of vital import for KDE and Gnome to support both X11 and Wayland for years and leverage their large existing codebase. Wlroots would both have to travel back in time like the terminator from 2018/2020 to 2010 and become universally suitable en route.

[silon42]

Personally I don't plan to switch to Wayland without using wlroots based compositor (preferably one I write myself).

[diegocg]

Yes, the lack of an unified server is such a shame. The great selling point of Wayland originally was that it avoided extra context switches by unifying the server and the window manager, this means every window manager must reimplement the server and every protocol by itself. But in an ideal world, we could have had a single Wayland server and window managers being loaded as plugins in the server process.

[nolist_policy]

> But in an ideal world, we could have had a single Wayland server and window managers being loaded as plugins in the server process.

It is never too late to start improving things.

[vidarh]

The overhead is low enough that my current wm is written in Ruby and the WM is nowhere near the hot path for anything. The notion that it's a problem or have the WM put of process is nonsense. If I ever write a Wayland compositor, I'll add an out of process WM interface, because it's far nicer to be able to restart at will without killing apps.