[asveikau]

The fact that Wayland can't just substitute out pluggable WMs without changing a bunch of other unrelated infrastructure is IMO one of the biggest user-facing losses relative to X11. Anybody who is working to improve that is doing god's work as they say.

[yason]

Not only a loss but a key disabler. Having used to having the same customized window manager for decades it's impossible to change to Wayland until there's a fully equivalent interface for managing windows so that everything works as I want from mouse clicks to keyboard shortcuts. Maybe it could be an existing window manager adding support for River, or Wayback layer that reimplements an X11 desktop root on top of a minimal Wayland compositor, but none of the current Wayland compositors even scratch the surface of this.

[cosmic_cheese]

It's a damper on development of new WMs and DEs, too. I have ideas for my own desktop I'd like to explore at some point, and if I do it'll almost certainly be X11 based initially because it's so much more quick and easy to wrap one's head around and get the iteration loop up and running with.

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.

[gf000]

How is a WM not just a simple plugin/extension? Find a display server you like and write an extension for it!

[cosmic_cheese]

That would suffice if I were only looking to build a WM, but my goal is a full (lean) DE.

[shevy-java]

The xserver may not be completely dead either:

https:/github.com/X11Libre/xserver

[asveikau]

I'm using X11 every day on my personal machines and don't see a need to switch at this time.

I think x11libre specifically is a little suspicious though. There's nothing wrong with the xorg packages I use today that requires a fork.

[anthk]

Xenocara > Xlibre. Also, the NetBSD guys have a fork too.

[LeFantome]

Check out Louvre. Wayland compositors may not be as hard as you thought.

Or build on River as this article suggests.

[gf000]

You only need a single implementation that exposes an API for running a WM as an extension.

I don't really get why would it be a good idea to somehow mandate a specific architecture design from the standard.

[nine_k]

We need a compositor that exposes everything as an extension. Preferably in a hot-reloadable, tweakable way, say, using Lua (with JIT). And also exposing its APIs in a way that allows having an analog of xdotool.

[Asooka]

Honestly, probably the best Linux GUI stack would look like a root Wayland server (not running as root ofc), inside which are nested a per-user Wayland servers (which can be switched between rendering to a monitor or offscreen for a remote login), inside which is nested an X11 server (which is freed from having to care about hardware), inside which runs a normal window manager.

[hparadiz]

That's how valve's gamescope works. It's a compositor on it's own. Run it inside KDE Plasma and you've got nested compositors.

[ChocolateGod]

Pretty sure Deepins DE uses this model

[wmf]

Pretty close to Wayback.

[preisschild]

You can do that already with libraries such as wlroots or Smithay

[MarsIronPI]

That's not the same thing. It's way easier to write an X11 window manager than to write a Wayland compositor, even with something like wlroots, because the window manager can speak the same protocol that clients speak, and it runs as a separate process.

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.

[tazjin]

EWM implements a Wayland compositor as a native thread spawned by a dynamic module in Emacs, it's a full compositor within the Emacs process: https://codeberg.org/ezemtsov/ewm

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.

[MarsIronPI]

Oh, reka looks interesting. Thanks for linking it. I don't disagree with you about dynamic modules, I just think that EWM's architecture shouldn't be necessary. (In which I think we agree?)

[yjftsjthsd-h]

No, that still requires you to make the whole thing, you just get help. For instance, I've run into a problem where I try some great new compositor that uses wlroots, and even though wlroots has good support for keyboard layouts I can't actually set the layout because the compositor hasn't wired up that functionality.

[jaen]

The article already addresses that...

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

[jauntywundrkind]

Especially with LLMs, the cost here is down significantly. People also drastically over-idealize what making an X window manager entailed: sure X had it's compositor, but you had to build so so much yourself.

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.