As a maintainer of xmonad upstream, I'm watching the waymonad project to see where it goes, but I have some concerns about its architecture which I'd love to see addressed before we'd officially endorse people to try switching. This is a copy of a message I sent to fellow xmonad developers a couple months ago:
> We should certainly take a look sooner or later. From a quick glance, I have some concerns about the general design of it:
> It's a compositor and window-manager in one. This is typical for Wayland, but there are lots of disadvantages:
> * Restarting the WM is just like restarting X: session over. Unacceptable for xmonad/waymonad, as we don't reload config, we recompile and restart. Someone is apparently working on making Wayland compositors restartable, in general: https://indico.freedesktop.org/event/1/contributions/20/, though.
> * Another consequence of the WM and compositor being one is that they share memory leaks and GC pauses and signal handlers and whatnot. As much as I love Haskell, I'd prefer frames from an FPS shooter to be presented on screen by something else. Oh and did I mention the compositor/WM also handles input, making any GC pauses doubly painful?
> * Aside from operational issues, this also means all of that needs to be implemented. There's https://github.com/swaywm/wlroots/ (used by waymonad), a library that supposedly lets individual Wayland compositors implement less code, but it doesn't seem to be nowhere near what X gives us: we take care of window management and all the input/output handling is taken care of by other tools with their own configuration and tools. It simply doesn't seem to work that way in the Wayland world. There are other options like implementing a shell plugin for Weston, or possibly other libraries, I don't really understand the landscape.
> I may be wrong on some of these, as I didn't actually try to compile and run the thing.
> Anyway, I am convinced it'd be best if the compositor and WM were separate processes, ideally maintained by separate teams. You know, that old “do one thing and do it well” philosophy. And I have no idea how difficult would it be to make things work this way. If someone were to work on this, discovering the answer to this question would be one the first things to do.
I should probably clarify the wlroots handling IO thing: what I meant is that with Xorg, there are command-line tools like setxkbmap, xinput, xset, xmodmap, xcape, xrandr, autorandr and possibly others that a user can use to interact with the X server and tweak stuff, and from what I understand these don't have equivalents in the Wayland world that would work across WMs/compositors. I could be wrong, though, perhaps wlroots does have a standard protocol for such things and such tools already exist?