[Development] Revisiting high-DPI configuration options

[Shawn Rutledge]

> On 19 Jul 2016, at 10:57, Prav <pr12og2 at programist.ru> wrote:
> 
> Hello, Everyone!
> 
>> The scope of this is the Qt::AA_EnanbleHighDpiScaling mode. I’d like to
>> focus on two aspects:
>>    1) Automatic scale factor configuration based on system settings.
> There so many debates about this topic and how to get real DPI for all devices correctly.
> But I personally does get this as SO important thing. And this is because people are different
> and have different preferences about reading from screen (because of eyes or just personally).
> Which brings me to understanding that it does not matter what is the DPI of screen. It matter only
> how large PERSON want program font normally be.
> So I would expect that the main intention in developing of apps should be moved toward giving
> the user possibility to scale the app.
> And you are done!

I agree that most apps should have a means of scaling.  Control-mousewheel and control+/- are common on the desktop, so maybe it ought to be universal.  So far we have browsers, image and drawing viewers and editors, text editors (like Creator’s) and terminals which have the feature, but many other applications don’t.  I got a 4K display at work, so now I want to use konsole instead of urxvt, because of this feature: I need to zoom it depending on the use case, and which screen it’s on.  (On the Mac though, I wouldn’t need it so urgently.  The window has a similar physical size as I move it from one screen to another; whereas on Linux, the non-highdpi-aware window manager will keep the same pixel dimensions as I move it across.  So it’s a much smaller window on the 4K screen, regardless whether the content inside gets scaled or not.  Is that right or wrong?  Are we waiting for window managers to catch up here?  I don’t think resizing the window is necessarily Qt’s problem, although sometimes the layout does drive the minimum window size.)  I don’t use Qt’s auto-scaling, because in general I want smaller fonts on the 4K display, but I want to be able to choose the scale, and fractional scaling works so badly now.  Widget styles seem to need some re-design to be scalable.

But there should also be a system-wide setting for font sizes, and it should be respected by default.  Unfortunately the settings like this in most OSes are kindof coarse.  With distance field rendering, font scaling can be completely continuous, but that’s only in QtQuick apps.

The most common problem with zooming will be the need to use good layout management in the application.  Apps should do that anyway, if they want any portability at all.  But there will be threshold problems: if the screen/font-size ratio doesn’t allow enough space, you want to switch from a layout which uses too much horizontal space to a completely different one that doesn't.

There are also cases when accurate calibration is important though.  Some people are actually still engaged in preparing print media, for example.  They will appreciate having 100% zoom result in the same scale as it will be on paper.  And such people should either buy monitors which have correct EDID, or know how to correct it in their OSes.

> App should remember of couse this setting to restore it back at restart

How should Qt encourage this?  So far we have QSettings, but you need to define your own setting.  And we have not made it easy to scale all fonts simultaneously, interactively.  Bindings are too cumbersome and expensive to be the universal solution.  To avoid setting the font on every individual Text item in a QtQuick app, for example, you can use QGuiApplication::setFont().  But that’s just for the default.  Maybe there should be an event of some sort when you do that at runtime, which every Text will react to, and which will then trigger the necessary layout changes.  But that would only take care of Text which uses the default font, so we need that unit support in QML (which has been discussed for years but not done yet) to be able to have a unit which represents the default font size, so that larger text could have a size 1.2x as big as the default instead of an actual point size.  Or maybe the event should be sent when you do QHighDpiScaling::setScreenFactor(), but that’s private API so far, and it’s still not clear to me which of those Qt high dpi-things are intended to affect only or mainly font sizes, and which of them demand everything to be scaled even if it will cause crappy results (scaling up pixmaps or pre-rendered widgets by non-integral ratios).  The prototype zoom-slider is in qtbase/tests/manual/highdpi, but you can see what goes wrong with that.  We need a similar test for QtQuick to see what goes wrong with dynamic scaling there.

Maybe we should have an optional feature in QQmlApplicationEngine (just set one flag or property, plus setOrganizationName and setApplicationName), or in a subclass, which makes it easy to make an application zoomable (even taking over those key and mouse shortcuts), and remember the last setting.  But maybe it’s controversial to push QSettings into even broader use… some think it’s obsolete and don’t know what to replace it with.  Some want to use JSON.  And what about touch-oriented apps?  We can’t take over the pinch-zoom gesture for the single purpose of scaling text sizes, because each app can use that gesture in its own way.  Maybe we could at least make it easy to declare a handler which makes the pinch gesture do that, if that’s what you want, and your app doesn’t have another use case for pinch.  Or, come up with another gesture for that kind of zooming.

The devil’s in the details, and we’ve had a proliferation of details over the last few years.

> PS I can give many more cases then getting right DPI does not give usability to user.
> 1. Developers or Designers are young, have good eyes are pretty conformable with small fonts.
>    They produce app with HighDPI support which correctly scales to DPI of HighDPI user device. But ... this does not mean
>    that old persons would feel comfortable with the app ... their eyes see not as good as when they were young.
> 2. Could be a reverse case ... like you want smaller because devs created app which seems larger to you.
> 3. Devs and Designers usually have good tech. I mean good monitors, modern phones with good crisp screen.
>    But user's tablet/phone can be not modern or be cheap or with tons of scratches (for example with plastic (not glass screens)).
>    Sooo ... visibility is much worse ... but DPI could be same.
> 4. You are OK with design and size of app's fonts at your notebook/tablet with like 10'', devs and designer see things the same good as you
>    and your screen is modern and good with gorilla glass or something same and DPI scale factor was determined exactly as it is.
>    But now you are inside city transport ... and guess what ...
>    you are shaken! ... and this mean you see the screen worse ... you need to increase the scale!
>    And if you sit/lay still in the bedroom you what smaller font to see more info at once.

Yes, exactly.

The same goes for switching between light and dark themes.  It should be system-wide and as effortless as possible.  When I use my laptop on my morning commute, I want a light theme, and typically a dark one on the way home, depending on the season and the weather.  Android is wrong - they enforce inconsistency and lack of choice by letting every application hard-code the theme.  Creator is wrong for making me restart it if I change the UI theme.  And everyone else is wrong for not making a handy system-wide toggle.

> I do not see much trend in Qt-discussions/apps-interfaces about user-defined scale factor. But only THIS is important to user.
> And NOT DPI ;)

We can’t say that DPI is never important though.  The consensus so far seems to be that some apps need accurate scaling, while most don’t.  Qt has to support both, and the one doesn’t prevent the other.