Allow smaller to shrink the height of a vertically maximized window - #1807
Open
YuriNachos wants to merge 1 commit into
Open
Allow smaller to shrink the height of a vertically maximized window#1807YuriNachos wants to merge 1 commit into
YuriNachos wants to merge 1 commit into
Conversation
Extends the .smallerHeight curtain exemption (b97a353, rxhanson#1645) to the combined .smaller command so a vertically-maximized window shrinks in both width and height instead of only width. Adds testSmallerShrinksHeightOfFullHeightWindow and updates three existing ChangeSizeCalculationTests expectations that encoded the pre-rxhanson#1737 height-pinned behavior.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #1737.
Problem
Under the combined
.smallercommand, a vertically-maximized window (Half / full-height) shrinks in width but not in height — it stays pinned to the top and bottom screen edges..smallerHeightalready had an exception for this (added in b97a353 / #1645), but.smallerwas left asymmetric, so the combined shortcut cannot shrink a maxed-height window down in both dimensions.Fix
One-line change in
ChangeSizeCalculation: extend the existingagainstTopAndBottomScreenEdgesguard fromparams.action != .smallerHeightto![.smaller, .smallerHeight].contains(params.action)..smallernow mirrors.smallerHeightand lets the height shrink for full-height windows.Behavior equivalence
This is strictly symmetric with the maintainer's own precedent
b97a353(which did the same for.smallerHeight)..smalleris conceptually.smallerWidth + .smallerHeight, so the height component should honor the same edge exception. An adversarial behavior-equivalence review confirmedFIX_IS_CORRECT— the change is more-correct and does not sacrifice a real use case; the only assertions it invalidated asserted the old (buggy) pinned-height behavior.Tests
ChangeSizeCalculationTestsassertions that encoded the old pinned-height behavior (testExplicitZeroDisablesScreenFractionMinimum,testSmallerCanReachExactConfiguredMinimum,testSmallConfiguredScreenFractionAllowsIssueRegressionStep) to the new expected rect (height shrinks bysizeOffset,yadjusts byfloor(sizeOffset/2)).testSmallerShrinksHeightOfFullHeightWindow— a regression test for Smaller/Larger toggle only change width of the window after "Half" and "Center" Size Adjustments #1737 asserting a full-height Half window shrinks in both dimensions.ChangeSizeCalculationTestspass (3/3 in the relevant suite).Note on pre-existing host failures (NOT caused by this PR)
Running the full
xcodebuild testsuite on this branch shows 21 failures inActiveSideSplitRatiosCooperativeTestsandHalfSplitCornerCalculationTests. These are pre-existing host-environment failures: I ran the identicalxcodebuild teston cleanupstream/main(no changes) and got the same 21 failures in the same suites. They are unrelated toChangeSizeCalculation(the only file this PR changes in app code) and are expected to pass on CI's display configuration.Authored by
@YuriNachos. Implementation written by acccc(Claude Code, GLM-5.2) worker under orchestrator acceptance — an adversarial review swarm (logic + behavior-equivalence + test-integrity lenses) confirmed the fix is correct, and the full-suite red was proven pre-existing by running the gate on cleanupstream/main.