Wow, this is going to keep me busy for a while. Thanks. > I always thought the way X window managers worked put the cart before the donkey: the client starts f

Wow, this is going to keep me busy for a while. Thanks. > I always thought the way X window managers worked put the cart before the donkey: the client starts first, then the window manager wraps it in a generic frame. I agree, the reparenting stuff is painful and not very clean. Doubly so because you need to be very careful not to "lose" windows that way if you reparent the window and the wm dies (it happened to me once, I promptly put my reparenting code aside and decided that's for later, if ever, since I mainly use nearly no frame at all anyway; it'd be nice if the server just reparented the window back to root if the wm fails catastrophically...). Some recent wm's like Katriawm[1] avoids reparenting even when drawing window chrome by instead carefully putting windows around the client window, which is more robust against catastrophic failure but it just feels icky to have to create multiple windows that you need to move separately whenever moving or resizing the client window. > Instead, they should be more like HyperCard, where the user can build their own stacks that frame and compose and integrate multiple windows together: the stacks come first, and start up and pull in the clients they want to integrate. bspwm kinda, sorta allows something like this if you squint just right, and via a private API by letting you define slots that will "swallow" windows that match the right WM_CLASS, but it's really awkward, requiring a bunch of API calls to define placeholder "receptacles" and then defining rules for which windows will end up in them. There's an "add-on" for bspwm that provides a number of layouts [3], which looks quite decent. But having a nice, clean way for applications to easily do that would be great. I guess you could hack your way around it without needing the WM to be particularly helpful thanks to X's lax security, but it's not very satisfactory. The main reason I decided to toy with my own anyway (apart from what must be a masochist streak) is that I use a very tiny subset of bspwm's functionality and like how that works, but also want to be able to more easily mix in floating windows when/where I want, and bspwm isn't great with that (it supports floating windows, but getting it to handle apps opening new windows in floating mode is a pain. We'll see how soon I regret this decison :) [1] https://www.uninformativ.de/git/katriawm/file/README.html https://www.uninformativ.de/git/katriawm/file/README.html [2] My "todo" desktop consists of tree panes, a todo list on the left, and a "done" list on the upper right and a "notes" list on the lowe right. Each is a terminal window running an editor. To do that with bspwm I had to basically do all of this ($D was set to the selector for the desktop I wanted to put it on) before even opening the terminals. It felt decidedly clumsy, but it worked. bspc node $D:/ -k # Kill any pre-existing windows on that node bspc node $D: -i # Insert a "receptacle" bspc node $D:/ -p east -i # Preselect the right hand side and insert a receptacle bspc node $D:/2 -p south -i # Preselect the bottom and insert a acceptable bspc rule -a todo-todo node=$D:/1 # If the class is todo-todo, assign it to node /1 on the relevant desktop bspc rule -a todo-done node=$D:/2/1 # todo-done assigned to /2/1 bspc rule -a todo-notes node=$D:/2/2 # todo-notes assigned to /2/2