aboutsummaryrefslogtreecommitdiffstats
path: root/tests/auto/quick/pointerhandlers/qquicktaphandler
Commit message (Collapse)AuthorAgeFilesLines
* Merge 5.12 into 5.12.1Kari Oikarinen2019-01-082-0/+80
|\ | | | | | | Change-Id: Ic746fbce93430867e2eda4bc7155d34e20a4aa2b
| * TapHandler: ignore scroll events and native gesturesShawn Rutledge2018-12-102-0/+80
| | | | | | | | | | | | | | | | | | | | | | | | | | | | During a 2-finger press (to emulate right click on a trackpad), the OS may also generate a QWheelEvent with ScrollBegin phase just in case scrolling starts. This must not prematurely deactivate the TapHandler. Also if a gesture or wheel event begins as the very first event after an application starts, ensure that subsequent mouse events are not mis-delivered as wheel or gesture events. Fixes: QTBUG-71955 Change-Id: Ic12e116483ab9ad37c4ac3b1d10ccb62e1349e0a Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* | TapHandler: clean up when wantsEventPoint returns falseShawn Rutledge2018-12-132-0/+56
|/ | | | | | | | | | | | | | | We already emitted grabCanceled() to inform QML callbacks, but we didn't call reset(). It seems more proper to do everything that would normally be done when grab is canceled. TapHandler should not give up its passive grab yet though, because that prevents delivery to any parent Flickable that might be filtering events. A parent Flickable should be able to start flicking after the drag threshold is exceeded (it happens to be exactly when TapHandler gives up). Fixes: QTBUG-71466 Fixes: QTBUG-71970 Change-Id: Ibba1b0de92cfd88547eeb44edb095d019de76a94 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Rename QQEventPoint::GrabState to GrabTransitionShawn Rutledge2018-08-311-2/+2
| | | | | | | | | | | | | | | | | | | This enum represents a transient state transition, and only sometimes corresponds to the current grab state of an event point. For example after exclusive grab has been canceled, the current state is that there is no exclusive grab: it doesn't make sense to remember that the way it got there was by cancellation. There was an idea to add a grabState property, but not all values would be eligible. An EventPoint can be exclusively grabbed by one item or handler at a time, and by multiple passive grabbers at the same time, so even a Q_FLAG would not fully express all possible states. Besides, there is already an exclusiveGrabber property, and we could add a passiveGrabbers list property if we had a real need. So adding a grabState property seems unlikely, and therefore is not a good enough reason to keep this enum named as GrabState. Change-Id: Ie37742b4bd431a7e51910d79a7223fba9a6bd848 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-173-6/+3
| | | | | | | ... and clean up imports in examples, snippets and tests accordingly. Change-Id: I5bbe63afd2614cdc2c1ec7d179c9acd6bc03b167 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* Input handler tests: remember positions of stationary pointsShawn Rutledge2018-07-031-9/+10
| | | | | | | | | | | | | | | | | | | 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>
* PointerHandler.grabChanged signal: add stateChange parameterShawn Rutledge2018-06-271-2/+2
| | | | | | | | | To make grabChanged signal useful, it's necessary to know whether the Pointer Handler has acquired or lost the grab. This patch fixes that. Task-number: QTBUG-68074 Change-Id: I29398d2bb5b27b8541197f23c3043ee86cad7c76 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* use nullptr consistently (clang-tidy)Shawn Rutledge2018-02-261-1/+1
| | | | | | | | | | | | | 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>
* Change default TapHandler.gesturePolicy to DragThresholdShawn Rutledge2018-01-311-0/+1
| | | | | | | | | | | | | This is based on the idea that TapHandler may be more often used to modify existing behavior rather than building Button controls from scratch. DragThreshold is reasonable newbie-friendly default behavior for both use cases. The drag-off-drag-back-release-and-click behavior is more advanced, and the designers of the best-behaving Button controls can be expected to discover the need to change gesturePolicy to get it. Change-Id: If220acf080e04f664d020d5e832f8d16a16b857a Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* prepend PointerHandler children of Items so the last is visited firstShawn Rutledge2017-11-232-0/+81
| | | | | | | | | | | | | | | 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>
* Fix outdated BSD license headerKai Koehne2017-11-153-83/+47
| | | | | Change-Id: Ib1fe267c23ea9fce9bcc0a91ed61081260338460 Reviewed-by: Liang Qi <liang.qi@qt.io>
* rename TapHandler.isPressed property to pressedShawn Rutledge2017-09-121-3/+3
| | | | | | | | | 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>
* Move properties into grouped "point" propertyJan Arve Saether2017-05-231-2/+2
| | | | | Change-Id: I80000110a2e0ca69210322a0fcc587d86158358e Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* TapHandler longPress autotest: be less demanding about hold timeShawn Rutledge2017-04-241-2/+2
| | | | | | | It's hitting slightly less than the expected amount of time in CI. Change-Id: I51ab1ee385045dd948f52e0c27e72ce627952fd6 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* add autotest for TapHandlerShawn Rutledge2017-04-215-0/+828
Change-Id: Idc516220365b3051e072506ede3f3159b0b736b2 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-24 01:52:01 +0000