aboutsummaryrefslogtreecommitdiffstats
path: root/tests/auto/quick/pointerhandlers/flickableinterop
Commit message (Collapse)AuthorAgeFilesLines
* 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>