[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.

[rollcat]

> [...] I am skeptical of the idea that any one window manager could accommodate the needs of GNOME, compiz (yay cubes), and dwm.

I am a former dwm user (contributed patches too), and I'd say we represent a group of marginal importance. Suckless is as much a philosophy as it is a lifestyle choice. It proves that simplistic software can be practical, but skims over many in-depth issues, such as accessibility.

Once we get the elitists out of the way, the needs of the 99.99% are not that hard to meet: Windows & macOS combined market share more than proves it; tools like Hammerspoon or AutoHotkey fill the gaps for most power users.

> 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.

Hammerspoon uses Lua; macOS doesn't even ship a Lua interpreter or ObjC bindings.

Also, the majority of the population is not technically competent enough to even care about decisions such as JavaScript vs Guile vs Bash; power users in practice turn out patient enough to put up with garbage like AppleScript, because it gets work done.

The continued prevalence of memory unsafe languages is unfortunate, but a well-written and well-maintained C project used by a million people is going to provide more value than an absolute marvel of engineering, written in Rust, used by a hundred.

[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).

[bee_rider]

Have you looked into it? I believe writing a wlroots compositor to be in the general ballpark of as difficult as writing an Xorg window manager—which is, beyond the type of project I’m likely to take up in my spare time, but at least doable by mere mortals.

[vidarh]

Far more work. I wrote the X wm I'm currently using in a couple of weeks and it's a few hundred lines of code. You can get a working X WM in a few dozen lines or tens of thousands. Mine is ca. 700 at this point (floating+tiling).

I considered wlroots but the complexity is far higher and Im not in a rush to move to Wayland.

[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.

[yjftsjthsd-h]

Ecosystem effects mean that it kind of is. Even if we made the software in question (probably on top of wlroots, maybe even just extending wayfire which IIRC kind of already has the plugin system you need?) there is zero chance GNOME or KDE will use it, and I wouldn't bet even on sway or such.

[vidarh]

Well, if people are using Gnome or KDE they've already largely chosen conformity, so why care about that?

[yjftsjthsd-h]

On the one hand, yes, I'm tempted to just ignore GNOME+KDE because they'll never play nice, and just go build something better without them.

On the other hand, this means that the ecosystem overall stays fragmented and we get an eternal state of "to do X in Windows do foo, in MacOS do bar, and on desktop Linux see this wiki page discussing your options". And while I suppose there would be value in ex. screenshot tools only needing 3 code paths, it would have been nice to only need 1.

[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.

[Izkata]

> If I ever write a Wayland compositor, I'll add an out of process WM interface

This is something I've been wondering for a long time - how long will it take before someone writes a Wayland-based server that provides an interface for window managers, system trays, and whatever other clients running in other processes, mimicking what X does?

[vidarh]

I think the main thing stopping it is that people get "stuck" on the compositor since even writing a wlroots based compositor is far more effort than the bare minimum for an X wm.