[Development] Updated high-DPI support for Qt 5.14

Matthew Woehlke mwoehlke.floss at gmail.com
Wed Sep 25 18:33:16 CEST 2019

On 25/09/2019 08.54, Morten Sørvig wrote:
> I see two differences between setting the DPI vs a factor:
> - You set one value per screen (DPI) instead of two (DPI & factor)
> - Qt can compute the factor, according to policy set by the application (as mentioned above)
> [...]
> If possible, I’d like us to move away from relying on setting
> environment variables, and/or switch to specifying per-screen DPI
> instead of a scale factor.
Has anyone considered whether or not this is *user* friendly?

As a user, I don't want to have to know/measure/compute the DPI of my
display device. I just want to make "stuff" bigger or smaller. I *also*
don't necessarily want the same physical size of "stuff" across devices.
On my phone, I may want smaller "stuff", because my phone is usually
quite close to my eyes. On my 4K 75" television, I may want larger
"stuff" because I'm sitting 10' to 15' away. Maybe I have really good
(or really bad) eyesight.

Fiddling with "fake DPI" as a way of adjusting things has always felt
like a hack. Setting display scaling "just makes sense". From a user
perspective, it's obvious that scaling is also going to affect icons,
style margins, frame thicknesses... basically, *everything*. DPI,
historically, only affected font sizes and *maybe* some margins. If the
only knob I have is DPI, how do I know (or control) what size my icons
will be? How am I supposed to guess what will be the relation between
"virtual" pixels and physical pixels, keeping in mind that I, as a user,
am trying to achieve a particular value for that?

There are a few instances, such as when representing physical objects,
when it makes sense to try to achieve a particular physical size. In
almost *every other case*, which is to say *always* for interface
elements, there is no fixed correlation between "desirable" size and
actual physical size, and anyone that designs their application
otherwise is doing their users a disservice.


More information about the Development mailing list