Thank you for this summary with examples!

Am Fr., 14. Jan. 2022 um 09:54 Uhr schrieb Marcel Taeumel
<marcel.taeumel at hpi.de>:
>
> 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..
>
> Best,
> Marcel
>
> Am 13.01.2022 21:04:04 schrieb Thiede, Christoph <christoph.thiede at student.hpi.uni-potsdam.de>:
>
> Hi Jakob,
>
>
> 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. :-)
>
>
> Best,
>
> Christoph
>
> ________________________________
> 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%, ...)
>
> Hi Marcel,
>
> 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?
>
> Kind regards,
> Jakob
>
>