aboutsummaryrefslogtreecommitdiffstats
path: root/tests/auto/quick/pointerhandlers/flickableinterop/data
Commit message (Collapse)AuthorAgeFilesLines
* Add handlers declared as Flickable children to its contentItemShawn Rutledge2019-01-226-0/+432
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* 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-123-12/+140
| | | | | | | | | | | 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>
* Add cat. logging in wantsEventPoint; improve FlickableInterop testShawn Rutledge2018-06-291-1/+7
| | | | | | | It was too hard to debug behavior in this test. Change-Id: Iaec9534cca17bdd90b94cfa8fa8b21b7026839ae 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-271-1/+77
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-153-6/+20
| | | | | 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-284-0/+369
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-06-22 00:18:11 +0000