aboutsummaryrefslogtreecommitdiffstats
path: root/tests/auto/quick/pointerhandlers/qquickdraghandler/tst_qquickdraghandler.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Update the window cursor on mouse releaseShawn Rutledge2022-03-171-0/+12
| | | | | | | | | | | | | | | | | 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. Fixes: QTBUG-85325 Task-number: QTBUG-85303 Change-Id: I4ea8dbd267046c8e972e723cc491bd44bbbfd7f2 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> (cherry picked from commit 8bd6342639721b7db08acf554c6bcd3e7ab04cb6) Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Don't let PointerHandler steal mouse grab from keepMouseGrab layerShawn Rutledge2021-07-191-0/+54
| | | | | | | | | | | | | | | As explained in the comment, the handler can override the keepMouseGrab "veto" if the item is a parent (like a Flickable) that filters events, but not in other cases. The logic was wrong though, apparently. Amends 090f404cf80da35734f712b02cc1543acecd5b62 Fixes: QTBUG-78258 Task-number: QTBUG-79163 Change-Id: I9a473ab3b23743f863cb0be13767fdbc29cd5e1c Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> (cherry picked from commit b09ce7dcd8ecf24ef23da8197a64e3fced3fc894)
* Update tst_DragHandler::mouseDragThreshold zero-threshold test caseShawn Rutledge2020-08-241-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> (cherry picked from commit 051e18a02fcdcb177cd602665424e53253f4d88c)
* Add PointerHandler.cursorShape propertyShawn Rutledge2020-01-311-1/+14
| | | | | | | | | | | | | | | | | | 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>
* 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/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 snapMode to DragHandlerJan Arve Sæther2019-05-161-0/+74
|/ | | | | | | | | | | | | | | | | 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-051-0/+33
| | | | | | | | | | | | | | | | | 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-061-0/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-191-50/+70
| | | | | | | | | | 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>
* 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-311-1/+84
| | | | | | | | | | | 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>
* 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>
* Add autotest for DragHandlerShawn Rutledge2017-05-291-0/+405
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-05-07 15:54:12 +0000