[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.


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