Hi!

Done homework, looked existing issues before posting

This request is related with, though different from, #30 , and more remotely to #13 .

Observed situation

I've been using quicktile for a long enough time and observed I converged to always purposefully press an "unwanted" key combination then the intended combination. For example: "maximize" then "left half", when I actually mean "left half".

Why?

• All those key combinations are not one-shot. They actually cycle through states: the "obvious" state, and others (1/3, 2/3).
• I very rarely want the 1/3 or 2/3 state.
• 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.
• 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.

Acknowledging the difficulty

You explained well here and IIRC in other places why it's so difficult to figure out if a window is already tiled.

Perhaps a good solution would be to look in a different direction.

Thinking aloud

What if we considered something very simple, just give up the complexity and restore the main point: predictability?

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

Here's a suggested logic:

• quicktile maintains a "state" variable, not even one per window, just one global
• when quicktile is summoned, if more than 5 seconds (configurable) were elapsed since last time, reset state
• when quicktile is summoned, if the focused window ID is different from last one, reset state
• switch state following one step of this logic diagram: (reset)->(main)->(1/3)->(2/3)->(go back to main).
• apply the action corresponding to reached state: "main" is the obvious one (maximize, or tile to half-side or quarter-corner), "1/3" and "2/3" are the other existing actions.

Benefits

• No more complicated guesswork depending on window managers, special windows that snap, etc, etc.
• Predictable!

Suggested documentation wording

Before

Usage (Typical)

• Focus the window you want to tile
• Hold the modifiers defined in ModMask (Ctrl+Alt by default).
• Repeatedly press one of the defined keybindings to cycle through window sizes available at the desired location on the screen.

After

Usage (Typical)

• Focus the window you want to tile
• Hold the modifiers defined in ModMask (Ctrl+Alt by default).
• Press the key combination to get the main wished effects: maximize, left half, right half, top half, bottom half or one of the four corners.
• (optional) press once more if you actually want the 1/3 variant.
• or twice more if you actually want the 2/3 variant.

Why is the "after" behavior simpler for the user?

• The beginner user can just press once and not even care about the "extra" states.
• The advanced user just has to remember: half, 1/3, 2/3, and press once, twice or thrice, get what they mean.
• For all users: nothing to check, works all the time.

And for maintainer: simpler logic, less code, less complexity.

Conclusion

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

What do you think?