Hah. I didn't think this was quite HN worthy at this point - the code is still a mess, and has plenty of bugs.
It is however the wm I actually use since I got frustrated with bspwm and did a very minimalist rewrite of TinyWM [1] in Ruby [2] and expanded it from there. It was painful the first few days until I'd had time to add multiple desktops and the start of a tiling mode. But at this point, it's "almost" pleasant for me.
The warnings are real, though, apart from the initial hyperbole - this is likely to break for you in all kinds of horrible ways still.
[EDIT2: As for a real example of the ways it can/will break: Right now, for some reason, after a restart without changing a single line, it's failing to grab super+buttons to move/resize windows; it doesn't really matter as I have keybindings for it and mostly use those, but, yeah, I'm doing something wrong somewhere and last time this happened the problem just went away by itself]
I use very few applications beyond (my own) terminal, (my own) polybar replacement, (my own) file manager, and a browser, and so once Chrome and my own apps mostly started working ok I've had very little incentive to make sure it behaves nicely with anything else and I know the distinction between different EWMH window types is incomplete and broken - just not in ways that usually affect my own use.
EDIT: Also a couple of quick notes on "design choices" to the extent this has been "designed" rather than accreted: As you can see in e.g. desktop.rb, quite a few places I've chosen to query and filter the top-level WindowManager class for a list of windows matching a given set of criteria. I did that on an experimental basis out of the idea that it was a waste of time to track precise state across multiple objects given that the total set of windows will always remain "small".
So the Window objects know the bare minimum state of the underlying X11 window that it needs to track, and the WindowManager class knows how to map an X11 window id to a Window object.
Other than that I avoid tracking state as much as possible, and even where I track state I try to avoid the need for full precision.
The one other place I must track state is the layout classes. Currently, only the basic tiling layout, which keeps a tree (that is currently a binary tree, but the array of nodes is there because I at one point thought I might allow more nodes) where the leaves keep track of which nodes have a defined place in the layout.
But even there, on updating the layout, I then crudely diff the currently known set of windows vs. the set of windows the layout believes are present and remove/add as needed.
I make a best effort to place new windows on map requests, but if anything breaks for any reason, the layout will "catch" up automatically and new windows will be placed. Given I use this daily while it is in flux and often broken because I've made a change and is testing it "live" on my desktop, this has turned out to be very helpful on occasion.
I can't make up my mind if this method (of constantly querying for attributes of every window) is a crude hack or quite elegant, but it works.
Many other things are not "designed". This is mostly very far from a good example of how to actually do things. E.g. "find_closest" used to pick a window to move to when you want to move directionally in a tiling layout is pretty much guaranteed to be possible to do much better with fewer lines of code once I actually get around to sitting down and thinking about it - the current version was cobbled together in a hurry because I was tired of not having the functionality and it "mostly works" as expected even though it's stupid.
[1] https://github.com/mackstann/tinywm/blob/master/tinywm.c
[2] https://gist.github.com/vidarh/1cdbfcdf3cfd8d25a247243963e55...
It is however the wm I actually use since I got frustrated with bspwm and did a very minimalist rewrite of TinyWM [1] in Ruby [2] and expanded it from there. It was painful the first few days until I'd had time to add multiple desktops and the start of a tiling mode. But at this point, it's "almost" pleasant for me.
The warnings are real, though, apart from the initial hyperbole - this is likely to break for you in all kinds of horrible ways still.
[EDIT2: As for a real example of the ways it can/will break: Right now, for some reason, after a restart without changing a single line, it's failing to grab super+buttons to move/resize windows; it doesn't really matter as I have keybindings for it and mostly use those, but, yeah, I'm doing something wrong somewhere and last time this happened the problem just went away by itself]
I use very few applications beyond (my own) terminal, (my own) polybar replacement, (my own) file manager, and a browser, and so once Chrome and my own apps mostly started working ok I've had very little incentive to make sure it behaves nicely with anything else and I know the distinction between different EWMH window types is incomplete and broken - just not in ways that usually affect my own use.
EDIT: Also a couple of quick notes on "design choices" to the extent this has been "designed" rather than accreted: As you can see in e.g. desktop.rb, quite a few places I've chosen to query and filter the top-level WindowManager class for a list of windows matching a given set of criteria. I did that on an experimental basis out of the idea that it was a waste of time to track precise state across multiple objects given that the total set of windows will always remain "small".
So the Window objects know the bare minimum state of the underlying X11 window that it needs to track, and the WindowManager class knows how to map an X11 window id to a Window object.
Other than that I avoid tracking state as much as possible, and even where I track state I try to avoid the need for full precision.
The one other place I must track state is the layout classes. Currently, only the basic tiling layout, which keeps a tree (that is currently a binary tree, but the array of nodes is there because I at one point thought I might allow more nodes) where the leaves keep track of which nodes have a defined place in the layout.
But even there, on updating the layout, I then crudely diff the currently known set of windows vs. the set of windows the layout believes are present and remove/add as needed.
I make a best effort to place new windows on map requests, but if anything breaks for any reason, the layout will "catch" up automatically and new windows will be placed. Given I use this daily while it is in flux and often broken because I've made a change and is testing it "live" on my desktop, this has turned out to be very helpful on occasion.
I can't make up my mind if this method (of constantly querying for attributes of every window) is a crude hack or quite elegant, but it works.
Many other things are not "designed". This is mostly very far from a good example of how to actually do things. E.g. "find_closest" used to pick a window to move to when you want to move directionally in a tiling layout is pretty much guaranteed to be possible to do much better with fewer lines of code once I actually get around to sitting down and thinking about it - the current version was cobbled together in a hurry because I was tired of not having the functionality and it "mostly works" as expected even though it's stupid.
[1] https://github.com/mackstann/tinywm/blob/master/tinywm.c
[2] https://gist.github.com/vidarh/1cdbfcdf3cfd8d25a247243963e55...