[Development] Scalable UIs in QtQuick (take 2)

Welbourne Edward edward.welbourne at theqtcompany.com
Thu Feb 18 15:24:43 CET 2016


> On Thu, Feb 18, 2016 at 10:50:22AM +0000, Simon Hausmann wrote:
>> What do you think?
Oswald Buddenhagen replied:
> that it's a bit silly that we're having this discussion *yet again*. ;)
> http://thread.gmane.org/gmane.comp.lib.qt.devel/6572/focus=6807

I was amused that the discussion related to "retina" displays.  It took
a while to work out that these were just high-resolution screens - I was
initially thinking that this was about directly projecting onto the
user's retina, which would be kinda cool.  It would also drive home,
with particular force, the point in Tony van Eerd's first response in
the thread:

> i find the point about using arcminutes as a truly device independent
> unit particularly relevant.

See also:
https://www.w3.org/TR/css3-values/#absolute-lengths

Traditionally, displayed things have had their sizes measured in
physical units that have been more-or-less approximate in practice due
to the vagueness of nominal pixel sizes.  Designers have stipulated the
sizes of things to be big enough to read, making various assumptions
about screen resolution and the distance of the reader from the screen.
They have also, to some degree, chosen to subdivide the available space
into aesthetically pleasing proportions, for which percentages are
useful.  These days we also need to make sure displayed objects are big
enough to put a finger on reliably.  (There are etymological reasons for
the inch to be a unit that represents the size of a thumb, making it apt
for this last purpose; but practical use, quite apart from the silliness
of archaic units, has eliminated this as an option.)

(Shawn Rutledge mentioned the problem of projectors, troubled by the
question of how far the projector is from the screen.  That measure is
in fact less important than the ratio of that to the typical, or
rear-most, audience member's distance from the screen.  That ratio is
consequently the ratio of angular sizes of an item on the screen,
between the audience member and the projector.)

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.

Conventional length units address the second of these reasonably well;
and percentages do the first perfectly.  The first should not normally
be in need of end-user customisation.  The second may need a little -
some folk's fingers are smaller than others and maybe, when I'm using a
stylus, I'll be happy to have the stylus-size determine the "finger"
size we need.  The last needs lots - folk with eagle eyes want more
detail on the screen at a time, while others need the text nice and big
to be able to read it at all.

Most sound uses of the first kind of size won't overlap with the other
two; but these two overlap plenty.  The user needs to be able to read
the text on a button and to be able to operate the button.  For the
multi-touch case, things to be touched need to be far enough apart that
distinct chubby fingers can actually hit them at the same time; they and
related items need to be visually intelligible, too.  All the while,
everything wants to be small to fit on a screen that fits in a user's
hands.  It's a complex problem both to specify clearly what the
designer's needs are and to implement in a way that meets those needs.

Those trying to develop a solution would do well to talk to relevant
experts in the CSS WG,

	Eddy.



More information about the Development mailing list