Make resizing relative, which unlocks progressive positioning

[imagine]

The assignments should be relative instead of absolute, so you can shove a window around, linearly progressing it to where you want.

Then you don't need to assign separate shortcuts for the 4 corners. Just execute two shortcuts.

e.g. for Bottom Left: 1. Left Half 2. Bottom Half

Advancing the logic, if a window is in Bottom Left and you hit "Top Half", it should return to Left Half

(This was the behavior of a now-abandoned window management app I used to use, but I forget which one.)

[rxhanson]

If you figure out the name of that app, let me know and I'll try to figure out what they did (although this is likely something I would rather add to Rectangle Pro). What I'm curious about is where the logic will stop, as in, how far to do you go before it decides not to resize smaller, and there must be a mechanism for backing out what you've done to say, go from left 1/8 back to right 1/4. If someone has already figured out an optimal state machine then that would make it a dramatically smaller problem to solve.

[rxhanson]

With all that said, I'm not trying to hold back Rectangle to make Rectangle Pro more appealing - I can just personally iterate faster on Pro. So, if anyone wants to add anything to Rectangle like this, then I wouldn't turn it down unless the code was terrible. :)

[Aaron-Rumpler]

Window size being small to the point where it's not resizable can't be determined until you resize it and check the size after (unless it's a fixed size window for both width & height). This makes it a little clunky, but still doable. The undo is where I feel like there should be an elegant solution but haven't quite thought it through. It might still end up with some weird feeling behavior no matter how it's implemented.

Hence the 'whether you'd detect that and revert to the size before the resize was attempted or just leave it as is'. 😀

[Aaron-Rumpler]

It is quite a different model to what Rectangle currently uses, where things like say top left sixth would be a composition of maximise, left third, and top half.

This is the main reason why I don't really have strong desire to add it to Rectangle, but can see it fitting in fine in Rectangle Pro.

I tend to agree on that. To me, it almost feels like a model for a seperate app (especially with the undo logic).

As for undo, I think you'd need to have a separate undo action for each action. So to go from bottom left corner to left half, you'd do an 'undo bottom half' action. Otherwise, if you wanted a window in the top half of the bottom left corner, that wouldn't be distinguishable from trying to go from bottom left corner to left half.

The undo is where I feel like there should be an elegant solution but haven't quite thought it through. It might still end up with some weird feeling behavior no matter how it's implemented.

Having dedicated undo actions for each action does allow for some quite powerful behaviour (e.g. you could do a last three quarters snap by snapping right, snapping left (which would snap to the left half of where the window already was, as opposed to undoing the first snap), then a reverse snap center third). And even without those undo actions, halves and third snaps by themselves let you quarter, sixth, eighth, etc snaps both horizontally and vertically (which could be combined separately, e.g. thirds vertically and quarters horizontally). By trying to undo actions by performing the opposite, you end up losing the ability to do a lot of that. But at the same time, I do see the appeal for the sort of undo that @imagine proposed. Ultimately, it seems like it could be quite powerful, if potentially tricky to get used to.

[imagine]

The undo-based spatial model sounds rad, but I misremembered and seem to have invented a new model.

The app I’m remembering was actually a different model that wasn’t as fancy. Left, down arrows gave window in BL corner. Up arrow → window jumps to occupy top half full-width, left arrow gets UL corner. It seems it was simply based on what edges the window was kissing already. I presume that would be simpler to implement.

I also think the edge-based model would be more pleasant to use compared to chunking windows around the screen, annoyingly slow. The one limitation that bugged me about the edge-based model is that it only support corners, doesn't allow for a quarter-height window on the left side centered vertically. But that limitation might be the right compromise of power and snappiness.

It would anchor to the side and on repeated triggers would go 1/2, 1/4, then cycle back to 1/2 similar to behavior currently available in Rectangle. I personally never wanted for more than halves and quarters.

I appreciate that these are different conceptual models from Rectangle’s specificity. I personally think it’s a more intuitive model and value how the shortcuts are minimal and map to the model. I expect it would be a tricky feature to introduce: very complex to surface multiple models in UI, even if research shows it’s generally a superior model there’s existing users who’d struggle. There would hopefully be some design for the UI that would intuitively express the config options.

[rxhanson]

@Aaron-Rumpler (or anyone else) if you feel inclined to create an implementation based on this discussion, let me know if there are any questions I can answer (regardless of if it's part of Rectangle or not). I don't think I will get around to creating an implementation of this in the near term.

[X-Wei]

PR #1824 implements a bounded version of this for the four half actions, in case it helps answer the "where does the logic stop" question: each axis has only three states — whole, docked to the leading edge, docked to the trailing edge — recognized from the window's current frame. The action for an edge docks the window to it; the action for the opposite edge expands that axis back to whole (so a bottom-left quarter goes back to Left Half with Top Half, and Right Half from a left half fills the screen). Nothing shrinks below a half-split on its own axis, and backing out is always the opposite key, so there is no extra state to remember. Untiled windows and repeated executions of a plain half are left to the existing code.