Cooperative Window Resizer Feature

[epicdistraction]

https://i.imgur.com/hXlCZfk.mp4

The Cooperative Window Resizer will automatically adjust the windows around it to avoid having to cmd tab and resize.

I ended up cherry picking the commits on a new branch to avoid an annoying rebase.

Summary

• Adds cooperative resizing for repeated side and corner shortcut cycling.
• Adds a new opt-in preference: “Resize adjacent windows when cycling side or corner shortcuts”
• Resizes directly adjacent tiled windows inversely when a repeated side/corner cycle changes the focused window
• Supports co-occupying windows in the same side/corner position so they follow the focused window’s resize
• Makes side and corner repeated shortcuts interoperable across compatible cycle lanes
• Handles clean side-to-corner tiled layouts, including stacked corner neighbors
• Keeps behavior conservative for ambiguous partial overlaps and unrelated floating windows

Testing

• Added frame-math tests for vertical/horizontal expansion and shrink
• Added tests for side actions, corner actions, side/corner interoperability, co-occupying windows, and the 2/3 split-ratio first-cycle regression
• Added regression coverage for partial same-side occupants in a four-corner 2/3 fixture

[epicdistraction]

Cleaned up this branch, reviewed, and it passes functional testing. Ready for 👀

[rxhanson]

Great! So far so good. I'll give it a thorough run-through tomorrow.

[rxhanson]

I have a couple of relatively minor bugs, and if you can't reproduce them then let me know and I can attach logs.

• Terminal window edges require a bit more tolerance to catch since they're window size is governed by line height rather than pixels.
• If a window doesn't resize small enough, then it will overlap an adjacent window and won't continue to resize the adjacent window on subsequent cycles. It's not terrible behavior, but it feels incorrect.

I like it a lot, though, and it's great with the vertical corner cycling.

[epicdistraction]

Good catches! I normally use iTerm and that has a smoother resize behavior. Able to repro with terminal

I also ran into the resize issue last night when using the laptop screen instead of external. That led me down a route to add an extra option for fuzzy matching. That allows programatic switching between mobile screen and tighter matching for higher res in my use-case. I'll narrow down the tolerance to work well in both modes for terminal.

[epicdistraction]

Large commit pushed. Still a WIP.

This resolves the bug whack-a-mole between: nearby tolerances of apps that don't quite fit like terminal, min application heigh and width forcing the grid larger on nearby resize or window resize. It also includes logic to pickup windows that are cutoff by a side split. And allows the gap between windows feature to function with the cooperative window planner.

There is a small bug where the command needs to be cycled multiple to invoke an action when the side split ratio ends up different than the settings entry due to min width. I'll have more time this evening to circle back on that.

[epicdistraction]

other minor issues that I'm tracking. If a min size is too large, it will split the difference and pushing the edge of the cooperatively resized window just slightly outside the grid. Doesn't occur when min size restriced window is the invoking window/corner

also sometimes the behavior to move a window to a corner is a bit aggressive towards the invoking window. Solution will look forward to the difference betweeen the whitespace from the current window location to the screen edges to determine if it should move.

edit: and when dragging a window to a snap corner, it should invoke the cooperative window resizer function in the same method as a shortcut.

[rxhanson]

Sounds good, looking forward to the update. Let me know if you hit any scenarios where it would help to have another set of eyes take a look.

[epicdistraction]

I'm happy with the behavior. The above issues were closed out. It looks super pretty with the gap between windows feature enabled.

edit: Its getting close. The window resolver will redraw a 1/3 to a min size instead of going straight to the min size. The MVP functionality is there. Just has a flash of a redraw. Might be work a follow up pr. Since this is fairly sprawling. I'll be able to spend more time tomorrow.

[rxhanson]

Nice! I'm good with merging when it makes sense and having follow-on adjustments. I'm getting ready to move, so I will most likely wait until early July to push out the next Rectangle release so there's not an immediate rush to get this into a release (although I appreciate the cadence of your work so far).

[epicdistraction]

Moves are always quite stressful. I'll be hoping it goes smooth for ya.

No worries on it taking a bit to get to a release. Probably best for myself and a few others to really utilize it for a bit to potentially find any corner cases. I was thinking about putting a build on my repo's releases. There is quite a bit of functionality that can be extended in various ways through the other configuration options. So. So, it'd be good to have a few friends that use rectangle try before general release.

There is still that minor adjustment for the window resolver to get a single redraw when moving a non min restricted sized application to a corner that is currently min-restricted. It's the same behavior, just slightly cleaner. But, I needed to take a break from that code for a minute. I'll be able circle back on that during the week. Good to either merge or keep this open for that tweak.