Skip to content

✨ Add proportional window sizing for screen transitions#861

Closed
cipher-shad0w wants to merge 4 commits into
mrkai77:developfrom
cipher-shad0w:issue_713
Closed

✨ Add proportional window sizing for screen transitions#861
cipher-shad0w wants to merge 4 commits into
mrkai77:developfrom
cipher-shad0w:issue_713

Conversation

@cipher-shad0w
Copy link
Copy Markdown
Contributor

Closes #713

Implements proportional window sizing when moving windows between displays of different sizes. Previously, windows would retain their absolute pixel dimensions
when transitioning between screens, leading to inconsistent behavior. This PR introduces screen-aware calculations that maintain window proportions relative to
each display's dimensions.

@cipher-shad0w
Copy link
Copy Markdown
Contributor Author

This implementation applies proportional sizing only to standard window positions (halves, quarters,
thirds, fourths, maximize, etc.) when moving between screens.

What's supported ✅

  • All standard positions with frameMultiplyValues (halves, quarters, thirds, fourths)
  • Maximize and almost-maximize actions

What's NOT supported ❌

  • Custom Actions - These will use their defined pixel/percentage values as-is
  • Special actions (center, undo, move, grow/shrink, etc.)

Technical reasoning

The feature checks for action.direction.frameMultiplyValues != nil to determine if proportional sizing
should be applied. Custom actions don't have frameMultiplyValues as they define their dimensions through
different properties (width, height, unit, positionMode, etc.).

@cipher-shad0w cipher-shad0w changed the title ✨ Implement proportional window sizing for screen transitions ✨ Add proportional window sizing for screen transitions Oct 30, 2025
@mrkai77
Copy link
Copy Markdown
Owner

mrkai77 commented Nov 2, 2025

This is a really good attempt at tackling the issue, thank you so much for taking the time to dive into it! Unfortunately, the approach isn’t quite correct. The main sign that this method isn’t ideal is that the preview window would no longer accurately reflect the frame of the window on the new screen. Action frames shouldn’t be calculated inside WindowEngine; its role should focus on executing them instead.

The correct approach would be to calculate the proportional frame within LoopManager.changeAction, right when the user selects the action. This both produces the right behavior and makes the overall implementation much simpler.

While reviewing this PR, I ended up putting together my own solution for the issue, which I’ll be merging (#874). I’d encourage you to take a look at it, I’d be more than happy to walk you through any of the changes if you’d like! Once again, I really appreciate your effort and initiative here. It means a lot that you took the time to work on this :)

@mrkai77 mrkai77 closed this Nov 2, 2025
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.

✨ Moving to next screen should keep window size

2 participants