[Development] Revisiting high-DPI configuration options

Prav pr12og2 at programist.ru
Wed Jul 20 01:56:52 CEST 2016

Hello, Everyone!

> 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.
> ... and many other thoughts

I wanted to say that right DPI for screen should give only default scale factor for the app. And app should be able to change the scale
factor easy at runtime and with fractional values so that user can unjust the scale factor according to himself and his current environment.

So here I confirm that I see that "HighDPI" and "scaling factor" should be solved with the same technology. BUT ... we need screen's DPI only as a starting guess for setting the scale factor.
Later we need to let user adjust it.

I think that Qt lib should not go deeper in this by now ... like forcing some standard way to do scaling for the app. With common gesture or std shortcut.
And this is simply because we are not sure what the best way is. I think what Qt have to make app scaling as easy
as calling of one function and advertise on every corner that apps have to use this function and let user change scale factor if app wants to be considered "modern" and "good".

After that users and apps will create the best practice in this area and then Qt can implement it. Currently it is too early.

I am not sure that this "setScaleFactor" function is currently implemented.
For example here
I see only use of environment variable before start of the app for manual setting of scale factor.
But why I can not change it in runtime is still unclear for me.

I agree that changing of scale factor means that size of window will be changed. And what if this cannot be done more ... end of screen size ... what to do?
Well we have layouts for this. But here is the problem ... Qt layouts have not been changed/extended for so long that in current new conditions
devs would probably think that they are not happy with standard Qt layouts and would like to extend them (for example Horizontal layout
can not ever layout things vertically ... even if there is no space in horizontal direction and plenty in vertical).
But here is the problem ... we have mechanism to extend widgets (Promotion) but
this mechanism somehow is absent for layouts! Why?!
I am not sure about QML layouts problems ... probably anchors make it easier to define custom layouting in QML (but still not sure that everything is without problems in QML)
but with widgets ... I never saw news about adding or extending any widget-layout.
But this is in need after setScaleFactor will be implemented! ... because you can scroll the page vertically
but horizontal scrolling is a bad tone ... so there is need in some std layout which will use vertical direction if the layout is out of horizontal space and
there devs need possibility to extend layouts something like we have for widgets.

Another problem will be with icons. They will scale bad. We are used to make icons with versions like _x2, _x3 ... and what we going to do if scale factor
will be fractional? ... have icons versions like _1.1 _1.2 _1.3?
Probably we need to rethink why in the world we make so many copies of one icon in compile time if we can make one SVG icon which can be scaled
to any size without loss of crispness in runtime. Especially material design makes this easier because we mostly see only contours in material design icons.
So the next step for Qt can be supporting of SVG-icons as main and preferable way for setting icons. In this case icons can be scaled clearly.

I mean that this scaling-problem have to be discussed more in this terms ... in terms of support of already known technologies which by now were
not developed enough to make fractional runtime scaling easy ... but not only in terms of getting right DPI. Right DPI-factor is not close to the problem solution ... at ALL!

More information about the Development mailing list