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
--
_______________________________________________
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus
