aboutsummaryrefslogtreecommitdiffstats
path: root/src/qml/jsruntime/qv4engine_p.h
diff options
context:
space:
mode:
authorShawn Rutledge <shawn.rutledge@qt.io>2018-10-26 19:57:09 +0200
committerJani Heikkinen <jani.heikkinen@qt.io>2018-10-30 09:39:20 +0000
commit75132505ab7eba08f4c82aced31143960d4773a7 (patch)
tree0e4bcb2329d84aef87e31a8b83e735fb6e014d5a /src/qml/jsruntime/qv4engine_p.h
parent502447e15b38d6111c23d608240e0d7afb7c2ad6 (diff)
QQWindow: cancel touch->mouse synthesis when touch is ungrabbed
Previously, each time a new touchpoint is pressed, we would purposely forget which touchpoint was acting as the mouse, as part of "starting over" with event delivery. Conceptually "starting over" ought to mean as freshly as possible; but in practice, if a user was using one finger to interact with some mouse-only Item, and then presses a second finger (whether intentionally or not), (s)he doesn't want the first interaction to immediately end. The multi-finger DragHandler must be able to take over the grab from the Item which already had the grab; but it uses a passive grab in the meantime to track the movement, and normally takes over the exclusive grab only when its preconditions are met: the point has to move past the drag threshold. So we can wait until then to reset the touchMouseId. The concrete use cases are: double-tapping a map is supposed to zoom in, even if there is a MouseArea on top. And, while dragging a Slider inside a Flickable, you should be able to start dragging the Flickable with a second finger. In the first case the issue was that the MouseArea could grab while handling the synth-event, thus setting touchMouseId; then touchMouseId was immediately reset again while handling the second touchpoint, so the second touchpoint would also be offered as a synth-mouse event to various items. But while fixing that, we have to avoid this issue in the Slider-in-Flickable case: when the first touch press is delivered, Flickable takes the exclusive grab temporarily; after moving the touchpoint, the Slider's DragHandler steals the exclusive grab. Then we try to deliver the second touchpoint press: at this time, we don't want touchMouseId to be set, because we want to be able to deliver synth-mouse events for the second point so that Flickable can grab that one. So it must be that when DragHandler steals the grab, we can reset touchMouseId, because the only reason it was set was that Flickable had the grab. This result is achieved by having QQuickItem::touchUngrabEvent() call a new QQuickWindowPrivate::cancelTouchMouseSynthesis() function. It was already a good idea to have such a function since we always reset touchMouseId and touchMouseDevice at the same time. Also modify the docs to remind users that when subclassing QQuickItem and overriding mouseUngrabEvent() or touchUngrabEvent() they should call the base class implementation, to avoid bypassing this new functionality. Fixes: QTBUG-70998 Change-Id: I02894971e9047d4fa7ac9d062d6714c9183a8058 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
Diffstat (limited to 'src/qml/jsruntime/qv4engine_p.h')
0 files changed, 0 insertions, 0 deletions