I read the docs of your WM, and it's pretty interesting ! You managed to get a lot done in a short period of time !

Be careful when relying on wmutils though. It looks like your WM is meant to be controlled over EWMH hints, which is the exact opposite of wmutils' goal.

As an example, in your sxhkdrc, you shouldn't rely on `pfw` to act on the active window. "Active" has a special meaning in the EWMH spec, because there is a corresponding attribute associated with it: "_NET_ACTIVE_WINDOW".

The active window isn't necessarily the one that has focus. So as far as you're using wmctrl to perform an action, you should specify ":ACTIVE:" as the window name, rather than relying on `pfw` (and that's one less fork !). This would be more solid, and would fit your WM's philosophy better (fully EWMH controlled).

I took the other path with glazier: having the WM do nothing, besides what wmutils can. I realised that having a tool in wmutils listenning for events ("wew"), is counter-efficient, and doesn't match what wmutils wants to be: A fully stateless set of utilities that directly send its requests to the X server.

Now about your questions ! As I said, wmutils is fully stateless, and doesn't have anything running in the background to track window positions, or whatever.

• changing tiling layout

Back when I was doing tiling, I had a script (tile.sh) that took as an argument the tiling mode (horiz, vert, full, stuff like that). When you run it, it recalculates EVERY window position, and place them according to the window stacking position (the order listed by lsw). the last one (with keyboard focused) was in the "Main area".

• and whether the script auto-tiles windows when changing workspace/group or opening/closing a window.

The only way you have to do it is with "wew", from wmutils-opt. At first I was triggering the tile.sh script on every CREATE/DELETE event. On such event, it would recalculate the whole layout, and windows were changing places according to their new position in the stack.

You can certainly imagine how inefficient and frustrating that can be.

I quickly moved back to calling the tile script manually from keybind or dmenu, ala cwm. This might sound tedious, however, I accommodated to it, and after some time, I liked that every window popped in "floating mode". This way temporary windows don't fuck up your tiling pattern.

• whether window state can switch between floating and tiling, and whether to keep track of its status and position

All windows poped floating. Running the script made every window tiled. Nothing in between (though now that there is "atomx", you can save states on a window. You probably won't though!)

My tile.sh script was written in shell, which means that it sucks to do proper window size calculations (no floating points, etc…). It was also slow to tile every window, so I would only call that script when appropriate, to avoid the flickering effect of the tiling recalculation.

When resizing a window, the other window wouldn't move to fill the remaining space. I tried to script it at some point, and quickly gave up. I cloud resize the master area however, by calling the script with a different percentage size for the master area (you had to make sure that the currently focused window was the main one, otherwise another window would take its place).

This means that tiling worked like in "dvtm". The only control you have is resizing the master window.

• tiling in different workspaces/groups

Please no. Everything was already too much of a pain.


As you probably guessed, I gave up on tiling with wmutils. It is simply not the best tool for the task (I gave up on tiling overall, but that's another topic). Tiling require many calculations per seconds, and for a smoother effect, you gotta send all your resize/move events to the X server BEFORE flushing the connections (so all changes appear at the same time).

wmutils tools, because they work in a standalone maner, need to flush the connection after every call, so every single change is visible, causing the flickering effect.

• monitor boundaries

wmutils has no visibility over what a monitor is, so I wrote randr to do that. It's pretty stupid, but get the job done. By default it prints the geometry of the monitor when the cursor is. Pass it a window id, and it gives the monitor where the window is (top-left corner).

When I switched to a 2 monitor setup, I replaced all occurrence of "wattr whxy $(lsw -r)" with "randr $(pfw) | cut -f 2-5". Simple as that. See my "maximize" script for example (note saving state in the ORIGINAL_SIZE atom 😉):