On 17 May 2022, at 22:14, Ilya Fedin <fedin-ilja2...@ya.ru<mailto:fedin-ilja2...@ya.ru>> wrote:
On Tue, 10 May 2022 19:40:02 +0000 Morten Sørvig <morten.sor...@qt.io<mailto:morten.sor...@qt.io>> wrote: On 9 May 2022, at 16:47, Thiago Macieira <thiago.macie...@intel.com<mailto:thiago.macie...@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
_______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
