> On 18 Feb 2016, at 15:24, Welbourne Edward > <edward.welbou...@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 _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
