| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In this scenario, a DragHandler is inside an Item in a Loader, under
a MouseArea, which unloads the loader on press. So on press, the
DragHandler acquires a passive grab, then the MouseArea acquires the
exclusive grab, then the DragHandler is destroyed along with its parent
when the Loader is unloaded. On release,
QQuickEventPoint::setGrabberItem(nullptr) was sending an
onGrabChanged(passiveGrabber, OverrideGrabPassive, this) notification.
That was questionable: the handler was not just then getting its grab
overridden, but rather un-overridden, because the exclusive grab
was being released. It's also a good idea to check for null pointers,
since m_passiveGrabbers is a collection of QPointers already,
so we can tell when a passive grabber is deleted dynamically.
It can also be reproduced with MultiPointTouchArea just as with
MouseArea, so the test is written that way for convenience, because
we have tst_multipointtoucharea_interop already. It doesn't really
matter which handler has the passive grab, or which item has the
exclusive grab that's being relinquished.
Fixes: QTBUG-73819
Change-Id: Ic605efa2143a1d849be095dcb88d6c38d7d2ee19
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
| |
|
|
|
|
|
|
| |
The test is actually flaky without that, but it seems to have been
missing already.
Change-Id: Ic619c66d924c18d3303f1d6bb65d42bc133c56a7
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We always intended to "start over" with event delivery when the number
of touchpoints changes. Change 48011c2dfeb83b4fe717034d4b3c353714fead48
began this process, but in addition to QQuickWindow delivering the
event to all items and their handlers in reverse paint order, ignoring
existing grabs, the handlers themselves have responsibility to act
as if it was an initial press whenever the number of relevant
touchpoints changes; and because QQuickWindow starts over, handlers do
not need to rely on passive grabs to retain interest in one point at
the time when a transition to a different number of points occurs.
For example, DragHandler by default handles just one point, so if you
press one point such that it takes a passive grab and adds that point
to m_currentPoints, then you press a second finger within the bounds
of the same parentItem, the DragHandler should not go on "wanting" the
first point anymore, because a two-finger gesture is different, and
not suitable for the DragHandler unless its maximumPointCount >= 2.
Even if the second point is released, QQuickWindow will "start over"
with delivery, so a multi-point handler does not need to rely on
retaining a passive grab to handle the transition from two points back
to one again.
This also helps enable smoother transitions between different
gestures: e.g. in the map.qml manual test, you can drag one finger and
transition from dragging to pinching and back while the second finger
is pressed, dragged and released.
Change-Id: Id9b8f30029ed1ff9fd2d64a5e413a47055622083
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
..when dragging (translation) is disabled
In order to do this, we had to integrate QQuickAxis to the PinchHandler
which allows enabling/disabling x and y axis individually.
This allows us to have one item with PinchHandler with translation
disabled (but to only handle rotate and scale) together with a two-finger
drag handler.
Change-Id: I1581c575ffba2e5d007163bec36e5699bdd86cbc
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
| |
|
|
|
|
|
|
|
|
| |
That is, minimumPointCount can now be set to a value > 1 to require
multiple fingers to do the dragging, or to track the displacement
of multiple fingers to adjust some value (such as the tilt of a map).
Task-number: QTBUG-68106
Change-Id: Ib35823e36deb81c8b277d3070fcc758c7c019564
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
| |
|
|
|
|
|
| |
... and clean up imports in examples, snippets and tests accordingly.
Change-Id: I5bbe63afd2614cdc2c1ec7d179c9acd6bc03b167
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
If you want to set target: null and then bind scale to some sort of
rendering scale property directly, it's a lot less trouble if the
scale property does not keep changing back to 1.0 every time a gesture
begins. Added an activeScale property to represent that value, the
one that the scale property had before.
Task-number: QTBUG-68941
Change-Id: Idcb6735d915a523afe1a948609080af7a83f82ad
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
| |
|
|
|
| |
Change-Id: I08e952fb8c19c21caf33ffb1cfdc260b533a01d9
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
From now on we prefer nullptr instead of 0 to clarify cases where
we are assigning or testing a pointer rather than a numeric zero.
Also, replaced cases where 0 was passed as Qt::KeyboardModifiers
with Qt::NoModifier (clang-tidy replaced them with nullptr, which
waas wrong, so it was just as well to make the tests more readable
rather than to revert those lines).
Change-Id: I4735d35e4d9f42db5216862ce091429eadc6e65d
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This helps with overriding behavior: when a QML control implementation
has handlers encapsulated inside, but the user tries to override
behavior by declaring more handler instances in instances of the
control, the user's handlers must be visited before the encapsulated
handlers. Likewise, this reverse-ordering corresponds to intuition
after having used MouseHandlers: the one which is declared last inside
an Item will have a higher effective Z order, and thus will be visited
first during event delivery.
Task-number: QTBUG-64692
Change-Id: I9bf18218a1887d0297c71ebf81dde0956394b72a
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
| |
|
|
|
| |
Change-Id: Ib1fe267c23ea9fce9bcc0a91ed61081260338460
Reviewed-by: Liang Qi <liang.qi@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
| |
even if all points are accepted or grabbed. A passive grab isn't much
good if there are cases where the handler is prevented from monitoring.
This enables e.g. the PinchHandler to steal the grab when the right
number of touchpoints are present and have moved past the drag threshold,
and enables completion of a couple of autotests.
Change-Id: I78dc6fc585f80bfb3c13e0c6e757ef815fb94afe
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
| |
|
|
|
|
|
|
|
|
| |
setGrabberPointerHandler is now implemented more similarly to
setGrabberItem. One improvement is that in
tests/manual/pointer/pinchDragFlingMPTA.qml the MPTA deactivates
when the PinchHandler takes over its touchpoint grabs.
Change-Id: I0bd4f143b5f25f1b393839f86c2a7802f1fa1886
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
| |
|
|
|
|
|
|
| |
This is more flexible in case someone wants a PinchHandler to respond
in the same way for either 2 or 3 touchpoints, for example.
Change-Id: I360ce6f0239d86aa92dbebc225e3646883e71100
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
| |
Conflicts:
examples/quick/shared/LauncherList.qml
src/quick/items/qquickevents.cpp
src/quick/items/qquickevents_p_p.h
src/quick/items/qquickwindow.cpp
tests/auto/quick/touchmouse/tst_touchmouse.cpp
Change-Id: Id692d291455093fc72db61f1b854f3fc9190267b
|
|
|
to test interoperability of PointerHandlers with conventional touch-
handling Items (with MultiPointTouchArea being the prototypical instance)
Change-Id: Id19f312b17b70df072d66cd91816d2b19250a500
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
