[Development] Extending touch semantic information and Qt backends

[Ariel Molina]

>
> I’m interested.  But I will warn you that my attempts to make MouseArea
> and Flickable handle touch events directly have run into issues with the
> complexity of handling two completely independent event types with
> similar-but-different code, backwards compatibility, getting reviews on the
> patches, getting tests to continue passing, etc.  They handle only mouse
> events, which are synthesized on a touchscreen; changing MouseArea to
> handle touch is too hard; and that makes it too hard to change Flickable,
> because so many applications have MouseAreas in delegates in ListViews.
>

Ideally I won't be touching any existing code, just adding more semantic
information to current code, things such as rotation, deviceID and marker
ID's are easy to add, but shape information and others are not that easy.


>
> So, in existing releases of QtQuick, only PinchArea and
> MultiPointTouchArea handle touch events directly.  Maybe you are thinking
> of enhancing MPTA and its TouchPoints?  That’s probably doable, but do you
> think that API is useful enough for your applications?  If not, what kind
> of API would you rather have?
>

I found the MultiPointTouchArea to be very limited, for example now the
code suggests to name every TouchPoint in order to use them (
http://doc.qt.io/qt-5/qml-qtquick-multipointtoucharea.html#touchPoints-prop)
. Better will be to allow it to be inserted as a model into a Repeater.

How about supporting something like this?
MultitouchArea{
  id: mtArea
}
Repeater{
  model: mtArea.touchpoints
  delegate: Rectangle{
     x: touchX
     y: touchX
     width: blob.width
     height: blob.height
     rotation: blob.angle
     opacity: pressure
  }
}

The main limitation there seems to be the limited information TouchPoint
offers.  With some refactoring to MultiTouchPointArea it can be done.


>
> Now the plan is to write a new set of event handlers which are
> lighter-weight: not Items themselves but declared inside any Item (inspired
> by the Keys attached property, but not quite the same).  There can
> potentially be lots of types of handlers, and even several handler
> instances inside one Item when necessary; some will be hardware-agnostic
> “gesture” recognizers (e.g. TapHandler and PinchHandler) while others will
> be hardware-specific.


The event managing is a ver good idea, but the real limitations are on the
information TouchPoints provide.


> So maybe we can come up with a good way to handle markers within that
> framework, although I don’t have access to a fancy touch table which
> supports them (but have a capacitive touchscreen).  And yes the multi-user
> scenarios are interesting too.  I figured the new QQuickPointerEvent can
> have some sort of ID for user or “seat", whichever makes most sense.  Do
> you think it should simply be a numeric ID?
>

There are several variants of fiducial markers, see for example the list at
http://www.tuio.org/?tuio20 where they list fidtrack, touchatag, QR Codes,
EAN barcodes, two variants of Microsoft, and even color tags covering from
binary trees, to strings, hex codes and raw bytes. So a QString should
accomodate all variants.


>
> Likewise I don’t have a touchscreen which supports rotation, but have a
> Wacom tablet which does.  QQuickPointerEvent has a rotation property, on
> the assumption that it will become more common (but I can only test it with
> the tablet for now).
>
> What do you mean about layers?
>
Several users interacting on the same space from different perspectives,
either bilateral screens (they are already being used), or screens where
some touchevents come from remote places/users. By identification of the
source it can be easily supported and by ignoring source the layers just
become a single touchscreen so current apps are not affected.



-- 
Ariel Molina R.

Oficina: +52 (222) 3723196
Movil: +521 2226 758874
http://edis.mx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160211/90d6f79e/attachment.html>