When the window manager is a separate process with async communication between the WM and display server things can get out of sync for a frame or two which leads to visual artifacts. In Wayland the window manager works synchronously with the compositor so that it's never out of sync.

▲

csb6 3 hours ago | parent [-]

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.

▲

WhyNotHugo 2 hours ago | parent | next [-]

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

▲

csb6 2 hours ago | parent [-]

Interpreters for Python, Lua, etc. can be embedded so using them does not require a separate process.

▲

MarsIronPI an hour ago | parent [-]

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

	▲	donaldihunter 13 minutes ago \| parent [-]
		You'll be looking for https://code.tvl.fyi/about/tools/emacs-pkgs/reka

▲

sly010 2 hours ago | parent | prev [-]

... or the WM loads the compositor, or the WM links to a compositor library (i.e. wlroots). The point is there are options...

Honestly, 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?