[Development] Scalable UIs in QtQuick (take 2)

[Sorvig Morten]

> On 18 Feb 2016, at 15:24, Welbourne Edward <edward.welbourne at theqtcompany.com> wrote:
> 
> To meet all the actual use cases, we need three different *kinds* of
> size for things:
>  * fraction of the available display area - good for top-level
>    sub-division of the space an app has at its disposal to work in;
>  * physical size on screen - to make sure a finger shall actually hit a
>    button reliably and not be mistaken for hitting the next button
>    over; and
>  * angular size subtended at the user's eye - for readability.
> 

I argue the situation is under control :)

Display area sub-division is handled by the Qt layouts. Touch targets need
to be larger than mouse targets: this is a styling issue which I think we
are handling/can handle. But the important thing is that both these two 
are handled in logical pixels; display density does not factor into it.

For you final point, I think the right place to solve this is at the hardware
and OS level, and not in QML which should keep operating in logical pixels.

The hardware designer selects a display panel with a certain pixel density 
and provides a scale factor/dpi value through the OS, taking into account 
the intended viewing distance for the device.

For example, these are the pixel densities (pixels-per-inch) for three Apple
devices: (all of them are 2x)

iPhone     : 326 
iPad       : 264
iMac (5K)  : 218

The effect is that a 10x10 square will have a smaller visual size on the
handheld devices, corresponding to the closer viewing distance.

We need some support for cases where Qt is close to the hardware (embedded
use cases), but I would argue the current scaling support (as configurable via
QT_SCALE_FACTOR or AA_EnableHighDpiScaling) is sufficient here, at least for a
first release. There are also cases where OS support is wanting, and we do more
work in Qt.

- Morten