[Development] Extending touch semantic information and Qt backends

[Welbourne Edward]

Very much a digression but ...

> TUIO models the touchpoint as a rotated ellipse though, right?  [snip
> URL] And I think that’s nice, for finger touchpoints at least
> (although markers could be any shape).  It can be assumed to be the
> ellipse inscribed in a rect

Traditional graphics always thinks in terms of *coordinate-aligned*
rectangles, characterised by a width and height with respect to a single
fixed coordinate system.  This works fine for the classical (vertical
rectangular) screen and even for most modern tablets, where "rotation"
may be supported but only in multiples of a quarter turn.  However, once
you get to the kind of "touch surface as table" that the reactable video
illustrated - a horizontal round table, no less - there ceases being any
naturality to any one choice of coordinate alignment.  It's then
necessary to support all orientations equally well, without privileging
one of them.

In such a context, either an ellipse or a rectangle can be reduced to a
centre-point, a semi-major axial vector (orienting it) and a semi-minor
axis length (at right angles).  Naturally, we can equivalently scale the
axes by two to drop the semi-s.  There's then an obvious correspondence
between a rectangle and an ellipse via matching characterisation in
these terms.  Which you think of that set of parameters as representing
is then somewhat arbitrary.  The area of contact between a finger and a
flat surface is closer to elliptical than to rectangular; but there's a
stronger reason to prefer an ellipse.

Now, I know nothing of the implementation details of touch screens: but
have to guess that the actual raw data of an object pressing on a screen
is a noisy mess of pressure signals from nearby sensors.  The natural
way to process that noisy mess shall be statistically and the natural
statistical trickery to use for it is going to give you a mean (vector)
and variance (matrix).  The former is your centre-point; the latter is
(necessarily, from how it'll be computed from raw data) a symmetric
positive-definite quadratic form, a.k.a. a metric, which shall be
diagonalised by some specific choice of coordinates - characterised by
two perpendicular vectors, one of which we get to construe as semi-major
axial vector, with the other telling us the semi-minor axis length.  All
of this would still be true for markers of stranger shapes, thanks to
the noisy mess of physcal sensor data.  So I'm not surprised to hear
that a touchpoint ends up represented by these three data - centre,
major axial vector, minor axis length - or some geometrical entity
equivalent to them.

While these data can indeed be understood equally as characterising a
rectangle or an ellipse, coming via a metric makes the ellipse (the
"unit circle" of the distance associated with the metric) the more
natural form.  When major and minor axes are close to equal in length,
the ellipse strongly de-emphasises its incidental orientation, becoming
completely orientation-agnostic when we get to major = minor, the
circle.  In contrast, a rectangle retains its sense of orientation all
the way to that degenerate case, where the square still has a definite
orientation, albeit modulo quarter turns.

We need an orientation in our representation, to support the case where
the axial lengths are significantly different, but we need to think of
that orientation as only relevant in so far as the axial lengths *are*
significantly different.  Data derived from a metric in the form of
centre, major axial vector and minor axial size are thus more naturally
thought of as describing an ellipse.

So let me encourage you to think in terms of ellipses in this modern
era, as the more natural reading of "centre, major axial vector, minor
axial size" data, rather than in terms of the rectangles you grew up
with - they are an artefact of upright rectangular screens.  The tactile
UI folk rightly prefer a well-rounded future,

	Eddy.