That’s an interesting one I’d missed. Thanks :)
It might just tempt me to ditch bspwm, or at least experiment. I use little enough of bspwm capabilities, so it might be feasible. I have also lightly toyed with the idea of writing my own, as since I don’t use menu bars etc. even on my floating screen (the “menu bars” in my desktop manager are just client rendered titles) I really need very few capabilities. Basically pretty much just a placement function similar-ish to bspwm, and the ability to move and resize and float windows.
On the other hand, a truly minimalist WM is <100 lines, so I might consider writing one from scratch too (I’d need to update the Ruby X11 binding to handle StructureNotify events and add a few more calls, but that’s pretty trivial). Though at this point we’re quickly approaching zealotry :) It would be fun, though. Maybe when I’m done replacing the terminal fully…
Heh, yeah, that’s part of what’s currently keeping me on X. I use little more than a bunch of shells and Chrome, so there’s not many incentives for me to switch. All of my Ruby X tools are very light on the X11 API use, so they’ll eventually be fairly simple to migrate over, but the window manager vs. compositor situation is frustrating.
I’m somewhat tempted to hack together some FrankenCompositor based on wlroots that implements the bare minimum of the X11 protocol to allow an X11 window manager to to manage the windows. The X11 protocol itself is simple, and while making every WM run would be a ton of work, if you first have a Wayland compositor making it possible to run simpler WMs wouldn’t actually necessarily be so bad. Not likely to happen anytime soon, though, it’s not exactly necessary and I’m not that much of a masochist :)
A somewhat more sane variant might be FFI bindings for wlroots so it’s possible to use it to build a compositor, but that too seems an awful lot more work than an X window manager.