[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