[Mars-den]

Description

Add local per-app presets for window size, position, and preferred display. The App Default action applies the focused app's preset, with a per-action fallback when no preset is saved. An optional setting applies presets to newly created standard windows without rearranging existing windows.

Includes settings editors, exact-frame Undo, display-disconnection fallback, keybind export/import support, and focused regression tests. Changes are limited to this feature and its stability.

Refs #1179 (approved by the maintainer) and #76. This is intended to cover #76's configurable initial-frame use case. The contributor has confirmed Finder windows opened from Desktop folders, other apps, and mounted devices. Presets are explicitly configured rather than inferred from the last Loop action.

How has this been tested?

• Unsigned hosted build and 57 focused tests passed on macOS 27.0.1 / Apple Silicon, using Xcode 27.0 (27A266a).
• Whitespace and localization-catalog JSON validation passed.
• Contributor-confirmed App Default and Undo smoke tests on revision b55e523: restoring a manually adjusted frame and consecutive Undo after Left Half → App Default, without a duplicate history step.
• Contributor-confirmed Finder windows opened from Desktop folders and other apps.
• Contributor-confirmed Current display targeting and preview/execution consistency across two displays on the latest build (1b13305; code-identical to pre-attribution-rewrite bf05b43).
• Contributor-confirmed manual App Default on Finder windows opened from a mounted device.
• Contributor-confirmed automatic preset size and position on new Finder windows on 9381ee4. Finder temporarily reports new windows as non-resizable; the fix retries the unfinished size once after 350 ms without overwriting an edited window. The contributor observed a visible two-stage move/resize during Finder window initialization.
• Contributor-confirmed explicit named-display targeting on b55e523.
• Contributor-confirmed named-display application and exact cross-display Undo on the latest build.
• Contributor-confirmed named-display disconnection fallback to the connected display and targeting restored after reconnection.
• Contributor-confirmed Accessibility revocation prevents actions and re-enabling restores normal operation.
• Contributor-confirmed repeated-shortcut Undo and consecutive Undo with configured padding on the latest build.
• Screenshots of the App Defaults manager, preset editor, and fallback editor.
• Retest automatic bottom/right preset positioning after delayed resize on d9c8caa.
• Retest URL-triggered Current display with the cursor on another monitor on d9c8caa.
• Final contributor review of the follow-up fixes.

Contributor review identified history identity collisions after shortcut reuse, padding leakage during consecutive Undo, Current display ignoring the cursor-screen setting, and preview/execution display mismatch after cursor movement. All four are fixed; the contributor has confirmed their manual retests. Final contributor review and the listed manual checks are complete. Commit attribution was corrected to Mars-den, rewriting commit hashes without changing code; the attribution-rewritten revision was 1b13305; the latest position and URL-targeting fixes are in d9c8caa. Earlier hashes above refer to the historical revisions on which those checks were performed.

Focused tests were run from a disposable source copy because the scheme's build action rewrites Config.xcconfig:

xcodebuild test -project Loop.xcodeproj -scheme Loop \
  -destination 'platform=macOS' \
  -skipMacroValidation -skipPackagePluginValidation \
  CODE_SIGNING_ALLOWED=NO \
  EXCLUDED_SOURCE_FILE_NAMES=CycleProgressStoreTests.swift \
  -only-testing:LoopTests/AppWindowDefaultTests \
  -only-testing:LoopTests/AppDefaultExecutionTests \
  -only-testing:LoopTests/AppDefaultObserverLifecycleTests \
  -only-testing:LoopTests/AppDefaultMigrationTests \
  -only-testing:LoopTests/AppDefaultURLCommandTests \
  -only-testing:LoopTests/AppDefaultAppResourcesTests \
  -only-testing:LoopTests/AppWindowDefaultsPresentationTests

Existing verification blockers left unchanged: CycleProgressStoreTests.swift uses obsolete APIs and prevents full-suite compilation, hence the explicit exclusion above. Repository-wide SwiftFormat also reports pre-existing docComments violations in ScreenOrder.swift and WindowFrameResolver.swift. These unrelated repairs are deliberately not included.

Screenshots

App Defaults settings and editors

App Defaults manager

Saved apps and the optional automatic new-window setting.

Preset editor

Preferred display and window position controls; size is configured in the adjacent Size tab.

Per-action fallback

The action to use when the focused app has no saved preset.

Checklist

• I have completed my contributor self-review, including the follow-up fixes.
• I have made corresponding changes to the documentation.
• I have no unrelated changes in this PR.

Please describe to which degree, if any, an LLM was used in creating this pull request.

OpenCode (GPT-6.1 Sol) assisted with implementation, review, and automated validation. Contributor self-review and the manual checks listed above are complete; this PR is ready for maintainer review.

[mrkai77]

Thanks for putting this together! Before I take a look, could you complete your self-review and the remaining manual checks? Our AI policy requires contributors to personally review and verify AI-assisted changes before submission. If "pending human review" just means maintainer review, please clarify that and update the checklist!

[Mars-den]

Thanks for clarifying! “Pending human review” means my own contributor review, not maintainer review. I've updated the wording and checklist.

I've tested Finder windows opened from Desktop folders and other apps, and confirmed that explicitly choosing a named display moves the window correctly. My diff review found two Undo edge cases, now fixed in 1875a49 with regression tests; all 51 focused tests pass. The follow-up fixes still need a manual retest.

I'm also checking the Current display behavior with two monitors, since it currently doesn't follow the mouse's display like other resize actions. I've left that unchecked rather than treating it as verified. I'll keep this as a draft until my contributor review and remaining verification are complete.

[Mars-den]

Thanks for your patience! My review caught several edge cases involving Undo history, padding, cursor-screen targeting, preview/execution consistency, and Finder’s delayed resizing and positioning. Those are now fixed, with 57 focused tests passing.
I’ve also completed the remaining manual checks, including multi-display behavior, disconnect/reconnect fallback, Accessibility recovery, automatic Finder presets, and URL targeting.
I also caught that the commits used my other account’s Git identity and had the attribution corrected to Mars-den. The PR was already under the correct account; the history rewrite changed hashes only, not code.
I’m finishing my final review of the latest fixes before marking the PR ready.
Finder made me earn that last checkbox 😅

[mrkai77]

Hey, thanks so much again for all the work on this! I really appreciate that you opened an issue first and tested everything so thoroughly, especially the Finder cases from #76. Unfortunately, I'm going to close this one.

After going through the implementation, it isn't quite how we picture this working in Loop, and it would need a lot more than a few review tweaks to get there. Most of the complexity comes from App Default being a special case throughout the window pipeline, with its own handling in ResizeContext, WindowEngine, WindowActionEngine, WindowRecords and URLCommandHandler. That includes an exact-frame Undo history that only App Default uses, and window targeting that skips the user's "Target window" setting. For changes to the core window code like this, we'd want to agree on the approach before any code is written. I know I said we'd be happy to review a PR in #1179, but looking back, we only agreed on what to build there and never discussed how.

I've closed #1179 as a duplicate of #76, since automatically applying a per-app frame to new windows is exactly what #76 asks for. That's the scope we'd like to focus on. The manual App Default action and its per-binding fallback go beyond #76, so if you still think they're worth adding, please open a separate issue for them!

Also, following up on my earlier comment, even after the self-review the PR still has code like the migration for the removed Save action from an unreleased build. For the next attempt, please make sure it's something you can explain line by line.

If you're still interested, feel free to comment on #76 with how you'd approach it, and we can figure out the right structure together before you start on it. Thanks again :)