[Lazarus] Hi-DPI tweak of components
Giuliano Colla
giuliano.colla at fastwebnet.it
Thu Jun 8 11:46:11 CEST 2023
Il 08/06/2023 11:34, Giuliano Colla via lazarus ha scritto:
> Il 08/06/2023 08:08, Ondrej Pokorny via lazarus ha scritto:
>
>> Check TCustomColorBox how it handles FColorRectWidth as an example
>> (it uses a default value and if the user overwrites it, it gets
>> scaled in DoAutoAdjustLayout().
>
> I believe that scaling for different DPI has been implemented with a
> shortsighted approach.
> IMHO the general approach should have been (or should be if someone is
> willing to face it) to have *two* parameters for width and height: a
> pixel value and a linear value (in mm, inches, whatever).
> If the designer or user sets the pixel value, this value is taken and
> used, but the linear value is calculated.
> If the designer or user sets the linear value, the pixel value is
> calculated using the current DPI, and is used to paint the control.
> A new DPI will cause all pixel values to be updated from the linear
> values.
> I don't know if there are some cases where the pixel value should be
> retained even for a significant DPI change. A FixedPixel boolean or a
> zero value in the linear value might override the resizing.
>
> I understand that this would require a revision of all TControl
> descendants, by exposing the new properties, but I believe it to be
> the only way to make the DPI handling user friendly and mainly
> transparent to the users.
>
> Giuliano
>
An afterthought. A simpler way (or a first step) could be to keep the
linear value hidden. This wouldn't require a deep LCL revision, and
would make fully transparent the DPI handling. The designer sets the
desired width/height to the current screen, but the linear value is
stored and used whenever the DPI changes.
Giuliano
--
Do not do to others as you would have them do to you.They might have different tastes.
More information about the lazarus
mailing list