Menu and Browser: defer to the toolkit's own scale instead of ignoring it - #209
Merged
Conversation
…g it Both grew a Scale field before SetMetricScale existed, and answered only to it. So a host had to choose: set the global and watch the menu stay small while everything around it grew, or set both and hope nothing was scaled twice. Since neither widget routes anything through scaled(), setting both would in fact have been safe -- but nothing said so, and "hope" is not an interface. The field now REPLACES the global rather than falling back to 1: a host that set it before the knob existed gets exactly what it asked for, and one that sets only the knob gets a menu and a browser that follow it like every other widget. 1.5 under a global of 2 is 1.5, not 3. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This was referenced Aug 16, 2026
Merged
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
1 participant
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.
Both grew a
Scalefield beforeSetMetricScaleexisted, and answered only to it. So a host had to choose: set the global and watch the menu stay small while everything around it grew, or set both and hope nothing was scaled twice.(Since neither widget routes anything through
scaled(), setting both would in fact have been safe — but nothing said so, and "hope" is not an interface. This is the double-scaling risk that window#49 could not rule out without reading both packages.)What changes
The field now replaces the global rather than falling back to 1:
Menu.ScaleunsetMenu.Scale = 1.5MetricScale() == 1MetricScale() == 2So a host that set the field before the knob existed gets exactly what it asked for, and one that sets only the knob gets a menu and a browser that follow it like every other widget. Asserted at both ends, including that a menu scaled by the global comes out the same height as one scaled by its field — the two ways of saying the same thing must agree.
This is what makes it safe for
window.Runto setSetMetricScalefor aNativeScalewindow: there is one scale, and setting it twice is not an error.🤖 Generated with Claude Code