At this point, take all the lessons of wayland, plan everything in advance rather than incrementally deciding basic things like screenshotting and then build something new, superseding wayland so that power users like me and app developers will stop clinging to X. Right now I have no confidence in wayland and I know I'm not alone.
Separating the Wayland compositor and window manager
71–80 of 228 posts
Re: Separating the Wayland compositor and window manager
#72The 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.
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 cr…
https:/github.com/X11Libre/xserver
Re: Separating the Wayland compositor and window manager
#73Re: Separating the Wayland compositor and window manager
#74The 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.
Re: Separating the Wayland compositor and window manager
#75I've never used a system with Wayland (been on i3 for ~15 years) but every time a project like this comes up, I have to wonder why Wayland is even a thing. So many hoops to jump through for things that should be simple. Sure, X11 has warts but I can make it do basically anything I want. Wayland seems like it will always have too much friction to ever consider switching.
I am not saying all of the design is corporate-controlled. But a ton of propaganda is associated with how wayland was advertised, until some folks had enough with it and decided to stop buying the "xorg is dead" routine these corporations push on:
https://github.com/X11Libre/xserver
It will be interesting to see what will happen though. The GTK devs said they will help kill off xorg with GTK5. KDE also wants to kill xserver. It would be kind of cool if that would not happen - imagine if a non-corporate controlled ecosystem would emerge. Not likely to happen, but it would be a lot of fun. As well as more real competition with wayland. Wayland broke its biggest promise: that it is a viable alternative to the xorg-server. I don't want to lose any feature, so it is a drawback for me.
Re: Separating the Wayland compositor and window manager
#76Earlier quoted context omitted.
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 proce…
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-p…
Re: Separating the Wayland compositor and window manager
#77Earlier quoted context omitted.
> It seems like instead of introducing another IPC protocol like this project does It doesn't introduce a new IPC, it uses the Wayland protocol with the river-window-management-v1 extension. The extension mainly defines new objects and verbs for them, but it's the same protocol. Separate process means that the window manager can be written in any language (even, e.g.: Python).
Interpreters for Python, Lua, etc. can be embedded so using them does not require a separate process.
Re: Separating the Wayland compositor and window manager
#78The 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.
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 cr…
Or build on River as this article suggests.
Re: Separating the Wayland compositor and window manager
#79The 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.
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.