Yeah, that makes sense. It seems like instead of introducing another IPC protocol like this project does, there could be a compositor that loads different window managers as plugins. Then everything is in the same process and there is no need for async communication. Of course a crash in the window manager would take down the compositor, but this is already true for Wayland compositors that combine both.
reply> It seems like instead of introducing another IPC protocol like this project does
replyIt 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.
replyWhat about Emacs? That's the usecase I care about. Until I can get Emacs to manage my Wayland windows ala EXWM, I'm sticking to X.
reply... or the WM loads the compositor, or the WM links to a compositor library (i.e. wlroots). The point is there are options...
replyHonestly, every time this topic comes up, I feel like the person complaining just doesn't want to put in the work and they are angry that they don't get an easy win. And maybe that's a good thing. Do we really need more half baked WMs?