Currently unpredictable state cycling, suggest replace with much simpler logic, gains predictability and cognitive comfort. about quicktile HOT 1 OPEN

The issue is, quicktile does its best to guess which of the states is current, then switch to the next. But the logic is unpredictable.

Actually, it hasn't been unpredictable in the strictest sense for a while. It used to detect heuristically, but it currently sets a _QUICKTILE_CYCLE_POS property on tiled windows which stores the index of the current tiling state in the sequence.

That was my solution for things like MPlayer's fixed aspect ratio. (#20)

Most of the remaining apparent unpredictability is just a need for more code to either reset the sequence or reapply the tiling preset in cases like switching monitors (#24).

The whole point of quicktile is to quickly tile windows. If pressing a key combo does what the user means without a doubt, it's a win. If the user has to press, look, press again, look, until the desired state appears, then it's a loss. From a cognitive load point-of-view, it replaces a fire-and-forget action with a act-check-loop-until, which requires different (more) cognitive resources. Like a cache miss in a modern processor.

...but I will agree with this.

What if we replaced all "is already tiled" code with a simple time-base state machine, that just totally ignores the actual window position?

My main concern there is that it's a big change. I can certainly see the benefit, but I doubt I'm the only one to have used the current approach as envisioned and reworking muscle memory like that shouldn't be done lightly.

IMHO this is simpler to the user, more predictable thus less cognitive load, reduces code complexity.

What do you think?

I'll need to think more on it when I'm not half-dead from fighting to fix a broken sleep cycle (the core reason I haven't been working on QuickTile) and sneezing my nose off because sleep deprivation interferes with over-the-counter allergy medication, but I don't think it'll actually reduce code complexity.

Getting and setting properties on the active window is simple (and the getting code is also used for stuff like querying _NET_WM_STRUT_PARTIAL to determine the usable workspace) while QuickTile currently has no code to support timeouts.

Plus, while it's got some race conditions I need to fix, QuickTile does have a "run as a subprocess to process one command, then exit" mode which would rule out some avenues for implementing what you propose. (I'd have to store a bunch of state on the root or active window rather than in local or member variables.)

from quicktile.