tinywm

uture for Xorg’; these things are arguably true, but they are also rather cruel to say (a bit like ‘inevitably you and everyone will die’: it really is true, but it’s also not at all a nice thing to say). I do think that Wayland or something very like it may be the way forward, but it needs to be an evolution, not a revolution. I know that the party line is that that’s not possible, but I suspect that rather than not possible it is just very hard. It’s always easier to greenfield, and it is always hell to be 100% backwards compatible. But that’s what it needs to be.

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...

t more familiar with the ecosystem a few questions will come up: Should I use X11 or XCB? - I personally used XCB and didn't find it too difficult to interface with, and there are a large number of implementations which use it (2bwm, bspwm, ratpoison, etc) so you shouldn't have an issue with learning more about it. But the documentation is pretty limited. If you are just wanting to write a toy WM than X11 is perfectly fine. X or Wayland? - If you're wanting to write your first WM as a hobby project than I would recommend X over wayland just due to the much larger amount of reference material and documentation. You will have a much easier time getting your feet wet. Ignore the comments about X dying as it doesn't really matter for a hobby project, since the whole point is to have fun. Feel free to check out my window manager which is an example of what just reading this blog post and getting inspired can result in: https://github.com/cfrank/natwm

e windows on a screen. [0]: https://github.com/mcpcpc/xwm [1]: https://github.com/mackstann/tinywm [2]: https://github.com/i3/i3 [3]: https://github.com/paperwm/PaperWM