kwinft VS wlstem

You might be interested in the KWinFT project I started few years ago which aims at providing such high-level libraries in the long run.

They have It's much much better

Interesting. If you don't mind, I'm working on KWinFT, originally forked from KWin, and now in the process of splitting out reusable libraries for compositor creation. My goal is to provide desktop-agnostic template libraries, so might be a good fit for you.

All I can think of is the KWinFT project, how that project benifits from this as well.

https://gitlab.com/kwinft/kwinft/-/issues/182 has the opposite

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.