Apply Half-Split ratio to corner actions and snap areas

[epicdistraction]

Summary

This changes the corner actions and snap areas to use the same Half-Split ratio preference. It also updates the UI to reduce error from whole number percentages.

This might not be a behavior change that everyone would want, but it has been useful for my workflow. It cuts down the number of repeated-command cycles I use between Left Half / Right Half / Top Half / Bottom Half and the corner shortcuts when using Repeated commands: cycle sizes on half actions

The Half-Split ratio in General -> ... -> Half-Split ratio is now also the default ratio for:

• UpperLeftCalculation
• UpperRightCalculation
• LowerLeftCalculation
• LowerRightCalculation

That means the corner snap areas, plus the Top Left, Top Right, Bottom Left, and Bottom Right shortcuts, now follow the configured Half-Split ratio instead of always behaving like fixed quarters.

With the default 1/2 ratio, behavior stays the same. With something like 2/3, the corners now compose the same split used by the half actions:

• Top Left: 2/3 width x 2/3 height
• Top Right: 1/3 width x 2/3 height
• Bottom Left: 2/3 width x 1/3 height
• Bottom Right: 1/3 width x 1/3 height

This also adds a dropdown for the Half-Split ratio picker so common ratios can be selected directly instead of typed as whole-number percentages. The dropdown reuses the same common values as the repeated-command cycle-size options, so there is not a second hard-coded ratio list. Custom percentages still work through Other.

The matching tolerance is there to avoid precision issues with values like 1/3 and 2/3, and also avoided turning this into a much larger unit test refactor. That may need to change.

Changes

• Add shared half-split frame helpers for leading/trailing horizontal and vertical components
• Refactor half actions to use the shared split helper
• Update corner actions to compose horizontal and vertical half-split components from the existing ratio preference
• Apply the same ratio to corner snap areas
• Preserve repeated-command sizing behavior
• Add a Half-Split ratio dropdown backed by the existing repeated-command common ratio values
• Keep custom Half-Split percentages working through Other
• Keep the existing Half-Split ratio preference keys unchanged
• Add tests for 1/2, 2/3, 3/4, and custom 60% corner ratios
• Preserve existing half-action behavior with tests

ai disclosure: codex was used for the majority of this work. I've reviewed and tested the changes. But, swift & osx apps are a bit outside my normal wheelhouse.

[rxhanson]

Thanks! I like the added dropdown and I think this is a good addition. I'll test this out more thoroughly over the next day or so and let you know if I hit any snags.

[rxhanson]

Ok, so it looks like we need to adjust some of the logic for repetitions. I've noticed that the height on repetitions doesn't remain as half height, even if the vertical split is set to 1/2. I think we want the height to always adhere to the split ratio, and only the width should vary on repetition.

[epicdistraction]

Great catch. I added a feature that locks the cyclic commands to the horizontal or vertical half ratio points. That will allow the corner keys to expand in the direction per the users choice. Although, it probably needs to be renamed and moved to a radio button.

This also cleans up where cycling actions shortcut when using a half ratio can hit a repetitive state and appear to do nothing.

[epicdistraction]

This is ready for review. Updated the label and refactored the code to describe the behavior over implementation.

Thank you for everything that you've done with Rectangle. I've used this and Spectacle since 2013 for who knows how many shortcut invocations a day. Its the number one thing I recommend to someone on osx.

[rxhanson]

Awesome, thanks for continued effort here. I'm thinking that perhaps most people would desire that the corner shortcuts expand horizontally on landscape oriented displays, and vertically on portrait oriented displays, which is the way I think halves work, off the top of my head. In your usage, do you see otherwise? Just thinking through whether or not it makes sense to have that config in there.

[epicdistraction]

After a near-day of rocking the vertical expansion on single 43" 16:9 display, I really like it. That was a nice, happy accident. The majority of users will probably continue using the current horizontal expansion, but it can make sense for some workflows.

It feels a lot more like a dual monitor or L vs R workspace setup in a single screen. The overall behavior is kinda similar to scrolling vertically on a website vs horizontally, except for a whole application.

With the Half-Split ratio set to 2/3 and a 190px stage manager, that gives the left hand side of my setup about a fixed 32" 4:3 screen. The right hand side is about a 24" 9:16 display, and there is a 2"x36" strip at the bottom that is used to "pin" htop, a music player, etc.

The model of my simplified configuration being four corners, the center shortcut, or stage manager for applications to reside. The height of the four corner apps expanding between 1/3, 2/3, or 3/3 with a single hotkey. Then, hammerspoon allows for one more shortcut to send the centered or dock application to the back of the display window index after interaction. There's also contexts.co in the mix to easily bring up any application to the foreground.

There is one more piece of default behavior that I'd like to change after some use. It would be allowing the 1/2 action to be de-selected from the Repeated Commands. It's really, really clean working in thirds everywhere. With even the "half action shortcut` being 1/3 of the whole display after this feature. The 1/2 checkbox in cyclic commands doesn't quite fit into that specific, simplified workflow.

[rxhanson]

Nice, I'm good with leaving that setting in, then.

There is one more piece of default behavior that I'd like to change after some use. It would be allowing the 1/2 action to be de-selected from the Repeated Commands. It's really, really clean working in thirds everywhere. With even the "half action shortcut` being 1/3 of the whole display after this feature. The 1/2 checkbox in cyclic commands doesn't quite fit into that specific, simplified workflow.

I'm ok with that, and renaming Left/Right Half to Left/Right Side. I'll hold off on merging for now.

[epicdistraction]

That was a bit of a load-bearing default check box. It created a few bugs that were also closed out. The weirdest being the application losing focus and ringing the osx bell on shortcut invocation. The fix for that needed the button.refusesFirstResponder = true

This push also has a commit that updates the shortcut actions names, Half Split Ratio configuration option, and the ensures the snap area dropdown uses the correct terms.

The scope of that got a bit messy; since, it included Top Side and Bottom Side with the Side Split Ratio updates. Having Center Half hanging out by itself was kind of odd. So, that has been updated to Center Section.

The second commit also includes a shortcut migration function, but that might not be the best long term solution. I'll happily update if you have a better best practice.

[rxhanson]

Great, thanks!

We'll want to leave the WindowAction names as-is, since this would break people's programmatic calls via the URL API in AppDelegate. Doing this should also remove the need for the migration. Technically, we could add in a way to route the side variances through to the half actions in the URL api or duplicated for defaults, although that doesn't have to be part of this PR.

This did make me second guess whether renaming to sides is the correct path forward, but I think it is the right way to go. Along with this, I'll plan on moving the Side Split Ratio setting into the General tab prior to the next release.

[epicdistraction]

Yeah, it does get kinda sprawling. Does seem like the rename is the only way to stay sane with non-default side ratio.

Pushed an update that goes back to the half/legacy names internally. It also adds a new hook via aliases with the new name for future programatic invocations.