-
Notifications
You must be signed in to change notification settings - Fork 78
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Currently unpredictable state cycling, suggest replace with much simpler logic, gains predictability and cognitive comfort. #119
Comments
Actually, it hasn't been unpredictable in the strictest sense for a while. It used to detect heuristically, but it currently sets a 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).
...but I will agree with this.
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.
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 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.) |
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?
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:
Benefits
Suggested documentation wording
Before
After
Usage (Typical)
Why is the "after" behavior simpler for the user?
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?
The text was updated successfully, but these errors were encountered: