aboutsummaryrefslogtreecommitdiffstats
path: root/src/quick/handlers/qquickpointerhandler.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Merge remote-tracking branch 'origin/tqtc/lts-6.2.8' into ↵Tarja Sundqvist2024-02-201-9/+9
|\ | | | | | | | | | | | | | | | | tqtc/lts-6.2-opensource Conflicts solved in a file: dependencies.yaml Change-Id: Ib4083daa41a689b937d2aeb522e93e3aab0be1c4
| * doc: Update QML eventPoint; fix GrabTransition linkShawn Rutledge2023-03-151-9/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Amends outdated stuff from 507efe5a8a2390813fb620a91b0b3b6b383f599d and c248a32fe69dfe1c685105d0c6aeaeb15d7ba29f. "eventPoint" should now always link to docs added in b43a873264d012dc0a0e574ea53335a40af8aa38. Replace the phrase "event point" with a link to the QML eventPoint value type. QPointingDevice is called PointerDevice in QML, so the GrabTransition enum ought to be found in those docs, in theory, for use in the PointerHandler::grabChanged doc. Task-number: QTBUG-102160 Task-number: QTBUG-104761 Change-Id: I5d1a8dedd9d98e6dee3fbca457aa38f42ea7bfb1 Reviewed-by: Andreas Eliasson <andreas.eliasson@qt.io> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> (cherry picked from commit 60ebb044c87c1e5cf8e0b4a7f135aac283203122) Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* | Merge remote-tracking branch 'origin/tqtc/lts-6.2.6' into ↵Tarja Sundqvist2023-03-011-3/+8
|\| | | | | | | | | | | tqtc/lts-6.2-opensource Change-Id: Ie5a87ae61d8ed0429225353ad46e5232d60f4daa
| * doc: Add missing PointerHandler.CanTakeOverFromItems enum valueShawn Rutledge2022-08-161-0/+2
| | | | | | | | | | | | | | | | | | Amends 0a3eec60cab3c453b378ee45ac335e0dc2951f4b Change-Id: Iae9d1b2b68dc48a52adf0438a09af8e53f5527f1 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io> (cherry picked from commit c2d92c241274f9abdcb24637f9838210f191e8ed) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
| * Quick: includemocsMarc Mutz2022-07-211-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Including moc files directly into their classes' TU tends to improve codegen and enables extended compiler warnings, e.g. about unused private functions or fields. Manual conflict resolutions: - dropped all includes into non-existing files Task-number: QTBUG-102948 Change-Id: I695daa12613de3bada67eb69a26a8dce07c4b85e Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> (cherry picked from commit 6a23f186138dff2a7007288a02702bce23d7ca70) Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
| * Consistently set and reset QQuickPointerHandler's currentEventVolker Hilsheimer2022-07-121-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | Set the pointer before we deliver to the handler implementation, and reset to nullptr afterwards. Fixes: QTBUG-104325 Change-Id: I37ddcb7b20760867ebfd3f23449c6a83088926aa Reviewed-by: Mitch Curtis <mitch.curtis@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> (cherry picked from commit 6b871adfa2f75bf039de390d2b379ddea3aa3eae) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* | Revert "Update commercial license headers"Tarja Sundqvist2022-11-241-21/+21
|/ | | | | | | | | | | This reverts commit 74089697cf2a4961fb697100555b17ae2342d734. Revert of commercial license headers is required for the Qt 6.2.x opensource releases, Qt 6.2.5 onwards. Task-number: QTBUG-107760 Change-Id: Id49069cb5e5f261da185fd082dfb71deb259d387 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Update commercial license headersTarja Sundqvist2022-06-041-21/+21
| | | | | | | | | | | | | | | Updated header.COMM to the files in tqtc-qtdeclarative. Examples, tests, or documentation files are not updated. The commercial license header may contain some additional lines so that its line count equals with the earlier license header. Reason for this is that some autotests use hard coded line numbers and a change in the line count causes failures in tests. Task-number: QTQAINFRA-4941 Change-Id: I32f554b0a8cb527f74d46f3c02b0e745d9fc5ddf Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* HoverHandler: allow cursorShape binding before parentItem is setShawn Rutledge2021-12-041-6/+18
| | | | | | | | | | | | | | | | When a HoverHandler is declared in a Window, the handler's bindings are evaluated before QQuickItemPrivate::data_append() is called to add the handler to the window's content item. So we need null pointer checks again (as we have for a lot of calls to parentItem() already). And to ensure that the declared cursorShape actually is shown, we need to check again in componentComplete(). And don't forget to call the parent class implementation whenever overriding any virtual function. Fixes: QTBUG-98717 Change-Id: Id0defac7a238df522e8eee69f71e83a3947560af Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> (cherry picked from commit 3e95a57dc1fb39b059b52e16fcce7b4262f88b61) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Doc: Fix more documentation issuesTopi Reinio2021-06-161-2/+2
| | | | | | | | | | | | | | | * Screen QML type is moved under the main QtQuick import * XmlListModel types are their own documentation project, add a dependency to qtquick.qdocconf. * Remove QDoc comment identifiers from internal, undocumented class. * Fix linking to Qt Creator manual. * Fix linking to QtQuick3D.Model. Change-Id: I3b48165c04ef84288472963e39eafc0868c14c49 Reviewed-by: Paul Wicking <paul.wicking@qt.io> (cherry picked from commit 5a34509af924fb49579c6344856e2236834e2aae) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Check for null pointer in QQuickPointerHandler::approveGrabTransition()Shawn Rutledge2021-06-041-2/+3
| | | | | | | | | | Found by static analysis: https://testresults.qt.io/codechecker/daily_diffs/qtdeclarative/dev/qtdeclarative-dev-20210604-1285b67a11/qquickpointerhandler.cpp_51058486.html#reportHash=9b76a76200c3a2eceb0e115776dda98b Amends b09ce7dcd8ecf24ef23da8197a64e3fced3fc894 Pick-to: 6.1 Change-Id: I4c35f648be9513e5e237d9b8d4e502e40e9f8a76 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Allow pointer handlers to be added to QQuick3DModel objectsShawn Rutledge2021-06-031-3/+12
| | | | | | | | | | | | | | | | | | | | | | Mainly it's a matter of removing the assumption that parent() is always a QQuickItem. But handlers that have a target property do not know how to manipulate it when it's not an item; so for example you can use DragHandler's translation property to manipulate the object, but it doesn't drag a 3D object by default. Delivery logic for now is implemented in QQuick3DViewport, because it's intimately tied to picking, and QQuickDeliveryAgent doesn't really know anything about QQ3D objects, and the conventional delivery to handlers in Qt Quick depends on QQuickItemPrivate::handlePointerEvent() which isn't available in that use case. Hover events are interfering with DragHnadler (wantsPointerEvent() returns false, therefore the handler gets deactivated right away). HoverHandler detects hover but does not detect leave, but that's probably a matter for the delivery logic to fix. Change-Id: Id0ec385ce8df3a003f72a6666d16632cef72bbd6 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* PointerHandler constructor: add to Item parent's list of handlersShawn Rutledge2021-06-011-6/+6
| | | | | | | | | | | | Amends 2d1ec2f84953f93fb661d442cd4207e7f0198e4b to fix the other constructor and delegate to it. QQuickTapHandler(parent) -> QQuickSinglePointHandler(parent) -> QQuickPointerDeviceHandler(QQSinglePtHandlerPriv, parent) -> QQuickPointerHandler(priv, parent) so in the intended use case, this is the constructor that counts. Change-Id: I856b3825609fa7601b50f6a7a69c46563dc9a34f Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* PointerHandler constructor: add to Item parent's list of handlersShawn Rutledge2021-05-261-0/+7
| | | | | | | | | | | | | When a pointer handler is created in C++, a parent Item might be given to the constructor, so QQuickItemPrivate::data_append() might not be called. But to be functional, it needs to be added to ExtraData.pointerHandlers. Task-number: QTBUG-68110 Change-Id: I02f6574f801018b964ecf4167bac65792d9c6094 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>
* Don't let PointerHandler steal mouse grab from keepMouseGrab layerShawn Rutledge2021-05-201-8/+17
| | | | | | | | | | | | | | | 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>
* Enhance approveGrabTransition log messageShawn Rutledge2021-05-141-2/+3
| | | | | | | | Show the existing grabber, not only the proposed grabber. Pick-to: 6.1 Change-Id: Idd1b41f96b063793c3c97aa67aa4425e2d58a027 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Map window coordinates to the same coordinate system as the QPointerEvent pointAlexey Edelev2021-05-111-1/+4
| | | | | | | | | | | If the window has parent windows its geometry should be mapped to the global coordinates before check if it contains the point coordinates. Fixes: QTBUG-91716 Pick-to: 5.15 6.1 Change-Id: I300547361dbe895b67caeee0d47f416426444552 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Use QQDeliveryAgent::sceneTransform, if set, in QQuickItem::mapFromGlobalShawn Rutledge2021-05-051-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | During dragging of a QEventPoint, Flickable computes the drag delta as pos - mapFromGlobal(point.globalPressPosition()) We cannot use only the global position delta, because the Flickable might be transformed in 2D (by setting rotation on it or in a parent, as in tst_qquickflickable::clickAndDragWhenTransformed) or in 3D (by mapping it onto a Model object). So we really need QQuickItem::mapFromGlobal() to actually work regardless how many of these transformations are in place. This is just the beginning: we have a lot of these mapFrom/To functions; but it's enough for the Flickable in the quick3d/dynamictexture example to work better. Without this fix, if you tried to drag a yellow note on the door panel, at the very first drag ListView saw a large delta and considered its drag threshold exceeded immediately, whereas the DragHandler on the note saw a very small delta; so ListView grabbed and DragHandler did not steal it: it relies on having "first dibs". When the drag threshold is exceeded, Flickable merely plans to grab on the next event rather than grabbing immediately, and therefore a child has a chance to grab first. Therefore it's normally OK for DragHandler to simply become the first exclusive grabber when the drag threshold is exceeded, and not steal the grab from another item (although grabPermissions can be changed to allow stealing if necessary). However this means that we continue to enforce the drag threshold in local (transformed) coordinates: if Flickable should wait until the user drags 10 pixels, but it's scaled to half-size, it will start dragging after only 5 pixels of movement, for example. Pick-to: 6.1 Task-number: QTBUG-92944 Change-Id: Id01cc833ca80850ca18a965adf47f435e43e20ed Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Fix build without features.gesturesTasuku Suzuki2021-04-161-0/+2
| | | | | | Change-Id: I9c5cb83ad45b7af7060fee2fed593da7efae7158 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* PinchHandler: scale incrementally when new pinch gesture beginsShawn Rutledge2021-03-251-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | When the gesture begins, we begin multiplying the target item's scale by 1.0 at first; it doesn't make sense to start immediately with the accumulated scale remembered from previous pinch gestures, because the target item remembers its own scale. When QQuickPinchHandler::wantsPointerEvent() returns false because some irrelevant gesture was received (for example a PanNativeGesture), that's not a good reason to deactivate. Deactivating and re-activating with each ZoomNativeGesture event results in extreme behavior, because PinchHandler depends on the BeginNativeGesture and EndNativeGesture events to reset internal state. Likewise, the fact that the button state is NoButton is not a good reason for wantsPointerEvent() to return false. Added an autotest: the first of its kind that actually simulates the native gesture events. Fixes: QTBUG-92064 Pick-to: 5.15 6.0 6.1 Change-Id: I3a9b92d70f99497ee58ad8557d90d521fbe16d41 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* Remove QQWindowPriv::is[Mouse|Touch|Tablet]EventShawn Rutledge2021-03-191-2/+2
| | | | | | | They are moved to QQuickDeliveryAgentPrivate. Change-Id: I5d6656dd6362dd03f0f4321cff07a8b207fadd39 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* Move event delivery from QQWindow to QQuickDeliveryAgentShawn Rutledge2021-02-241-9/+6
| | | | | | | | | | | | | | | | | | | | QQuickWindow owns QQuickRootItem which owns QQuickDeliveryAgent, so for every window there's an object responsible for event delivery, while the window itself is mainly responsible for rendering (separation of concerns). However, QQuickRootItem and QQuickDeliveryAgent can now be used in cases where the scene doesn't directly belong to a window, such as when a Qt Quick sub-scene is mapped somewhere into a Qt Quick 3D scene. In that case, we must remember which delivery agent was in use at the time when a QEventPoint is grabbed and deliver subsequent updates via the same DA. There's also a QQuickDeliveryAgent::Transform abstraction which subscene-management code (such as QQuick3DViewport) can implement, to provide a formula to map the window's scene coordinates to subscene coordinates; if defined, it will be used during delivery of subsequent updates to existing grabbers. Task-number: QTBUG-84870 Change-Id: I70b433f7ebb05d2e60214ff3192e05da0aa84a42 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Doc: Fix documentation warnings for Qt QuickTopi Reinio2020-11-051-2/+2
| | | | | | | | | | | - Remove links to modules and examples that are not part of Qt 6. - Remove links to entities marked as \internal - Add missing enum value and QML property docs where it's trivial to do so. Task-number: QTBUG-88156 Change-Id: I10a1c7bcc5fe0e2354ea69eaf24930362edb7415 Reviewed-by: Paul Wicking <paul.wicking@qt.io>
* QQuickPointerHandler: Don't leak the QtQuick-specific extra dataUlf Hermann2020-10-311-0/+1
| | | | | | Change-Id: I0c5697e9df4dc01aeedf427aab723c306e19338d 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-58/+92
| | | | | | | | | | | | | | | | | | | | | | | 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>
* Add ; to Q_UNUSED and UNUSED_PARAMLars Schmertmann2020-06-261-1/+1
| | | | | | | | | This is required to remove the ; from the macro with Qt 6. Task-number: QTBUG-82978 Change-Id: Iead53d18fd790fb2d870d80ef2db79666f0d2392 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Remove QQuickPointerDevice in favor of QPointingDeviceShawn Rutledge2020-06-231-1/+12
| | | | | | | | | | | | | | ...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/+83
| | | | | | | | | | | | | | | | | | 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>
* Fix Qt6 build in preparation of qt5 submodule updateAlexandru Croitor2019-12-191-2/+2
| | | | | | | | | Fixes the QTextStream usages. Change-Id: I0c009a82fb644a9f3c3d42ec410d18b680977f23 (cherry picked from commit 1c5c5f7aadc2dcc73a21eeb818e95c4e1b7de70f) Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Merge remote-tracking branch 'origin/5.14' into 5.15Qt Forward Merge Bot2019-12-091-1/+18
|\ | | | | | | | | | | | | Conflicts: src/qml/common/qv4compileddata_p.h Change-Id: I1150c8cd0161f0e22137d383013751394ae64e18
| * Don't let PointerHandler steal touch grab from preventStealing MouseAreaShawn Rutledge2019-12-061-1/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The scenario: - mouse press: MouseArea grabs; DragHandler gets a passive grab - drag a little: DragHandler's drag threshold is exceeded - drag some more: DragHandler tries to take the exclusive grab This grab takeover succeeded before, because although MA has keepMouseGrab(), the event being delivered is a touch event, and MA does not have keepTouchGrab(). If this happens while QQuickWindowPrivate::touchMouseId is the same touchpoint that the DragHandler is trying to grab, it should not succeed, because we honor the keepMouseGrab() flag. I.e. keepMouseGrab() implies keepTouchGrab() whenever the touchpoint under consideration is currently the touch-mouse. On the other hand, if a DragHandler is used on some item inside a Flickable: on press, the Flickable grabs right away (it has a bad case of FOMO), but the DragHandler just gets a passive grab. When the drag threshold is exceeded, DragHandler must be able to steal the grab from Flickable, because Flickable was just being too aggressive. So now we have the rule that if the Item it wants to steal the grab from is a parent of the type that filters all events, it's OK to ignore the keepMouseGrab() flag and steal anyway (as it did before this patch). Fixes: QTBUG-79163 Change-Id: I2b3f175bea867cb737357857657653b0a7b83995 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* | Add dragThreshold property to Event HandlersShawn Rutledge2019-09-191-0/+69
|/ | | | | | | | | | | | | | | | | 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>
* Doc: fix grabPermissions and other enumeration propertiesShawn Rutledge2018-09-141-2/+21
| | | | | | | | | | | | * grabPermissions is a flags property, not bool. * Add a list of the possible grabPermissions values. * Fix two other places where \qmlproperty enum was used instead of enumeration. * acceptedButtons, acceptedDevices, acceptedModifiers and acceptedPointerTypes are flags properties, not plain int. Change-Id: I6f49dcc1e1762e913e4989b208380d64899630a6 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* Rename QQEventPoint::GrabState to GrabTransitionShawn Rutledge2018-08-311-7/+7
| | | | | | | | | | | | | | | | | | | 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>
* MultiPointHandler::wantsPointerEvent: reset if different cand countShawn Rutledge2018-08-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We always intended to "start over" with event delivery when the number of touchpoints changes. Change 48011c2dfeb83b4fe717034d4b3c353714fead48 began this process, but in addition to QQuickWindow delivering the event to all items and their handlers in reverse paint order, ignoring existing grabs, the handlers themselves have responsibility to act as if it was an initial press whenever the number of relevant touchpoints changes; and because QQuickWindow starts over, handlers do not need to rely on passive grabs to retain interest in one point at the time when a transition to a different number of points occurs. For example, DragHandler by default handles just one point, so if you press one point such that it takes a passive grab and adds that point to m_currentPoints, then you press a second finger within the bounds of the same parentItem, the DragHandler should not go on "wanting" the first point anymore, because a two-finger gesture is different, and not suitable for the DragHandler unless its maximumPointCount >= 2. Even if the second point is released, QQuickWindow will "start over" with delivery, so a multi-point handler does not need to rely on retaining a passive grab to handle the transition from two points back to one again. This also helps enable smoother transitions between different gestures: e.g. in the map.qml manual test, you can drag one finger and transition from dragging to pinching and back while the second finger is pressed, dragged and released. Change-Id: Id9b8f30029ed1ff9fd2d64a5e413a47055622083 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* Fix PointerHandler constructors and destructorsShawn Rutledge2018-07-271-6/+2
| | | | | | | | | | | | | - Constructors should take QQuickItem* not QObject* to be symmetric with the parentItem() accessor (and other code) which assumes its type - Use header initialization everywhere possible - Reorder variables to minimize padding (somewhat) - Remove empty destructor bodies (the compiler can write them) - Remove override and virtual from destructors in accordance with https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rh-override Change-Id: I682a53a803d65e29136bfaec3a5b534e975ecf30 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* Rearrange docs: Pointer Handlers -> Input HandlersShawn Rutledge2018-07-261-2/+1
| | | | | | | | | | | | | | | At QtCS 2018 we decided to rename Pointer Handlers to Input Handlers and include the Keys attached property as part of this set (since we plan to have attached-property pointer handlers too, eventually). It's no longer a module, it's included in Qt Quick 2.12. We need to start promoting Input Handlers and reducing the visibility of legacy stuff like MouseArea and MultiPointTouchArea (in the hope of being able to deprecate them eventually). Task-number: QTBUG-66651 Change-Id: I801351ac2531191cbb1faac9318441c67a109af6 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io> Reviewed-by: Venugopal Shivashankar <Venugopal.Shivashankar@qt.io>
* Finish renaming pointDistanceThreshold to margin (including doc image)Shawn Rutledge2018-07-241-1/+1
| | | | | | | | | Followup to da722fb448f06cf43780e6f857a1ccd9f07176d6 Task-number: QTBUG-68077 Change-Id: I93322949018091e453297164ef1838619d19ee57 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io> Reviewed-by: Martin Smith <martin.smith@qt.io>
* Rename Pointer Handlers to Input Handlers (as a concept)Shawn Rutledge2018-07-121-8/+8
| | | | | | | | | | | | | | | | This is a documentation change to alleviate some confusion that we've seen during the Tech Preview period. It doesn't make sense to actually rename the base class though, because it is intended to handle QQuickPointerEvents, not QEvents. The reason for that is that refactoring the QEvent hierarchy has to wait until Qt 6. So maybe in Qt 6 we can remove QQuickPointerEvent and have a QQuickInputHandler base class which handles QInputEvents; but for now, this conceptual renaming seems about as far as we can go. Task-number: QTBUG-66651 Change-Id: I84a41dc282c480d08f4d4a0d9a857e37e074aa7a Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
* Add cat. logging in wantsEventPoint; improve FlickableInterop testShawn Rutledge2018-06-291-1/+4
| | | | | | | It was too hard to debug behavior in this test. Change-Id: Iaec9534cca17bdd90b94cfa8fa8b21b7026839ae Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Replace MultiPtHndlr.pointDistanceThreshold with PointerHandler.marginShawn Rutledge2018-06-291-1/+38
| | | | | | | | | | | | | | | | It's not just useful for PinchHandler: TapHandler has a good use for it too. But unfortunately if the handler's parent Item has a custom mask, we don't have a way to augment the mask with a margin; so if margin is set, we assume the bounds are rectangular. QQuickMultiPointHandler::eligiblePoints() now calls wantsEventPoint() rather than bounds-checking the point directly: this adds flexibility, potentially allowing an override in subclasses, if we need it later. Task-number: QTBUG-68077 Change-Id: I65c95f00c532044a5862654e58c9c5f8c973df81 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Add HoverHandler to detect a hovering mouse pointerShawn Rutledge2018-06-281-3/+9
| | | | | | | | | | Detect whether the handler's parent contains the mouse, while the point property tracks the event point (position etc.) Task-number: QTBUG-68072 Change-Id: Ica99332596eab3e344852a11f1ceb7aaf6348c86 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* PointerHandler.grabChanged signal: add stateChange parameterShawn Rutledge2018-06-271-5/+7
| | | | | | | | | 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>
* Move wantsEventPoint() up from SinglePointHandler to QQPointerHandlerShawn Rutledge2018-06-201-0/+5
| | | | | | | | We want to be able to call it from the upcoming QQuickItemPrivate::anyPointerHandlerWants function. Change-Id: I15ef60303fa56f43e66b16c8dd0f4102070536d0 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Fix non-initialized class memberJesus Fernandez2018-06-201-4/+4
| | | | | | | | >>> Non-static class member "reserved" is not initialized in this constructor nor in any functions that it calls. Coverity-Id: 190209 Change-Id: Ia1c07ff16b2015d99ab15f387ac6cc687703fcbb Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Refactor QQuickPointerHandler: add private implementation classShawn Rutledge2018-05-151-38/+88
| | | | | | | Follow the usual pattern in preparation for making this class public. Change-Id: I8330cdda27e131a5f93723d4cf4c53a9f7630434 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* QQuickPointerHandler: make classBegin and componentComplete protectedShawn Rutledge2018-03-271-1/+9
| | | | | | | | | They are public in QQmlParserStatus but don't need to be public here. Also de-inline the default implementations, because this class will be public C++ API eventually. Change-Id: Ic7dfbec853e3d20f45b361401f710dedb5eae416 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* doc: Correct mostly linking errorsMartin Smith2018-02-231-3/+3
| | | | | | | | | This update corrects many qdoc warnings, mostly of the "Can't link to..." variety, but there were also a few qdoc comments added. As of this update, the qdoc warning count is 46 in QtDeclarative. Change-Id: Icf2d34c7ce7010ebfd9b474feacfe8af42f3fd5f Reviewed-by: Martin Smith <martin.smith@qt.io>
* QQuickPointerHandler: add virtual onTargetChanged()Shawn Rutledge2018-01-121-0/+2
| | | | | | | | To be overridden in handlers which need to know when this happens, to avoid connecting to the targetChanged() signal. Change-Id: I51432b69d05fd541eb62e0cd01f4019e336816ac Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* PointerHandler: add grabPermissions, enforce in setExclusiveGrabShawn Rutledge2017-11-141-9/+121
| | | | | | | | | | | | | | | | | | | | | | | | | | | | As soon as we enable the concept that PointerHandlers can use passive grabs to lurk, monitor all movements, and then steal the passive grab, they can fight over the grab. For example if there are two items with PinchHandlers, and two or more touches occur within bounds for both, then each update event can cause the other PinchHandler to steal the grabs and become active. So we replace stealing with negotiation: the handler which wants to take over the grab checks its own flags to see whether that's allowed, and the handler which is about to lose its grab also has the right to approve or deny the takeover (just as QQuickItem has had keepMouseGrab and keepTouchGrab for a long time.) Additionally, if one handler wants to cancel another handler's grab without taking over (simply set the grabber to null), it must be approved. A single-point handler can simply call setExclusiveGrab, with the expectation that permission may be granted or denied. A multi-point handler only wants to grab all points if grabbing all of them will be allowed, otherwise grab none; so it calls canGrab on each point to check beforehand. Thus, when two handlers are competing for the same grabs, one or both can be prevented from stealing from each other, or from Handlers in general, or from Items, or some combination. Change-Id: I5c733b2b8995ce686da0be42244394eeee82a268 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2025-12-23 19:32:03 +0000