cagebreak VS wlstem

There's also a Wayland WM directly inspired by ratpoison! https://github.com/project-repo/cagebreak

That's true for a lot of libraries, you have to maintain the code, I would treat that as a fact of life, It might be worth noting there are some projects designed to provide a high level abstraction over wlroots which might be different: cage -> used by cagebreak phoc -> used by phosh and wayfire -> used by swayfire.

cagebreak as far as i can tell is a one man project (it uses cage to provide a high level abstraction over wlroots).

I also remembered cagebreak (wayland window manager). it uses cage (which is defined as a "wayland kiosk" but might also be used as a high level abstraction over wlroots).

Anyway, like you I also wanted to see how far I could go on Wayland. After trying out a number of wms I settled on cagebreak which is modeled on ratpoison. It's still in early development but worked well enough for me to give it a semi daily driver status. It works really well with emacs too, without the single-thread issue. I went for a pure Wayland experience (without XWayland as well), so I couldn't some apps I normally use - but I was able to create something quite close to my xorg setup.

There's cagebreak, wich is inspired by ratpoison. It's different yo hlwm, but it has the same concept of containers, but every container only have the "max" layout

I haven't seen https://github.com/luamfb/wlstem mentioned in the comments so I'm dropping it here. I'm really hoping something like this takes off. I was also an xmonad user and mostly dislike how sway/i3 does tiling, so I've been also hopig for vivarium, river, hyprland to get to the feature support and stability of sway.

I've tried to remedy this situation by creating a new library on top of wlroots, one that would be made by refactoring sway code to making most of its non-WM and non-sway specific code readily available. My attempt was called [wlstem][https://github.com/luamfb/wlstem]. I've spent a year or so refactoring sway code, only to come to a point that is far, **far** from where I wanted this library to be. For a few months now, I've been telling myself I should get back to work on wlstem, but I haven't, and quite frankly, I won't, because I know full well it might take two or three years to finally get all the features I wanted in wlstem. Not to mention wlstem is using an outdated version of wlroots, which would be even more outdated when I finally finished. And that's before I even wrote a single line of the compositor itself.