> On 13 Sep 2019, at 17:50, Thiago Macieira <thiago.macie...@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 _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development