[Development] Updated high-DPI support for Qt 5.14
Morten.Sorvig at qt.io
Mon Sep 16 15:00:27 CEST 2019
> On 13 Sep 2019, at 17:50, Thiago Macieira <thiago.macieira at intel.com> wrote:
> On Friday, 13 September 2019 08:35:59 PDT Elvis Stansvik wrote:
>>> What happened to QT_AUTO_SCREEN_SCALE_FACTOR and QT_SCREEN_SCALE_FACTORS?
>> I wonder too. I assume they've not been removed? The latter is the one that
>> KDEs kscreen KCM manipulates AFAIK, and I occasionally use it from command
>> line for testing. What would be the new way to set per-screen scale factors?
> I'm going to make a different request: unless the meaning has changed, keep
> the same names. We already went through a round of having people migrate their
> variables from the old names to those I listed. Let's not do it again without
> strong reason.
Yep, nobody likes API churn. They are not going away, but do not fit well with
the API structure or the way the implementation works any more, so I did not
emphasize them in my email.
Long term I think the migration path should be off of Qt-specific high-dpi
config options, in favor of windowing system API. Which in this case probably
means using Wayland instead of X11.
Could KDE possibly set per-screen DPI instead of a scale factor? Applications
can now use the QGuiApplication::setHighDpiScaleFactorRoundingPolicy() API to
decide wether or not they accept fractional devicePixelRatios (in the cases
where Qt implements the scaling), which does not match well with having a directly
set scale factor.
More information about the Development