Repository navigation
Never demand a window larger than the screen can show - #616
Merged
Merged
Conversation
added 2 commits
September 9, 2026 22:46
tauri.conf.json declares the window minimum in logical pixels, so the physical size it asks for scales with the display. At 250% the declared 1024x720 demands 2560x1800 physical. A 1080p panel cannot show that in either direction, and a 3440x1440 one cannot show the height. The window then cannot be resized to fit its own screen, and there is no way out from inside the app because the controls that would fix it are off the edge. The minimum is now capped at what the monitor can actually display. A machine with room keeps the full floor and nothing changes for it; one without gets a window it can see and move. Below the design floor the layout is cramped, but cramped and reachable beats correct and off-screen. Lowering the numbers was the other option and it does not fix the class: any fixed logical minimum exceeds some screen at some scale factor. Capping is the property that actually holds. Also brings the window itself down when it lands on such a screen. The declared default is larger than the minimum, so a screen too small for one is too small for the other, and relaxing only the minimum would still open oversized. The floor is now documented with what it is worth rather than as a bare number. Sweeping the studio one axis at a time against a real six-stem track: the content area shrinks with the window and stops being usable around 620px of height, and width has no hard floor at all down to 760, where the footer strip scrolls (which it already does at 1280, see #586) and every control stays reachable. So 1024x720 is a comfortable floor rather than a hard requirement, which is what makes capping it safe rather than a compromise. The policy is split from the window plumbing so it can be tested without a display, since the arithmetic is the part that decides whether someone ends up stuck. Three tests: a roomy screen is left alone, the reported 1080p-at-250% case comes back with something that fits in both directions and still leaves room for a taskbar, and a wide-but-short screen relaxes only the axis that does not fit. Verified against an unclamped version: two of the three fail. A fourth test asserting the constants against each other was written and deleted. It compared two literals and could never fail, which clippy flagged as well. The measurement it was trying to record belongs in the comment above them, where it now is. Checked on both targets: 92 tests on Windows, 101 under WSL. Closes #607
A window that silently behaves differently on one machine than another, with nothing anywhere saying why, is the shape of bug this fix exists to remove. So the decision goes in setup.log with the numbers behind it: what it relaxed to, what the screen actually reports, and what was declared. Also the line that lets this be verified at all. The clamp does nothing on a display with room, which is correct and makes it invisible to test by eye without changing someone's display settings. Raising the constants above any real screen and reading this line exercises the whole path -- current_monitor, to_logical, set_min_size and set_size -- against a real monitor: window minimum relaxed to 3096x1296; screen is 3440x1440 logical (3440x1440 physical at 1.00x), too small for the declared 1024x720 and the window itself came back 1296 physical tall, matching. Constants restored afterwards; the probe was never committed.
thcp
force-pushed
the
fix/window-min-size-fits-screen
branch
from
September 9, 2026 21:48
6a7b4c0 to
f7f852e
Compare
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
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 #607
Also fixes a macOS build break on main
Found while rebasing this onto #615.
maincurrently does not compile for macOS in the test profile.cuda_install_passesis#[cfg(not(target_os = "macos"))], and each test that calls it carries its own matching gate. #615 inserted two new tests immediately beforecuda_install_passes_adds_dependency_pass_only_when_needed, which took over the#[cfg]attribute that belonged to it. So that test, andevery_cuda_pass_carries_torchvision, now call a macOS-gated function without the gate.That is my regression from #615, and the dead macOS runner is exactly why nothing caught it. Both gates are restored here. It is bundled in rather than split out because this PR touches the same lines and macOS CI is down either way, but it is the more urgent half of the change.
The problem this PR was for
tauri.conf.jsondeclares the window minimum in logical pixels, so what it demands physically scales with the display:A 1080p panel cannot show that in either direction. A 3440x1440 ultrawide cannot show the height. The window then cannot be resized to fit its own screen, and there is no way out from inside the app because the controls that would fix it are off the edge.
The fix
The minimum is capped at what the monitor can actually display. A machine with room keeps the full floor and nothing changes for it.
Lowering the numbers was the alternative and it does not fix the class: any fixed logical minimum exceeds some screen at some scale factor. Capping is the property that holds.
It also brings the window itself down on such a screen, since the declared default is larger than the minimum.
The floor is measured, not assumed
Sweeping the studio one axis at a time against a real six-stem track:
So 1024x720 is a comfortable floor rather than a hard requirement, which is what makes capping it safe.
Verification
The policy is split from the window plumbing so it can be tested without a display. Three tests: a roomy screen is left alone, the reported 1080p-at-250% case comes back fitting in both directions with room for a taskbar, and a wide-but-short screen relaxes only the axis that does not fit. Two of the three fail against an unclamped version.
The plumbing was verified against a real monitor without changing any display settings, by temporarily raising the constants above any real screen:
and the window came back 1296 physical tall, matching. That exercises
current_monitor,to_logical,set_min_sizeandset_sizefor real. Constants restored; the probe was never committed.The decision is now recorded in setup.log, because a window that silently behaves differently per machine with nothing explaining why is the same shape of bug this fixes.
94 tests on Windows, 103 under WSL.