Have you considered following dwm's example or configuration-as-code by making the window manager be a zig library? An internal interface would replace the existing protocol (and be a clear place for extensions). This would retain all the latency guarantees but still separate the window management from the compositing.
+1 for a shared tagset. If you use more than one screen, this is a huge improvement. Of course it is subjective, but as someone running a triple-head setup (notebook + two extra screens) I find it a much easier workflow with less "thinking about what I want to do". Focusing a specific tag should be enought, no matter if it's on the current screen or not IMHO.
I apologize if you have answered this question, what is the status bar that you are using? I've spent some time with river the past few days, I have hot keys set up, wallpaper, my 3 monitors are set up with wlr-randr wlr-randr, now I need a status bar, thank you for your work with this project.
If I understood correctly, the compositor has to do all the work (keyboard layouts, mouse settings, screen setting, basically all the things that X11 does itself) and the window manager only manages the windows (where they are positioned, in what layout they are, etc.). River "does the window management" by offloading that task to another binary using some protocol (most, if not all, other wayland compositors do NOT do that) which enables to create separate windows mangers that are used by river just like we could do it for X11 (but 100x better, of course, it's Zig after all)
From my knowledge, a compositor is a program that can do additional processing to the graphical content of windows. Blur, transparency, those fancy 3D effect like windows on the faces of a cube, they're done by the compositor. A WM does everything else that is related to windows. With Xorg, some WMs also do compositors, for others there are standalone compositor like compix. In Wayland it can get a bit confusing since all WMs do their own compositing, so we generally talk about Wayland compositors, not WMs, but they're really compositing WMs.
@@akkesm This isn't quite correct. I'm writing my own Wayland compositor so I've able to get some first-hand experience with these things. Essentially, the model in X11 is that you have your X11 server -- the X11 server itself is what would loosely be referred to as a "compositor" in Wayland terminology. It manages your hardware and creates and distributes resources to clients (any application that wishes to display a window, capture keyboard input, etc.). In X11 there are some special, privileged classes of clients: - the (X11) window manager, which is a special client that the X11 server talks to in order to make decisions about the positioning of windows and a handful of other decisions. These are your i3s and openboxes. - the (X11) compositor, not to be confused with the wayland concept of a compositor (which the X11 server itself is), which the X11 server talks to in order to make decisions about the rendering of windows in some way or another, though I'm not entirely sure on all of the details of how that's done. This is what you're likely referring to. compton/picom is an example of this. - (I believe there are one or two other special types as well, such as input managers, but I don't know as much about them) In Wayland, instead, you write a "Wayland compositor" which sits directly between the clients and your hardware resources. Instead of a providing a standalone piece of software as a server like X11, Wayland provides a thin library and code generator that implements the "Wayland protocol" which your Wayland compositor uses to implement communication with its clients (and the clients use to implement communication with the server). This means that your Wayland compositor has to do much more work than an X11 window manager has to -- in essence, most of what an X11 window manager does is get notified of events and simply tell the X11 server what to do in response to them (and some additional work like creating its own windows to display your window decorations), whereas a Wayland compositor has to actually handle those events and directly perform whatever behavior is desired as a result. What Isaac is talking about in this talk is essentially recreating the idea of an X11 window manager from first principles under Wayland.
