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