Skip to content

fix: allow the main window to be resized horizontally#191

Open
git-lucky wants to merge 2 commits into
Starmel:masterfrom
git-lucky:fix/resizable-main-window
Open

fix: allow the main window to be resized horizontally#191
git-lucky wants to merge 2 commits into
Starmel:masterfrom
git-lucky:fix/resizable-main-window

Conversation

@git-lucky

Copy link
Copy Markdown

Why

The main window is locked to 450pt wide and can't be widened, while it resizes vertically without complaint. Transcriptions are often long, so the narrow column makes the history list harder to read than it needs to be.

Root cause

Three independent constraints pinned the width. All three had to go — fixing any one or two alone changes nothing, which is what made this less obvious than it looks:

  1. SwiftUI.frame(width: 450) on the root view set a fixed width, making the content's minimum and maximum identical. .windowResizability(.contentMinSize) then had nothing to resize.
  2. AppKit propertiesadoptMainWindow set window.maxSize width to 450, equal to minSize.width.
  3. AppKit delegatewindowWillResize(_:to:) returned NSSize(width: 450, height: frameSize.height), rewriting the width on every resize attempt.

The third was decisive: AppKit consults the delegate on each resize, and its return value overrides the window's own minSize/maxSize. It also explains the exact symptom — height was passed through untouched while width was hardcoded, so the window resized vertically but never horizontally.

What changed

Before After
SwiftUI frame .frame(width: 450) .frame(minWidth: 450)
window.maxSize.width 450 unbounded
windowWillResize forced width to 450 returns the proposed size
.defaultSize 450 × 650 unchanged
Height range 400–900 unchanged

ContentView already declared .frame(minWidth: 400, idealWidth: 400), so the content was always built to flex — only the outer constraints prevented it.

Existing users see no difference on update. The window still opens at 450 × 650; it simply can now be widened. SwiftUI persists the frame automatically, so a user who never drags it keeps exactly today's behavior.

Tests

5 new unit tests in MainWindowResizabilityTests. The size limits are extracted into AppDelegate.applyMainWindowSizeLimits(to:) so they can be applied to a real NSWindow and asserted, following the pattern already used by isMainAppWindow:

  • testWindowWillResize_honorsProposedWidth — fails against the old code, passes against the new. This is the real regression guard.
  • testWindowWillResize_leavesHeightUntouched
  • testSizeLimits_allowHorizontalResizing — max width must exceed min width
  • testSizeLimits_preserveMinimumWidth — 450 floor retained
  • testSizeLimits_preserveHeightRange — 400–900 retained

Test plan

  • Window opens at 450 × 650 as before
  • Right and left edges now drag wider
  • Cannot be dragged narrower than 450pt
  • Vertical resizing still honors the 400–900 range
  • Size persists across relaunch (SwiftUI frame autosave)

Tim Hise and others added 2 commits July 24, 2026 15:22
The root view pinned a fixed 450pt width, which made content min and max
width identical and left windowResizability(.contentMinSize) with nothing
to resize. ContentView already declares a flexible minWidth, so this only
needed the outer frame to become a minimum. Default launch size is
unchanged.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
windowWillResize rewrote every proposed width to a fixed 450pt. AppKit
consults the delegate on each resize, so that return value overrode the
window's own minSize/maxSize -- height passed through untouched, which is
why the window resized vertically but never horizontally.

Three layers pinned the width; all are addressed:
  - SwiftUI .frame(width: 450) -> .frame(minWidth: 450)
  - window.maxSize.width 450 -> unbounded, via a testable
    applyMainWindowSizeLimits(to:)
  - windowWillResize now honors the proposed size

Default launch size and the 400-900pt height range are unchanged, so
existing users see no difference until they drag the window.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant