[Lazarus] Hi-DPI tweak of components

[Ondrej Pokorny]

On 08.06.2023 11:46, Giuliano Colla via lazarus wrote:
> 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.

Well, this still could be implemented.

But do not forget that the LCL must stay backwards-compatible (old code 
must work in new versions) and to some extend also forwards-compatible 
(LFM from new Lazarus versions must open in older Lazarus versions - 
that is valid for at least 2 latest stable versions). Especially, the 
LFM compatibility is an issue.

All in all, an over-complicated approach with little gain.

Ondrej