aboutsummaryrefslogtreecommitdiffstats
path: root/tests/auto/quick/pointerhandlers/qquickdraghandler
Commit message (Collapse)AuthorAgeFilesLines
* Remove the qmake project filesFabian Kosmale2021-01-151-22/+0
| | | | | | | | | Remove all qmake project files, except for examples which are used to test that qmake continues to work. Change-Id: Ic4abb72dc2dcd75df7a797c56056b6b3c5fe62ac Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* CMake: Regenerate projects to use new qt_internal_ APIAlexandru Croitor2020-10-061-3/+3
| | | | | | | | 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>
* Handle ungrab and grab-cancel consistently; inform handlersShawn Rutledge2020-09-261-8/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Blacklist tests due to QPointerEvent changesShawn Rutledge2020-09-181-0/+8
| | | | | | | | | | | | | | | | 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>
* Remove QQuickPointerEvent etc.; deliver QPointerEvents directlyShawn Rutledge2020-09-181-9/+9
| | | | | | | | | | | | | | | | | | | | | | | QEventPoint does not have an accessor to get the QPointerEvent that it came from, because that's inconsistent with the idea that QPointerEvent instances are temporary, stack-allocated and movable (the pointer would often be wrong or null, therefore could not be relied upon). So most functions that worked directly with QQuickEventPoint before (which fortunately are still private API) now need to receive the QPointerEvent too, which we choose to pass by pointer. QEventPoint is always passed by reference (const where possible) to be consistent with functions in QPointerEvent that take QEventPoint by reference. QEventPoint::velocity() should be always in scene coordinates now, which saves us the trouble of transforming it to each item's coordinate system during delivery, but means that it will need to be done in handlers or applications sometimes. If we were going to transform it, it would be important to also store the sceneVelocity separately in QEventPoint so that the transformation could be done repeatedly for different items. Task-number: QTBUG-72173 Change-Id: I7ee164d2e6893c4e407fb7d579c75aa32843933a Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Update tst_DragHandler::mouseDragThreshold zero-threshold test caseShawn Rutledge2020-07-281-7/+8
| | | | | | | | | | | | | | | | | After qtbase b50daef9771d8829fc7f808898cbe051a5464b79, a mouse move event that does not contain a mouse location different than the last known location is no longer delivered. It's intended to be OK to set DragHandler.threshold to 0, and this test was checking functionality in that case; but we now need to move the mouse at least one pixel to test it. Then, the drag threshold is immediately exceeded, the drag begins, translation starts to occur, etc. Amends ab5df626bef9365089ce716ce476bccae1d0a04b Task-number: QTBUG-85431 Change-Id: I89c0dc13ed06fbf1443f42fa5b63713da56ecf6d Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Update the window cursor on mouse releaseShawn Rutledge2020-06-302-1/+14
| | | | | | | | | | | | | | | | When a PointerHandler with a custom cursor deactivates, the cursor wasn't restored until the next mouse move. I was writing a test to ensure that there were no bugs analogous to QTBUG-85303 with a handler that uses its active state to change the cursor (unlike HoverHandler which changes it whenever the mouse is hovering) and found this new bug. Pick-to: 5.15 Fixes: QTBUG-85325 Task-number: QTBUG-85303 Change-Id: I4ea8dbd267046c8e972e723cc491bd44bbbfd7f2 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Remove QQuickPointerDevice in favor of QPointingDeviceShawn Rutledge2020-06-231-10/+8
| | | | | | | | | | | | | | ...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>
* CMake: Update Apple platform defines after rename in qtbaseTor Arne Vestbø2020-03-171-2/+2
| | | | | Change-Id: Ia0a075e3199eab735f9b289873beeb8730ebc47e Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Merge remote-tracking branch 'origin/dev' into wip/cmakeAlexandru Croitor2020-03-122-3/+17
|\ | | | | | | | | | | | | | | Conflicts: dependencies.yaml src/qml/qml/qqmlengine.cpp Change-Id: I6a73fd1064286f4a2232de85c2ce7f80452d4641
| * Add PointerHandler.cursorShape propertyShawn Rutledge2020-01-312-3/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Also, QQuickItemPrivate::setHasCursorInChild() was unable to check the QQuickItemPrivate::hasCursor variable, because the function argument hasCursor was shadowing that, even though the comment "nope! sorry, I have a cursor myself" hints that the intention was to check that. So this change exposed a problem there, and we have to fix that too, in order to keep the tst_qquickwindow::cursor() test passing. [ChangeLog][Event Handlers] Pointer Handlers now have a cursorShape property to set the cursor when the handler is active and the mouse is hovering, and restore to the previous cursor when the mouse leaves. Fixes: QTBUG-68073 Change-Id: Ib5c66bd59c4691c4210ee5465e1c95e7bdcf5ae1 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* | Regenerate qtdeclarativeAlexandru Croitor2020-02-121-5/+2
| | | | | | | | | | | | | | 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>
* | Regenerate all projects with new CMake API versionAlexandru Croitor2019-11-151-3/+3
| | | | | | | | | | | | Change-Id: Ie0db35f674137c229eaf049616f38f8e818f7092 Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* | Regenerate testsAlexandru Croitor2019-11-141-9/+2
| | | | | | | | | | | | Change-Id: I67a6c8f1659e7b471a4fcb92a2699292cf4eea81 Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* | Merge remote-tracking branch 'origin/dev' into wip/cmakeAlexandru Croitor2019-10-141-2/+97
|\| | | | | | | | | | | | | Removed dependencies.yaml because we don't use it yet in wip/cmake. Fixed conflict in qmlcachegen.cpp. Change-Id: Ie1060c737bee1daa85779903598e5b6d5020d922
| * Add dragThreshold property to Event HandlersShawn Rutledge2019-09-191-2/+97
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We need drag threshold to be adjustable on each handler instance instead of relying only on the system default drag threshold. For example in some use cases DragHandler needs to work with a threshold of 0 or 1 to start dragging as soon as the point is pressed or as soon as the point is moved, with no "jump", to enable fine adjustment of a value on some control such as a Slider. This involves moving the dragOverThreshold() functions that handlers are using from QQuickWindowPrivate to QQuickPointerHandlerPrivate, so that they can use the adjustable threshold value. Task-number: QTBUG-68075 Change-Id: Ie720cbbf9f30abb40d1731d92f8e7f1e6534eeb5 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* | Merge remote-tracking branch 'origin/wip/qt6' into wip/cmakeAlexandru Croitor2019-08-151-27/+55
|\| | | | | | | Change-Id: I6f2152aeecaeb8e63fdbc1cdf1444132a054b6f5
| * Merge remote-tracking branch 'origin/5.13' into devLiang Qi2019-07-261-27/+55
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: src/quick/handlers/qquickpointerdevicehandler.cpp src/quick/scenegraph/qsgdefaultglyphnode.cpp src/quick/scenegraph/qsgdefaultglyphnode_p.cpp src/quick/scenegraph/qsgdefaultglyphnode_p_p.h tests/auto/qml/qjsengine/tst_qjsengine.cpp Done-With: Jan Arve Sæther <jan-arve.saether@qt.io> Done-With: Laszlo Agocs <laszlo.agocs@qt.io> Change-Id: I35749152f8dce44b9af8d52b1283629879010f11
| | * Move Event Handler acceptedButtons check back up to QQPDeviceHandlerShawn Rutledge2019-07-051-27/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Reverts what's left of e53510944169ac9f6753e0d14e1b24a24ff7bd9a (amends 73258eca7ab7e3981d9f4aaa5484020cb67854a0): MultiPointHandler is not only for touch handling anymore. DragHandler in particular needs to respect the acceptedButtons property. Fixes: QTBUG-76875 Fixes: QTBUG-76582 Change-Id: I414e785dd09b297c93e5e9f162be23e4a44eca54 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* | | Add QtDeclarative Test CoverageLeander Beernaert2019-08-141-0/+57
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* / Add snapMode to DragHandlerJan Arve Sæther2019-05-163-0/+161
|/ | | | | | | | | | | | | | | | | This changes snap behavior slightly. Basically, it does not snap anymore if the target() item is an ancestor of the parentItem(). In addition, we add a property that enables users to change the behavior. (SnapIfPressedOutsideTarget has the old behavior) [ChangeLog][QtQuick][Event Handlers] Added DragHandler.snapMode which can be used to configure under which conditions the dragged item is snapped to be below the cursor. The default mode is SnapAuto. The old behavior can be obtained through the SnapIfPressedOutsideTarget mode. Fixes: QTBUG-75661 Change-Id: Ibc00e8fbe31b779f8e817af1505e76425467d27a Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* If DragHandler is dragged within its margin, don't jumpShawn Rutledge2019-04-052-0/+69
| | | | | | | | | | | | | | | | | Not being pressed inside the target is a necessary but not sufficient reason to reset m_pressTargetPos to the center of the target. The intention was rather to make the target jump into position when the parent was a different item: e.g. if a Slider has a DragHandler whose target is the slider's knob, you can start dragging anywhere on the whole Slider but you want the knob to jump to the cursor position when the drag begins. While we're at it, both branches of the if in onGrabChanged() are checking that target() isn't null, so we can move that check out. Fixes: QTBUG-74966 Change-Id: I05be11d27422b070d941b9e43d4e1157e071c3a5 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* Fix bug where QQMPH kept an exclusive grab when no buttons were pressedJan Arve Sæther2019-02-062-0/+107
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This happened if you moved the mouse while doing a multitouch operation. More specifically this caused the bug: 1. Open qtdeclarative/tests/manual/pointer/map.qml 2. Rotate the map with two fingers (Do not release fingers). 3. Move mouse (no buttons pressed). 4. Release both fingers. 5. Move mouse again (error: the draghandler has a grab and thus the map is dragged even if no buttons are down). This happened because if you moved the mouse while having two fingers down, Windows would generate a *mouse*move* event with Left button or Right button pressed (which wasn't the case on the physical device but it's probably because of a bug in how mouse events are synthesized from touch on Windows). This caused the QQuickMultiPointHandler to do a passive grab. Then, when releasing the fingers it would not send a mouse release event (just plain touch release events), so the QQuickMultiPointHandler would keep the passive grab it had. All subsequent mouse move events would then be dispatched to the QQuickMultiPointHandler where it would assume that the button was pressed until it got a release event (but button was never pressed so that wouldn't happen). Eventually it would perform an exclusive grab, and dragging was initiated. Change-Id: I42b3133c5fde93c7f92f1cb28705156a69f9ad1c Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* MultiPointHandler: ensure centroid properties are reset after releaseShawn Rutledge2018-08-221-0/+19
| | | | | | | | | | | ...and verify the centroid changes in the DragHandler autotest. It was observable in manual tests that draw velocity vectors that they weren't getting reset to zero after the release, after ca7cdd71ee33f0d77eb6bf1367d2532e26155cb2. Change-Id: I16186d36d51a567b0d653307421147264a5e6326 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* Make DragHandler a MultiPointHandlerShawn Rutledge2018-07-192-53/+74
| | | | | | | | | | 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-176-12/+6
| | | | | | | ... 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-6/+7
| | | | | | | | | | | | | | | | | | | 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>
* 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>
* Do not stop delivering to handlers if all points are acceptedJan Arve Saether2018-01-313-2/+203
| | | | | | | | | | | Some Pointer Handlers can perform the desired interaction using only passive grabs. When such a handler is used to modify behavior of another event-handling Item or Handler which needs to take the exclusive grab, this allows them to cooperate: both can see the updates, and neither prevents delivery of events to both. Change-Id: I312cc301c52fcdf805245bbe0ac60fd28f92c01f Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Fix outdated BSD license headerKai Koehne2017-11-155-137/+77
| | | | | Change-Id: Ib1fe267c23ea9fce9bcc0a91ed61081260338460 Reviewed-by: Liang Qi <liang.qi@qt.io>
* Let passive-grabbing PointerHandlers see all point updatesShawn Rutledge2017-11-141-5/+4
| | | | | | | | | | | even if all points are accepted or grabbed. A passive grab isn't much good if there are cases where the handler is prevented from monitoring. This enables e.g. the PinchHandler to steal the grab when the right number of touchpoints are present and have moved past the drag threshold, and enables completion of a couple of autotests. Change-Id: I78dc6fc585f80bfb3c13e0c6e757ef815fb94afe Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* change the type of DragHandler::translation to QVector2D; document itShawn Rutledge2017-09-291-1/+1
| | | | | | | | For consistency we use QVector2D to represent relative movements in all Pointer Handlers. Change-Id: I23dc20c360b482a995d232e8a6d7e87d9bd8f600 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* rename TapHandler.isPressed property to pressedShawn Rutledge2017-09-122-4/+4
| | | | | | | | | 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>
* Update according to new "point" API of single handlerJan Arve Saether2017-05-311-1/+1
| | | | | Change-Id: Ia67dd04333a7879362819e1bb2a891c1f92b7069 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Add autotest for DragHandlerShawn Rutledge2017-05-298-0/+963
Change-Id: I46f7e2c16b775723a08aa192845d490046231990 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-19 16:06:02 +0000