| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Consider
Flickable {
Text {
TapHandler { gesturePolicy: TapHandler.ReleaseWithinBounds }
}
}
On press, TapHandler gets the exclusive grab. Now drag vertically.
The Text is short in stature, so your finger soon strays out of bounds
of the Text, likely before you have dragged past the drag threshold.
In this case, we want Flickable to continue to filter the move events
because of the fact that TapHandler is the grabber. If it was a
MouseArea instead of a TapHandler, it already worked that way; so this
makes behavior of handlers more consistent with that.
More specifically: QQuickPointerTouchEvent::touchEventForItem() now
generates a touch event even if the touchpoint is not within the bounds
of the given item, but is grabbed by one of that item's handlers. Until
now, we had that exception only if it was grabbed by the item itself.
tst_FlickableInterop::touchAndDragHandlerOnFlickable now always drags
the delegate at index 2 (the third one) from its upper-right corner,
upwards and to the left. The first drag goes outside the delegate's
bounds, but the Flickable/ListView/TableView filters and takes over
anyway (on the next drag), to prove that it is correctly depending
on the grab that the TapHandler (or DragHandler) took on press.
Fixes: QTBUG-75223
Change-Id: Ie4e22c87be0af9aa3ff0146067b7705949b15c40
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit 1e1674849a89db54cdbcc4e995300e3ec1624c3a)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In particular, on press when QQuickFlickable::filterPointerEvent() calls
captureDelayedPress() and will return true, it also accepts the event to
stop propagation. It becomes the grabber as a consequence of that.
On a future move event, when the drag threshold is exceeded while the
delayed press timer is still running, Flickable already has the grab
(but it accepts the event again), and QQuickFlickablePrivate::drag()
calls setKeepMouseGrab(true). In this case we still want to prevent any
children's DragHandlers from seeing the event, because a DragHandler
will also see that the drag threshold was exceeded and try to steal the
grab. A DragHandler can steal the grab only if there was no press
delay: then it sees the initial press because Flickable does NOT stop
event propagation (does not accept the event), so it can take a passive
grab and continue to wait for the drag threshold to be exceeded,
regardless of what else happens.
In case of multiple touchpoints, allPointsGrabbed() returns false if the
Flickable has only grabbed one point; but we want to avoid delivering
handlers in children just on the basis of that grabbed touchpoint being
within their bounds, even though other points may be delivered to
various handlers.
This fixes tst_FlickableInterop::touchAndDragHandlerOnFlickable.
The blacklisting of dragHandlerInSiblingStealingGrabFromMouseAreaViaTouch
was bogus (it's in the mousearea_interop test).
Task-number: QTBUG-86729
Change-Id: I9f0d42e97de4f4a3b4f7773800a8d59dc34a0553
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
(cherry picked from commit c5c05498a7e79c1868551192921a42236ecbf5f8)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
QQuickWindowPrivate::cloneMouseEvent() renamed to clonePointerEvent()
and generalized to be able to clone any of the kinds of QPointerEvent
that we're interested in replaying. Now it is used only in
QQuickFlickablePrivate::captureDelayedPress().
Reverts f278bb7c66bb00c9f81b7a3aceeb94cb9b3a1b66 and
012a4528a515af8d7ec7dbc05a38d8fd0d6d4d1b (don't skip
tst_TouchMouse::buttonOnDelayedPressFlickable). Some test changes
from f128b5dee8a2a03ebc55ed0cd1e749a6599282c3 also get reverted.
QEventPoint should always have valid velocity now, so
Flickable no longer has to calculate it for itself.
Removing that became necessary to fix the movingAndFlicking test.
Adds logging categories qt.quick.flickable.filter and .replay.
Fixes: QTBUG-85607
Task-number: QTBUG-83437
Task-number: QTBUG-78818
Task-number: QTBUG-61144
Task-number: QTBUG-88038
Task-number: QTBUG-88138
Change-Id: I0ed6802dff5e5d1595adddc389642925f1f2c93d
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
| |
Task-number: QTBUG-86729
Change-Id: Ia4db0a98a4977cb89799c5749983a370d35317a7
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
|
| |
Modify special case locations to use the new API as well.
Task-number: QTBUG-86815
Change-Id: I3b964e3baf0cc7040830156dac30358ea1152801
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
|
|
|
|
|
|
| |
Task-number: QTBUG-86729
Change-Id: I49fb86e867afeee2f0567dc3498598b249ae5e08
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Call onGrabChanged on Pointer Handlers during grab transitions:
this was missing in a97759a336c597327cb82eebc9f45c793aec32c9.
Flickable needs to receive an ungrab by child-event-filtering,
in order to set its pressed state back to false (as in the
cancelOnHide autotest). This is best done as a result of the
QPointingDevice::grabChanged signal, while trying to send the ungrab
to the item that was the grabber, rather than as a special case.
Thus, QQuickWindowPrivate::onGrabChanged (the handler for the
QPointingDevice::grabChanged signal) is now the only place from which
we call QQuickItem::mouseUngrabEvent() and touchUngrabEvent().
But the result is that they are called in more cases than before,
so some tests need adjustment. touchUngrabEvent() is not sent
unless the event is available and we can verify that all points
have been released. This is important for MultiPointTouchArea:
it will react by ending interaction with all points at once.
Another thing that's important to MPTA and multi-touch handlers is that
QQuickWindowPrivate::deliverPointerEvent() must not clear grabbers of
points that are not yet released, in the case that only some points are.
QQuickWindowPrivate::removeGrabber() now calls
QPointingDevicePrivate::removeGrabber() with its optional cancel
argument, so that it will emit either a cancel or an ungrab transition.
That's only relevant for Pointer Handlers, whereas QQuickItem
mouseUngrabEvent and touchUngrabEvent don't make a distinction.
Task-number: QTBUG-86729
Change-Id: Idf03aef2e2182398e0fc4a606c0ddbb2aaed5681
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
qtbase/2692237bb1b0c0f50b7cc5d920eb8ab065063d47 and the associated
Qt Quick change to do direct delivery of QPointerEvents seem to have
broken a number of tests as they are currently written. It looks bad;
however I spent a lot of time already on some older "basic" tests
like tst_qquickwindow, touchmouse, tst_qquickflickable etc. and found
a lot of things to fix while doing that; so at least those aren't broken
now. Troubleshooting each test takes time. Hopefully it will turn out
that many of these failures are related (there seems to be something in
common about handlers and items stealing touch grabs from each other).
Task-number: QTBUG-86729
Change-Id: I14acf57fc83fa961a25f91108dcd4aea42b54435
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
...and generally deal with changes immediately required after adding
QInputDevice and QPointingDevice.
Also fixed a few usages of deprecated accessors that weren't taken
care of in 212c2bffbb041aee0e3c9a7f0551ef151ed2d3ad.
Task-number: QTBUG-46412
Task-number: QTBUG-69433
Task-number: QTBUG-72167
Change-Id: I93a2643162878afa216556f10808fd92e0b20071
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
|
|
|
|
| |
Change-Id: Ia0a075e3199eab735f9b289873beeb8730ebc47e
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
| |
Change-Id: I48d7fd306f3d1b161a8e73029282ee591b1ef612
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Liang Qi <liang.qi@qt.io>
|
|\
| |
| |
| | |
Change-Id: I0c5b939c70bdb91ccdf7068784308416dcaa5736
|
| |
| |
| |
| |
| |
| |
| | |
Task-number: QTBUG-81290
Change-Id: I58f64f5eabdb72f2f01bf72e988941521a89d331
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
| |
| |
| |
| |
| |
| | |
Change-Id: Ie0db35f674137c229eaf049616f38f8e818f7092
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
| |
| |
| |
| |
| |
| | |
Change-Id: I67a6c8f1659e7b471a4fcb92a2699292cf4eea81
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
All tests compile and run on a developer build.
These tests are failing:
tst_qqmlsqldatabase Fails due to missing sql driver
tst_qqmlsqldatabase Fails in wip/qt6
tst_ququicklayouts Fails in wip/qt6
tst_flickableinterop Fails in wip/qt6
tst_qquickpinchandler Fails in wip/qt6
tst_qquickflickable Fails in wip/qt6
tst_qquickgridview Fails in wip/qt6
tst_qquickimage Fails due to missing jpeg plugin
tst_qquicklistview Fails in wip/qt6
tst_qquicktext Fails in wip/qt6
tst_qquickcanvasitem Fails in wip/qt6
tst_scenegraph Fails due to missing jpeg plugin
tst_TestFiltering Fails in wip/qt6
Change-Id: I4b9d69c118e23c095cb72ad5a67653fc30943bb1
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
|
|
|
|
|
|
| |
Task-number: QTBUG-75224
Change-Id: Ic7daefa2f0422a0b1cfa112fd5412cafffb2a9ed
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
|
|
| |
touchAndDragHandlerOnFlickable and touchDragFlickableBehindSlider are
unstable.
Task-number: QTBUG-73983
Change-Id: I220869a0a6e7beb69d7273b0edc66ac067ebcd38
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
|
| |
The usual problem is that Flickable doesn't instantly jump to the
expected position but moves there after a delay.
Change-Id: Iafc9dd493b97629377e7f7c60ae7adde13427bae
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
So far it was checking parentContains() on press, release, or when
the gesturePolicy is WithinBounds, but not for each movement when the
policy is DragThreshold (the default). This might explain most of the
remaining warning noise: "pointId is missing from current event, but was
neither canceled nor released" because it was possible for TapHandler
to remember wanting a point that it should not have wanted, but without
taking any kind of grab, and then complaining when that point was no
longer present. Since it did not grab, it did not get the release,
unless the release was part of an event containing a point that it
DID grab.
Fixes: QTBUG-71887
Change-Id: I26ce62279574cf6b0150f24e486f224a604ac6b1
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
QQuickItemPrivate::data_append() was not invoked when any kind of
Pointer Handler was directly declared in a Flickable (or subclass)
because QQuickFlickable redefines the default property to be its own
flickableData property. So we need to repeat the special handling
in QQuickFlickablePrivate::data_append() too. The handler must
be added to the private->extra->pointerHandlers vector, so that
QQuickItemPrivate::handlePointerEvent() will attempt to deliver
events to those handlers.
TapHandler seems OK (especially with its default gesturePolicy
so that it does not do an exclusive grab).
PointHandler seems OK.
DragHandler competes with Flickable for the exclusive grab.
pressDelay can help; or set acceptedDevices: PointerDevice.Mouse
to allow the mouse to drag but not flick, and the touchscreen
to flick but not drag.
Fixes: QTBUG-71918
Fixes: QTBUG-73035
Change-Id: Icb97ed5230abe0cb6ec0230b5b5759a0528df7e8
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Until now, AA_SynthesizeMouseForUnhandledTouchEvents has only affected
behavior of QGuiApplicationPrivate::processTouchEvent, but had no
effect in Qt Quick. QQuickWindow also accepts the touch event
just to make sure that QGuiApplication will not synthesize mouse
from touch, because it would be redundant: QQuickWindow does that
for itself.
Now we make it have an effect in Qt Quick too: skip mouse synthesis
if it is set to false. This provides a way to simplify the
event delivery. If you set it false, then you cannot manipulate old
mouse-only items like MouseArea and Flickable on a touchscreen.
(You can of course use event handlers for that.)
[ChangeLog][QtQuick][QQuickWindow] You can now disable touch->mouse
event synthesis in QtQuick by calling
qGuiApp.setAttribute(Qt::AA_SynthesizeMouseForUnhandledTouchEvents, false);
This will simplify and speed up event delivery, and it will also prevent
any and all interaction with mouse-only items like MouseArea and
Flickable on a touchscreen.
Task-number: QTBUG-52748
Change-Id: I71f1731b5abaeabd9dbce1112cd23bc97d24c12a
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
|
|
|
|
|
|
| |
Don't slow down CI for logging unless the test fails.
Change-Id: I2d5faedf3fadb30ec5a732445d695bda7e290233
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is important in order for passive grabbers to be in the same order
as if the points were pressed at the same time.
In our case, the problem occurred when we had a single-point DragHandler
together with a two-finger PinchHandler:
* One finger was pressed and moved
=> DragHandler called setPassiveGrab()
=> point0->passiveGrabbers: [DragHandler]
* A second finger was pressed and moved
=> PinchHandler called setPassiveGrab() for both points
=> point0->passiveGrabbers: [DragHandler,PinchHandler]
=> point1->passiveGrabbers: [PinchHandler]
So then as one keeps on dragging the *two* fingers, the DragHandler will
get the chance to do an exclusive grab first, (since its the first listed
passive grabber of point0), and the PinchHandler won't get the opportunity
to grab. This is not expected since their declaration order implies that
the PinchHandler should get a chance to grab first.
Change-Id: I4e82ed186eeb5bf1dae1679d393e5563072175d1
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>
|
|
|
|
|
|
|
|
|
|
|
| |
When there's a DragHandler on one Item and a TapHandler on another,
we have more trouble with Flickable stealing the grab. We need a
test to ensure that this problem doesn't reappear after fixing.
Task-number: QTBUG-64846
Change-Id: Ia3bc3b7c9654f09aa96ad70968d82b566686e030
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We need Handlers to receive accurate positions for stationary touch
points: that is, the last-known position from the previous touch
event. (And we hope that all actual touch-capable platforms also send
proper QPA events with correct positions for stationary points.
We assert that it's a bug if they don't.)
As explained in qtbase 7cef4b6463fdb73ff602ade64b222333dd23e46c, it's
OK to retain a copy of a QTest::QTouchEventSequence for this purpose,
so that the QMap<int, QTouchEvent::TouchPoint> previousPoints will not
be discarded between events.
We have done this in other tests, but not consistently; e.g.
468626e99a90d6ac21cb311cde05c658ccb3b781 fixed the PinchArea test.
Change-Id: I4dbe69f8dcc4b1cca30fd7ce91d7d2ecf5ec4bc3
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
|
|
|
|
|
|
| |
It was too hard to debug behavior in this test.
Change-Id: Iaec9534cca17bdd90b94cfa8fa8b21b7026839ae
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
..while its (ancestor) coordinate system has changed during the drag.
For example, ensure that a DragHandler-based Slider keeps its knob centered.
If the Slider is used on a Flickable which you are flicking with a second
finger, then the coordinate system is changing underneath the Slider.
The problem was that DragHandler stored the initial drag position of the
target when the target item was pressed, and used that throughout the
whole drag operation. Unfortunately if the target item was inside a
Flickable that got flicked during a drag operation, that initial position
was not updated (and thus, incorrect).
Instead of storing the initial target position in scene coordinates, we
now store the position that got pressed in local target coordinates, and
ensure that in any further updates the touchpoint have the same local
position (by moving the target).
Task-number: QTBUG-64852
Change-Id: I25012d34d88f45c7eb9c711db0037d530cf10854
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|\
| |
| |
| | |
Change-Id: I64bf7d183bbd8af7282270097809d14a54ba0188
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This got regressed by change e6d4df156e9aec62054740dc99ab8ba2855eaafc. Before
that change, we always cleared both the exclusive and passive grabbers.
Task-number: QTBUG-66152
Change-Id: I93d2568bd2a23ddd55a5294d544f978a50a5543e
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|/
|
|
|
|
|
|
|
|
| |
Make sure the Rectangles we're sending the touch events to are
visible on screen, otherwise I get consistent failures in this
test on Linux.
Change-Id: Icc2ba7ba73c434dd2ef725adbaa57ab6d413f354
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
| |
Change-Id: Ib1fe267c23ea9fce9bcc0a91ed61081260338460
Reviewed-by: Liang Qi <liang.qi@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If an item that had a TapHandler and a DragHandler was placed inside a
Flickable it would call sendFilteredPointerEvent() for each of the
handlers, even if they were siblings.
This is not ideal, and because of a mechanism in flickable it even caused
the DragHandler to not drag the item as expected.
This is because of a mechanism in Flickable where the value returned is
actually derived from the previous call to filterMouseEvent() (stored in
member variable stealGrab).
Below are the relevant steps it went through when the mouse drag exceeded
the drag threshold (mouse pointer started on the item):
Precondition: QQuickFlickablePrivate::stealMouse == false
1. Mouse Drag (which exceeded drag threshold)
2. sendFilteredPointerEvent(tapHandler->parentItem()) returns false.
(but since it moved beyond threshold, it would set stealGrab-> true).
3. tapHandler->handlePointerEvent() declined and ungrabbed (due to
DragThreshold gesture policy).
4. sendFilteredPointerEvent(dragHandler->parentItem()) returns true
(because the previous call to sendFilteredPointerEvent() set stealGrab
to true).
As a consequence of (4), dragHandler->handlePointerEvent() was not called,
and the flickable would start to flick instead of the item starting to drag.
Change-Id: Ia99eae91cad0903ebbaedaaafcdf92a25705a922
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
|
|
| |
This is for the sake of convention. Unfortunately (and the reason
it wasn't done this way at the outset), it may prevent us from ever
having a signal called "pressed" in this handler or its base class.
Change-Id: Iafa117410e0e33562290b87df59bc8c0085c217d
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
|
|
|
|
|
|
|
| |
5d4f488bf30f5650051d6cc226a75dbd17cd9a70 changed some APIs, but it forgot
to update all autotests.
Change-Id: I2a0ca14dbc1a0dddcbad597389c00d5e6f6c8b79
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
| |
Change-Id: If3d9e10bb54fc75a7e72bc6367de3e083611a45f
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
|
Flickable can steal the grab from a PointerHandler the same way it can
steal from an Item: by filtering the children's events. But within
the drag threshold, or if the DragHandler is dragging, the handlers
behave normally.
Change-Id: If1bc1f2e8d9aaebb590f3434a3018a9f1a1f1dac
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|