aboutsummaryrefslogtreecommitdiffstats
path: root/tests/auto/quick/pointerhandlers/flickableinterop
Commit message (Collapse)AuthorAgeFilesLines
* Blacklist ...::touchDragFlickableBehindButton() on mingwUlf Hermann2019-04-171-0/+2
| | | | | | Task-number: QTBUG-75224 Change-Id: Ic7daefa2f0422a0b1cfa112fd5412cafffb2a9ed Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Blacklist tests in tst_FlickableInteropUlf Hermann2019-02-211-0/+4
| | | | | | | | | touchAndDragHandlerOnFlickable and touchDragFlickableBehindSlider are unstable. Task-number: QTBUG-73983 Change-Id: I220869a0a6e7beb69d7273b0edc66ac067ebcd38 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Try to fix flakiness in flickableinterop testUlf Hermann2019-02-071-1/+1
| | | | | | | | 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>
* TapHander: do not "want" an eventPoint that is outside parent boundsShawn Rutledge2019-01-301-3/+7
| | | | | | | | | | | | | | | | | 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>
* Add handlers declared as Flickable children to its contentItemShawn Rutledge2019-01-227-0/+570
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* QQuickWindow: obey AA_SynthesizeMouseForUnhandledTouchEventsShawn Rutledge2018-08-061-10/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* tst_FlickableInterop: use categorized logging rather than qDebugShawn Rutledge2018-08-061-6/+6
| | | | | | | 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>
* Call clearGrabbers each time we get a press eventJan Arve Sæther2018-07-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Make DragHandler a MultiPointHandlerShawn Rutledge2018-07-191-1/+1
| | | | | | | | | | 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>
* Get rid of Qt.labs.handlers import, merge into QtQuick 2.12Shawn Rutledge2018-07-174-8/+4
| | | | | | | ... and clean up imports in examples, snippets and tests accordingly. Change-Id: I5bbe63afd2614cdc2c1ec7d179c9acd6bc03b167 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* tst_FlickableInterop: test both usages of DragHandler in a SliderShawn Rutledge2018-07-124-32/+195
| | | | | | | | | | | 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>
* Input handler tests: remember positions of stationary pointsShawn Rutledge2018-07-031-8/+9
| | | | | | | | | | | | | | | | | | | 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>
* Add cat. logging in wantsEventPoint; improve FlickableInterop testShawn Rutledge2018-06-292-34/+19
| | | | | | | It was too hard to debug behavior in this test. Change-Id: Iaec9534cca17bdd90b94cfa8fa8b21b7026839ae Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Fix draghandler to respect axis constraintsJan Arve Sæther2018-02-211-0/+86
| | | | | | | | | | | | | | | | | | | | | | | ..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>
* Merge remote-tracking branch 'origin/5.10.1' into 5.11Qt Forward Merge Bot2018-02-151-0/+14
|\ | | | | | | Change-Id: I64bf7d183bbd8af7282270097809d14a54ba0188
| * Make sure passive grabbers are cleared on releaseJan Arve Saether2018-02-021-0/+14
| | | | | | | | | | | | | | | | | | 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>
* | Stabilize the flickableinterop autotestLars Knoll2018-02-081-2/+2
|/ | | | | | | | | | 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>
* Fix outdated BSD license headerKai Koehne2017-11-154-109/+61
| | | | | Change-Id: Ib1fe267c23ea9fce9bcc0a91ed61081260338460 Reviewed-by: Liang Qi <liang.qi@qt.io>
* Fix a bug with TapHandler+DragHandler on top of FlickableJan Arve Sæther2017-10-272-1/+154
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* rename TapHandler.isPressed property to pressedShawn Rutledge2017-09-122-5/+5
| | | | | | | | | 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>
* Fix autotests to run with the new APIJan Arve Saether2017-05-231-2/+2
| | | | | | | | 5d4f488bf30f5650051d6cc226a75dbd17cd9a70 changed some APIs, but it forgot to update all autotests. Change-Id: I2a0ca14dbc1a0dddcbad597389c00d5e6f6c8b79 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* tst_flickableinterop: test buttons with all gesturePolicy valuesShawn Rutledge2017-05-154-12/+70
| | | | | Change-Id: If3d9e10bb54fc75a7e72bc6367de3e083611a45f Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* Add tst_flickableinterop: verify drag and tap handlers inside FlickableShawn Rutledge2017-04-286-0/+815
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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-05 12:27:56 +0000