[Development] Updated high-DPI support for Qt 5.14

[Morten Sørvig]

> 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.

- Morten