[squeak-dev] Please Test | Improvements around display scaling (150%, 200%, 250%, ...)
marcel.taeumel at hpi.de
Fri Jan 14 08:54:22 UTC 2022
Hi Jakob, hi Christoph --
> [...] which messages should we use to write well-scaling LayoutFrames [...]
There was no change in this regard. As Christoph explained, try to depend on font metrics if possible or use "RealEstateAgent scaleFactor" for other pixel-based numbers.
Here are some examples:
aMorph height: TextStyle defaultFont height * 1.5. "or #defaultFixedFont"
aMorph height: Preferences standardButtonFont height.
aSpacer width: (aSpacer width max: (TextStyle defaultFont widthOf: $x) * 2).
aPanel width: (TextStyle defaultFont widthOfString: 'Hello!').
aMorph layoutInset: (5 * RealEstateAgent scaleFactor) truncated. "or rounded"
I don't think that we can get rid of all pixel-based constants because low-ppi displays require a sense of pixel-perfect accuracy where font-based calculations might look too awkward.
After the 6.0 release, we might want to look into the following challenges:
- Replace the use of "RealEstateAgent scaleFactor" with a single message on numbers, points, rectangles such as #scaledToDisplay or #screenScaled or #uiScaled
- Deferring layout scaling from initialization code (e.g., Morph >> #layoutInset:) to layout computation (e.g., TableLayout >> #layout:in:).
Again, nothing has changed regarding the current programming model for scale-factor-aware tools/widgets/etc..
Am 13.01.2022 21:04:04 schrieb Thiede, Christoph <christoph.thiede at student.hpi.uni-potsdam.de>:
looking at CodeHolder>>#optionalButtonsFrame, I would suppose that relying on the font selectors from Preferences class might be a best practice. Independently of the scaling factor, users could also override the font style of single widget classes, so going through the actual font makes sense to me. :-)
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Jakob Reschke <jakres+squeak at gmail.com>
Gesendet: Donnerstag, 13. Januar 2022 20:48:45
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Please Test | Improvements around display scaling (150%, 200%, 250%, ...)
Now that the scaling code has arrived in Trunk, which messages should
we use to write well-scaling LayoutFrames, in particular with offsets
(that were previously hardcoded to pixel values)?
Should we use
- Display relativeScaleFactor
- Display relativeUiScaleFactor
- Display uiScaleFactor
- or do it entirely in a different manner?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Squeak-dev