Skip to content

fix: size and center the main window relative to the actual monitor#154

Open
anshul23102 wants to merge 1 commit into
NexGenStudioDev:masterfrom
anshul23102:fix/dpi-aware-window-sizing
Open

fix: size and center the main window relative to the actual monitor#154
anshul23102 wants to merge 1 commit into
NexGenStudioDev:masterfrom
anshul23102:fix/dpi-aware-window-sizing

Conversation

@anshul23102

Copy link
Copy Markdown
Contributor

Summary

Closes #141.

tauri.conf.json hardcoded width/height (1200x800) with no logic anywhere to adapt that to the screen the app actually launches on. The same fixed size showed up whether the user had a small laptop panel or a large external display, and the window had no explicit centering, so its start position depended on OS defaults.

What Was Changed

  • src-tauri/src/lib.rs: adds a setup hook that reads the primary monitor's work area (screen size minus taskbar/dock) and scale factor, computes a target size at 75% of that work area in logical pixels, clamps it to a 1000x700 to 1600x1000 range so it's never unusably small or absurdly large, sets that size, and centers the window. Falls back silently to the static tauri.conf.json size if monitor detection is unavailable (can happen on some Linux setups at startup), and always calls window.show() regardless of whether monitor detection succeeded, so the window can never end up permanently hidden.
  • src-tauri/tauri.conf.json: added minWidth/minHeight (1000x700) so a user can't resize below a usable size regardless of the computed initial size, added center: true as a declarative fallback, and set visible: false so the window is created hidden and only shown once the setup hook has finished computing and applying its real size. This avoids a visible flash/jump from the old 1200x800 default to the computed size.

Test Plan

  • cargo check and cargo clippy — both clean, zero warnings
  • Ran the actual app with pnpm tauri dev, not just a compile check
  • Queried the live window's real bounds via Quartz (CGWindowListCopyWindowInfo) rather than relying on a screenshot: on this machine's display (1470x956 logical resolution), the window came up at 1103x700, i.e. correctly computed as roughly 75% of the available work area width, with the height clamped to the 700 minimum, and positioned near the center of the screen rather than a default corner
  • No visible resize flash is possible given the hide-until-sized structure (window is created with visible: false and only shown after set_size/center run synchronously in setup)

Related Issues / PRs

Closes #141.

Addresses issue NexGenStudioDev#141. tauri.conf.json hardcoded width/height (1200x800)
with no way to adapt to the screen the app actually launches on. That
constant is also never converted into anything monitor aware afterward,
so the same window shows up regardless of whether the user has a small
laptop panel or a large external display.

- src-tauri/src/lib.rs: adds a setup hook that reads the primary
  monitor's work area (screen size minus taskbar/dock) and scale
  factor, computes a target size at 75 percent of that work area in
  logical pixels, clamps it to a sane 1000x700 to 1600x1000 range so it
  is never unusably small or absurdly large, sets that size, and
  centers the window. Falls back silently to the static
  tauri.conf.json size if monitor detection is unavailable (some Linux
  setups at startup), and always calls window.show() regardless of
  whether monitor detection succeeded, so the window can never end up
  permanently hidden.
- src-tauri/tauri.conf.json: added minWidth/minHeight (1000x700) so a
  user cannot resize below a usable size regardless of the computed
  initial size, added center: true as a declarative fallback, and set
  visible: false so the window is created hidden and only shown once
  the setup hook has finished computing and applying its real size,
  avoiding a visible flash/jump from the old 1200x800 default to the
  computed size.

Verified with a real native window, not just a compile check. Ran
`cargo check` and `cargo clippy` (both clean, zero warnings), then ran
the actual app with `pnpm tauri dev`. Queried the live window's bounds
via Quartz (CGWindowListCopyWindowInfo) rather than relying on a
screenshot: on this machine's display (1470x956 logical resolution),
the window came up at 1103x700, i.e. correctly computed as roughly 75%
of the available work area width with the height clamped to the 700
minimum, and positioned near the center of the screen rather than a
default corner. No visible resize flash was possible to trigger given
the hide-until-sized structure.

Signed-off-by: Anshul Jain <anshul23102@iiitd.ac.in>
@gemini-code-assist

Copy link
Copy Markdown
Contributor

Warning

Gemini encountered an error creating the review. You can try again by commenting /gemini review.

@anshul23102

Copy link
Copy Markdown
Contributor Author

Ready for review — could a maintainer take a look and add the appropriate GSSoC 2026 label? npm audit/cargo audit failures are pre-existing on master (confirmed via check-run history), unrelated to this change's diff.

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.

[UX] Hardcoded window dimensions not DPI-aware — UI broken on high-DPI displays

1 participant