[Development] QTBUG-95930 / QTBUG-99546 need some attention

Morten Sørvig Morten.Sorvig at qt.io
Thu May 19 16:20:05 CEST 2022

On 17 May 2022, at 22:14, Ilya Fedin <fedin-ilja2010 at ya.ru<mailto:fedin-ilja2010 at ya.ru>> wrote:

On Tue, 10 May 2022 19:40:02 +0000
Morten Sørvig <Morten.Sorvig at qt.io<mailto:Morten.Sorvig at qt.io>> wrote:

On 9 May 2022, at 16:47, Thiago Macieira
<thiago.macieira at intel.com<mailto:thiago.macieira at intel.com>> wrote:

On Monday, 9 May 2022 07:07:23 PDT Morten Sørvig wrote:
b) In practice, QT_SCREEN_SCALE_FACTORS has become a system
setting since it’s being set on behalf of the user. This means the
values should be subject to rounding according to
highDpiScaleFactorRoundingPolicy property, like with other system
DPI settings.

It it's a system setting, then one should assume it's been set to
the exact value that the system wanted it to be. So if they'd
wanted it rounded, they'd have rounded it.

That is true, however the purpose of highDpiScaleFactorRoundingPolicy
is override the system setting. For example, a Windows display can be
configured for 175%, but the app knows it does not support that and
has enabled rounding (to 200%).

So if QT_SCREEN_SCALE_FACTORS is considered a system setting then
this is an inconsistency in behavior.

So, what's the decision? Is it a bug in Qt or in KDE?

Looks inconclusive to me - no clear consensus either way. (I’m also not sure if it's a bug - it’s just "the current behavior")

However, we might be able to find a way forward: the rounding policy is also under user control with the QT_SCALE_FACTOR_ROUNDING_POLICY environment variable. So users who wants no rounding at all (even for apps which claim to not support fractional scale factors) can set it to “Passthrough” to preserve the current behavior.

- Morten

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20220519/2307ac0e/attachment.htm>

More information about the Development mailing list