Separating the Wayland Compositor and Window Manager
64 points by ifreund
64 points by ifreund
Congrats on the release!
Looking forward to getting the new river packaged in nixpkgs, though it's still waiting on the current staging cycle. If anyone needs it, here's a derivation.
Wayland compositors really are an order of magnitude (at least!) harder to write than an X11 WM. Projects like niri and EWM have a lot of code simply because they must, the compositors do way more stuff! For just trying some ideas this is a huge barrier to entry.
River's new WM protocol basically solves this. I wrote reka (Emacs-based WM) for it and have been using it for two weeks or so, while hanging out in river's IRC channel. There's people with new ideas and new WM implementations almost every day, and getting up & running is pretty easy in any language that has decent Wayland protocol bindings.
I've got an idea that I am working on very slowly on a back burner about a Wayland compositor that would talk enough X11 to use an X11 window manager to manage Wayland windows. I would like to do it mostly for fun. Minimally I would like to support dwm and maybe WindowMaker. The problem with this idea is that to support WMs it has to implement some X11 drawing, but maybe there is a way to make Xwayland do that part.
River is my reference in terms of Wayland, because it seems already like the half the work needed for the idea.
Have you looked at Wayback ( https://wayback.freedesktop.org/ )? I'm curious how that compares to what you have in mind, or if it would be a piece of the puzzle.
IIUC Wayback is an X11 server, that is more like an extension of Xwayland for rootfull X (full desktop) and it doesn't handle Wayland clients. My idea would be to make it as thin layer as possible for Wayland clients, so a different way around.
Oh, I'm getting it now! That's a good point about Wayback not being suitable if you're still wanting to manage windows of Wayland applications.
If I wanted to run Wayland clients inside an X11 session I would spend my time working on a kind of "reverse Xwayland" that presents a Wayland client to the X11 server as if it were an X11 client.
There's nothing technically challenging about writing such a program, Wayland's policy over mechanism approach means translating from Wayland to X11 is far easier than translating from X11 to Wayland as Xwayland needs to.
I suspect that at least one person has done work in this direction before...
I know that that would be easier, but also far less interesting for me. Because there are X11 desktops, there are a lot of X11 client binaries, but most Wayland clients are also X11 clients or you already can just run a Wayland compositor with an X11 backend.
At least with translating X11 to Wayland we could retain some of Wayland goodies.
I guess it comes to value judgment on the tradeoffs of each solution and apparent coolness.
About 15 years ago I was stuck with poorly supported integrated NVIDIA graphics that would occasionally freeze up when using GNOME Shell, and as a stopgap I tried a few tiling window managers to reduce graphical load. I remember really enjoying ratpoison and xmonad in particular, though at this point I don't remember exactly why. I've since avoided NVIDIA and enjoyed Wayland (mostly GNOME) for nearly 10 years, but seeing this work makes me interested in trying out some of these ideas again. I see there are ratpoison- and xmonad-inspired options that use river.
I also love the look of Canoe as someone whose first GUI experiences were on Windows 3.1.