aboutsummaryrefslogtreecommitdiffstats
path: root/tests/auto/quick/pointerhandlers/qquickdraghandler/tst_qquickdraghandler.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Only activate DragHandler if drag starts within itShawn Rutledge2025-06-241-0/+28
| | | | | | | | | | | | | | Previously, starting a mouse drag outside a DragHandler's parent and moving inside would activate it. This is unexpected behavior, inconsistent with touch behavior, and might interfere with other drags, so we only activate a DragHandler if at least one point was pressed inside the parent. Pick-to: 6.10 6.9 6.8 Fixes: QTBUG-127863 Change-Id: I2215636397ce9fc6a29b9a35165507e5b8d886f4 Reviewed-by: Santhosh Kumar <santhosh.kumar.selvaraj@qt.io> Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* Add PinchHandler and DragHandler 2-finger inside/outside testsShawn Rutledge2025-06-201-0/+51
| | | | | | | | | | | | | | | | | These should already behave the same with much-older Qt versions: so far, multi-point handlers require all points to be pressed inside the parent Item. Although DragHandler has long supported setting minimumPointCount to require more than one finger, we didn't have test coverage for that. So far the main "real" use case is the 2-finger tilt gesture in maps (in which case target is null), but it can also be used for dragging a target with more than one finger. Pick-to: 6.10 6.9 6.8 Task-number: QTBUG-127863 Change-Id: I2d4734f12a31a4b720bd11c05a61bc0cdc3b84ce Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* Map DragHandler delta to the sceneAleksandr Timofeev2025-05-151-0/+51
| | | | | | | | | | | | | Previously, DragHandler didn't account for scene transforms when calculating drag threshold. In the case when one axis is disabled, and the scene is rotated 90 degrees, the remaining axis should be activated by movements that are nominally the same as the disabled direction, because of rotation. Fixes: QTBUG-136354 Pick-to: 6.8 6.9 Change-Id: I6669949908b0d026850411c10056685648a109d9 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* tests: do not leak QPointingDevice instancesShawn Rutledge2025-05-101-26/+25
| | | | | | | | | QTest::createTouchDevice() passes ownership of the device to the caller, so make sure it gets deleted. Pick-to: 6.8 6.9 Change-Id: I1289def6b40bf688a7334b9997f7e4319516d018 Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
* Tests: include QTest, not QtTestGiuseppe D'Angelo2025-04-151-1/+2
| | | | | | | | | | | | | Never use module-wide inclusions. They blow up build times. For QtTest this is usually just a typo (QTest was meant instead). Add missing includes as needed. In the diffs I've spotted other huge inclusions (QtQuick, QtQml), but those need more attention. Task-number: QTQAINFRA-7110 Pick-to: 6.9 6.8 Change-Id: I74bf3fe212f50a7a3a6af2b1c80bbcaabc2516d7 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* DragHandler: Don't change QEventPoint accepted state in touch eventsDoris Verria2024-08-301-0/+62
| | | | | | | | | | | | | | | | | | | | | | QQuickDragHandler::handlePointerEventImpl() accepts the event to begin with. Since ca7cdd71ee33f0d77eb6bf1367d2532e26155cb2 we meant to stop event propagation for mouse events, at least to prevent Flickable from receiving the event via direct delivery after it has already filtered. But back then, QEvent::setAccepted() did not automatically accept the touchpoints; now it does (a questionable choice in Qt 6 that accept() and setAccepted(true) do not do the same thing). Now we leave QEventPoint:isAccepted state alone if it's a touch event, so the workaround to stop propagation of mouse events is the only case where it needs to be changed. And update the comment: since 3073a81e90c8d835dfccccf8b3a080a93ed0d2af Flickable handles touch events directly, it doesn't depend on touch->mouse synthesis. Fixes: QTBUG-124731 Pick-to: 6.8 6.7 Change-Id: I833a4d28f708e27cf01b108da1b886807725dc06 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* Correct license for test filesLucie Gérard2024-02-271-1/+1
| | | | | | | | | | | | | | According to QUIP-18 [1], all test files should be LicenseRef-Qt-Commercial OR GPL-3.0-only [1]: https://contribute.qt-project.org/quips/18 Pick-to: 6.7 Task-number: QTBUG-121787 Change-Id: I26d72e8de04d4c7c57b3b7838af5d033265de5ba Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Kai Köhne <kai.koehne@qt.io> Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Include what you need: <QPointer>Marc Mutz2023-10-061-0/+2
| | | | | | | | | | | | | | | | | | | | | | | All these TUs relied on transitive includes of qpointer.h, maybe to a large extent via qevent.h, though, given that qevent.h is more or less the only public QtBase header that includes qpointer.h, something else seems to be at play here. Said qevent.h actually needs QPointer in-name-only, so a forward declaration would suffice. Prepare for qevent.h dropping the include. The algorithm I used was: If the TU mentions 'passiveGrabbers', the name of the QEvent function that returns QPointers, and the TU doesn't have qpointer.h included explicitly, include it. That may produce False Positives, but better safe than sorry. Otherwise, in src/, add an include to all source and header files which mention QPointer. Exception: if foo.h of a foo.cpp already includes it, don't include again. Task-number: QTBUG-117670 Change-Id: I9b98cda524a0e6a61be7805edda708916bb2bc2b Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Improve DragHandler tests for easier troubleshootingShawn Rutledge2023-01-091-1/+1
| | | | | | | | | | | - Sometimes you just need to see the touchpoints and centroids - Delay long enough to see them - Avoid QTRY_COMPARE when we're sure the event was already flushed - Fix indentation Pick-to: 6.5 Change-Id: I307963378c29fb285190657e7a0693888ad7c48c Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* Pointer handlers: don't emit canceled() when an extra button interruptsShawn Rutledge2022-12-151-0/+65
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the intention is that a handler should react only to the left mouse button (by default, acceptedButtons == Qt.LeftButton), and the user presses the right button while the handler is already active, it de-activates, because wantsPointerEvent() returns false. But now it will no longer emit canceled() in that case. The docs for the canceled signal say "If this handler has already grabbed the given point, this signal is emitted when the grab is stolen by a different Pointer Handler or Item." But in this case the handler gives up its grab voluntarily, it's not being stolen by anything else. Probably we were emitting canceled because it's intuitive that the gesture is being canceled because something weird happened. But that's not the documented reason for emitting this signal, and it's perhaps inconsistent with the fact that dragging can be resumed. The mechanism for emitting when another handler or item takes over the grab begins in QPointingDevicePrivate::setExclusiveGrabber(), which emits grabChanged(), which is connected to QQuickDeliveryAgentPrivate::onGrabChanged(), which will call onGrabChanged() on the handler, and the base class implementation QQuickPointerHandler::onGrabChanged() will emit canceled(). At least in this case a handler does not need to decide on its own to emit. [ChangeLog][QtQuick][Event Handlers] A Pointer Handler no longer emits the canceled() signal when it deactivates due to violating conditions (such as pressing the right button when acceptedButtons == LeftButton). Fixes: QTBUG-102201 Pick-to: 6.5 Change-Id: Ibe67c8f2a5e44d96df3a788ca1ee4e43f7de658d Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* Uncomment velocity check in tst_DragHandler::mouseDragShawn Rutledge2022-12-111-2/+2
| | | | | | | | | | This should've been ok after qtbase 1fdbbb49d9f2d2bb62e151a29e5615031af6606a Pick-to: 6.2 6.4 Task-number: QTBUG-33891 Change-Id: I96cba3bc2fb8c0dd3e1411d56f81ccfcd1e0947f Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Standardize Drag/PinchHandler active/persistent scale, rotation, translationShawn Rutledge2022-12-101-7/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | PinchHandler.scale is persistent between gestures, whereas rotation and translation were active-gesture properties; that wasn't consistent. We fixed up DragHandler in just this way in 6.2. The translationChanged() signal now comes with a vector delta, which is often useful when writing an onTranslationChanged JS handler. Likewise, scaleChanged() and rotationChanged() come with qreal deltas. The scaleChanged() delta is multiplicative rather than additive, because an additive delta would not be useful in cases when some target item's scale can be adjusted by alternative means: you need to multiply it in your onScaleChanged function. Now that PinchHandler has 4 axes as grouped properties, some properties in the handlers themselves begin to look redundant; but at least the translation properties are useful to group x and y together. So in this patch we continue to follow the pattern that was set in 60d11e1f69470d588666b76092cd40ae5644a855. PinchHandler.scale is equivalent to persistentScale, whereas rotation is equivalent to activeRotation; so we have a reason to deprecate those properties, as in ea63ee523377bd11b957a9e74185792edd9b32e8. The persistent values have setters, to provide another way for applications to compensate when the values are adjusted by other means, as an alternative to incremental changes via a script such as rotationAxis.onValueDelta, onRotationChanged etc. [ChangeLog][QtQuick][Event Handlers] PinchHandler.activeTranslation now holds the amount of movement since the pinch gesture began. PinchHandler.persistentTranslation holds the accumulated sum of movement that has occurred during subsequent pinch gestures, and can be set to arbitrary values between gestures. Likewise, activeScale, persistentScale, activeRotation and persistentRotation follow the same pattern. The scaleChanged, rotationChanged, and translationChanged signals include delta arguments, which are useful for incrementally adjusting a non-default item property when the target is null. Fixes: QTBUG-76739 Task-number: QTBUG-94168 Change-Id: I6aaa1aa3356b85e6d27abc64bfa67781ecb4f062 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* Add PinchHandler.scaleAxis, rotationAxis; hold values in axesShawn Rutledge2022-12-101-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pointer Handlers that manipulate target item properties should now use QQuickDragAxis consistently to: - enforce minimum and maximum values - hold the persistent and active values - make those available via properties - emit a new activeValueChanged(delta) signal when the value changes, so that it's possible to incrementally update a target item property in JS (onValueDelta: target.property += delta) In the pinchHandler.qml example, you can use the PinchHandler to adjust 4 properties of one Rectangle independently (it requires coordination). m_boundedActiveValue controls whether m_activeValue will be kept between minimum and maximum. For rotation, tst_QQuickPinchHandler::scaleNativeGesture() expects it to be, although that seems questionable now, and may be addressed later. [ChangeLog][QtQuick][Event Handlers] PinchHandler now has scaleAxis and rotationAxis grouped properties, alongside the existing xAxis and yAxis; and all of these now have activeValue and persistentValue properties. The activeValueChanged signal includes a delta value, giving the incremental change since the previous activeValue. The persistentValue is settable, in case some target item property can be adjusted in multiple ways: the handler's stored value can then be synced up with the item property value after each external change. These features are also added to DragHandler's xAxis and yAxis properties. Task-number: QTBUG-68108 Task-number: QTBUG-76380 Task-number: QTBUG-76379 Task-number: QTBUG-94168 Change-Id: I78a5b43e9ba580448ef05054b6c4bc71b1834dd6 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* qquickpointerhandler_p.h: Clean up includesFabian Kosmale2022-10-191-0/+2
| | | | | | | | | | | | | | | | | The referenced bug report specifically complained about warnings caused by including qquickpointerhandler_p.h. All of those -Wshorten-64-to-32 warnings come from headers that aren't strictly needed for qquickpointerhandler_p, though. So fix the issue by only including what is actually need, which also slightly improves compile times. This requires adding a few transitive includes in select places. As a drive-by, remove the unneeded QML_DECLARE_TYPE. Fixes: QTBUG-105055 Change-Id: I24d78e7131771a4bbcb402e6838a5a9a11abbbec Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Port from container::count() and length() to size()Marc Mutz2022-10-071-30/+30
| | | | | | | | | | | | | | | | | | | | This is a semantic patch using ClangTidyTransformator as in qtbase/df9d882d41b741fef7c5beeddb0abe9d904443d8: auto QtContainerClass = anyOf( expr(hasType(cxxRecordDecl(isSameOrDerivedFrom(hasAnyName(classes))))).bind(o), expr(hasType(namedDecl(hasAnyName(<classes>)))).bind(o)); makeRule(cxxMemberCallExpr(on(QtContainerClass), callee(cxxMethodDecl(hasAnyName({"count", "length"), parameterCountIs(0))))), changeTo(cat(access(o, cat("size"), "()"))), cat("use 'size()' instead of 'count()/length()'")) a.k.a qt-port-to-std-compatible-api with config Scope: 'Container', with the extended set of container classes recognized. Change-Id: Idb1f75dfe2323bd1d9e8b4d58d54f1b4b80c7ed7 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* tst_qquickdraghandler: guard the usage of deprecated APIsIvan Solovev2022-08-261-0/+39
| | | | | | | | | | | | | | Protect the usage of deprecated APIs by #ifdefery, and also suppress the deprecation warnings for it. Add tests for the replacement APIs. In tst_multipointtoucharea_interop simply replace the deprecated API with the new one. This allows to build the tests without deprecated APIs. Task-number: QTBUG-104858 Change-Id: I017e64ca467455decd6c663240225de69acebec1 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Use SPDX license identifiersLucie Gérard2022-06-111-27/+2
| | | | | | | | | | | | Replace the current license disclaimer in files by a SPDX-License-Identifier. Files that have to be modified by hand are modified. License files are organized under LICENSES directory. Pick-to: 6.4 Task-number: QTBUG-67283 Change-Id: I63563bbeb6f60f89d2c99660400dca7fab78a294 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Consolidate test helpers into private librariesMitch Curtis2021-09-131-5/+6
| | | | | | | | | | | | | | | | | | | | Previously each test would include and build sources from the shared folder. Now we make those sources a library, build it once, then have each test link to it instead. We also take the opportunity to move some helpers that qtquickcontrols2 had added into the quicktestutils library where it makes sense, and for the helpers that don't make sense to be there, move them into quickcontrolstestutils. We add the libraries to src/ so that they are internal modules built as part of Qt, rather than tests. That way we can use them in a standalone test outside of qtdeclarative. Task-number: QTBUG-95621 Pick-to: 6.2 Change-Id: I0a2ab3976fdbff2e4414df7bdc0808f16453b80a Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Add DragHandler.activeTranslation and persistentTranslationShawn Rutledge2021-06-041-12/+70
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If you want to set target: null and then bind translation to some object's x and y properties directly (perhaps an Item, a Qt Quick 3D Model object, etc.), it's a lot less trouble to use a translation property that does not keep changing back to 0,0 every time a gesture begins. In hindsight, the translation property should have been the persistent one (for consistency with the fix for QTBUG-68941, in which we made PinchHandler.scale persistent and added activeScale: b4d31c9ff5f0c5821ea127c663532d9fc2cae43e). But for several years, the translation property has been restarting with each gesture; so now we add a persistentTranslation property. The new activeTranslation property has the same value as the translation property (which is deprecated). Also, the persistentTranslation property is settable, because in some UIs there may be multiple ways to move the same object, and there needs to be a way to sync them up. Also fixed a bug: when minimumPointCount == 2, QQuickMultiPointHandler::wantsPointerEvent() doesn't initialize d->currentPoints until two points are pressed. But often, one point is pressed, and in the next event, the second point is pressed while the first is held Stationary. So QQuickHandlerPoint::reset() needs to set pressPosition and scenePressPosition on both points at the same time, because it is called on each HandlerPoint in d->currentPoints at that time when both points are pressed. So if any point is pressed, act as if they all were freshly pressed. Without this fix, the centroid's scenePressPosition is wrong (based on the average of 0,0 and the second point), therefore a "jump" was occurring when persistentTranslation is used to directly drive a binding (like the tilt in map.qml). [ChangeLog][QtQuick][Event Handlers] DragHandler.activeTranslation now holds the amount of movement since the drag gesture began. DragHandler.persistentTranslation holds the accumulated sum of movement that has occurred during subsequent drag gestures, and can be set to arbitrary values between gestures. Task-number: QTBUG-94168 Change-Id: I1b2f8ea31d0f6ff55ccffe393bc9ba28c1a71d09 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* Don't let PointerHandler steal mouse grab from keepMouseGrab layerShawn Rutledge2021-05-201-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 Pick-to: 5.15 6.1 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>
* Keep DragHandler active while dragging even if other event happensFabian Kosmale2021-05-051-0/+73
| | | | | | | | | | | | | | | | | QQuickPointerHandler::handlePointerEvent() calls setActive(false) when wantsPointerEvent() returns false (except for a NativeGesture event), for the sake of deactivating reliably when it receives an event which it does not handle. Now we need one more exception, because it's not what we want in DragHandler while dragging: If we get a wheel event, that should not interrupt the current drag operation. Thus, we change the logic in wantsPointerEvent to consider even events we wouldn't normally handle while the DragHandler is active. In handlePointerEventImpl, we then simply ignore them. Fixes: QTBUG-91549 Pick-to: 6.1 5.15 Change-Id: I24e8bd890a21b244c9964f4df76986688085fa87 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Fix some "can be marked override" warningsAndreas Buhr2021-02-231-1/+1
| | | | | | Change-Id: I13da0d085901314950c4fa0afb5853e183652e67 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> 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-301-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. 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>
* 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>