aboutsummaryrefslogtreecommitdiffstats
path: root/src/quick/handlers/qquicktaphandler.cpp
Commit message (Collapse)AuthorAgeFilesLines
* doc: Fix mention of DragHandler in TapHandler docsShawn Rutledge2025-10-241-1/+1
| | | | | | | | Amends 6eaa95662c2d4ba287ac5d1de5ec49bd3a9f59e6 Pick-to: 6.5 6.8 6.10 Change-Id: I195e26fa1a703607b1d65d57e5dc43a072b05e72 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* Set explicit default security level of all files with default securityJan Arve Sæther2025-09-171-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | The files (folders) already processed are listed in each issue in epic QTBUG-134547 These files were processed half a year ago. In order to make it clear that all of these files are already processed, mark them with an explicit default security header. For the record, this was generated with this script: find -E . -regex ".*\.(cpp|h|hpp|mm|qml|js)$" | xargs python3 ~/bin/add-cra-header.py in the folders listed in each subtask of QTBUG-134547 (add-cra-header.py only exist at my desktop, but it simply adds the default security header if it doesn't already have any existing security header) QUIP: 23 Fixes: QTBUG-134547 Pick-to: 6.10 6.9 6.8 Change-Id: Ieb8c78ea6561fdbdd27c7b13185ece853eedf80f Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io>
* Ensure TapHandler.pressed==false when deactivated; tolerate null eventShawn Rutledge2025-03-061-3/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Dating back at least to 507efe5a8a2390813fb620a91b0b3b6b383f599d the initial plan was that an ungrab calls setActive(false), and that ought to be enough, because every pointer handler can react to deactivation in its own way. But QQuickTapHandler did not override onActiveChanged(); and it would still not work very well to do that, because setPressed() takes various arguments that are not available in onActiveChanged(). So an odd state of dubious utility was possible: it could be inactive and pressed at the same time. That's now prevented, as long as TapHandler relies on an exclusive grab. If a TapHandler's window is deactivated while it has an exclusive grab, onGrabChanged() is called with a null event, because the deactivation event is not a pointer event. Don't crash, and don't get stuck in pressed state either. Currently in this scenario, the grab transition is UngrabExclusive, not CancelGrabExclusive. If we are sure that a TapHandler should no longer be pressed if its window is no longer active, and one symptom is that it's ungrabbed, probably it makes sense to be consistent that when it loses any kind of grab that it has taken, it should no longer be pressed. But then we would run into the issue with the null event as described above. So these changes are best done together. If a TapHandler's window is deactivated while it has a passive grab, the TapHandler cannot be deactivated or un-pressed, because it is not in active state in the first place. (As documented, `active` means it has an exclusive grab.) Fixes: QTBUG-118454 Fixes: QTBUG-124777 Change-Id: I855a0e0ddcb13866af5501f6164b6b18b41dda2a Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* Doc: Replace \instantiates with \nativetypePaul Wicking2024-08-201-1/+1
| | | | | | | | | | | Since the implementation of the `\nativetype`-command in QDoc, the `\instantiates`-command is deprecated. Replace the use of the deprecated command in favor of its replacement. Pick-to: 6.8 Task-number: QTBUG-128216 Change-Id: I23d9f66d3f6db2e5f827d7868497a432bb9b0626 Reviewed-by: Venugopal Shivashankar <Venugopal.Shivashankar@qt.io>
* Make more logging categories staticUlf Hermann2024-06-241-1/+1
| | | | | | | Non-static, non-forward-declared logging categories are deprecated. Change-Id: Iaeb0183ef7ca05bbd0f4587166096c29825cc175 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* QQuickMenu: cancel all grabs before QPlatformMenu::showPopup()Shawn Rutledge2024-06-211-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | If a TapHandler is used to open a menu: TapHandler { acceptedButtons: Qt.RightButton onPressedChanged: if (pressed) backgroundContextMenu.popup() } and popup() blocks and then eats the mouse release (as QCocoaMenu::showPopup() does), it means QQuickTapHandler::setPressed() is not allowed to finish executing before being blocked, and it has no chance to get the mouse release afterwards either (that release may have been the one that selected a menu item, which presumably is why macOS eats it). But it behaves well enough if we cancel the grab, and thereby cause QQuickTapHandler::onGrabChanged() to be called with CancelGrabExclusive or CancelGrabPassive. setPressed(false) will be called before setPressed(true) has finished: that works OK in practice, because it doesn't do much else after the `emit pressedChanged()` line. But when QQuickTapHandler::onGrabChanged() calls setPressed(false) after the grab is already canceled, the event is not passed along; so check for null before calling setExclusiveGrab(event, point, false). TapHandler has just been informed that the grab was canceled, so it doesn't need to ungrab again. Pick-to: 6.8 Fixes: QTBUG-126539 Change-Id: I657a6e9b4581df4dd284d6f488e4101c2a2faf4c Reviewed-by: Mitch Curtis <mitch.curtis@qt.io> Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* TapHandler: don't (dis)connect signals to a null windowShawn Rutledge2024-04-251-5/+17
| | | | | | | | | | This is unexpected, but we're told that it happens somehow. Pick-to: 6.5 6.6 6.7 Fixes: QTBUG-108696 Change-Id: I738099f43003056f7a24c09b1dc36024a81cbbb1 Reviewed-by: Vladimir Belyavsky <belyavskyv@gmail.com> Reviewed-by: Santhosh Kumar <santhosh.kumar.selvaraj@qt.io>
* Disable TapHandler.longPressed signal if longPressThreshold == 0Shawn Rutledge2023-11-171-8/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | There needs to be a way to disable the long-press feature, because it's exclusive: if we emit longPressed(), we do not emit tapped(). But we should also be able to accommodate slow users who pause for too long unintentionally, or while simply observing the behavior. Also clarify that resetting longPressThreshold reverts to the default. Add more exhaustive test coverage, verify that longPressed and tapped are mutually exclusive, and verify the effects of violating the gesturePolicy. Change longPressThreshold on LauncherList's back button so that it always triggers, regardless whether the user pauses on it for a while. [ChangeLog][QtQuick][Event Handlers] TapHandler.longPressThreshold can now be set to 0 to disable its press-and-hold feature, and can be reset to undefined to restore the platform default. Fixes: QTBUG-119132 Task-number: QTBUG-105810 Pick-to: 6.5 6.6 Change-Id: Id5fd7e51c70fdb0cb6c4beb5615717a222aec871 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* Make TapHandler longPressed/tapped exclusive and reliable; fix exampleShawn Rutledge2023-11-171-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The back button in the examples' LauncherList.qml has been flaky. As described in the docs, a TapHandler used to implement a Button should have `gesturePolicy: TapHandler.ReleaseWithinBounds` to get the common behavior that you can drag out of the button to cancel the click, and you can also drag back into the button to change your mind and let it click after all. But when trying to test this behavior, another problem became evident: if you spend a longer time than longPressThreshold for the whole gesture, then at the time of release you could see the debug output "long press threshold exceeded" and the tapped signal was not emitted. Our intention was that if you are dragging around, the TapHandler is not eligible to emit the longPressed signal; it follows that it should not become ineligible to emit tapped, either (tapped can be emitted if other constraints are satisfied). The intention of the ReleaseWithinBounds policy is that it doesn't matter how much you drag, as long as the point is within the bounds of the parent at the time of release. So we begin keeping track of whether we have actually emitted the longPressed signal, rather than merely looking at the time difference. This changed behavior in tst_qquickdeliveryagent::passiveGrabberOrder: 1 second is more than enough time for long press with the default longPressThreshold, and now the tapped signals are no longer emitted after longPressed. So we just wait for pressed state rather than waiting so long. qWaits in tests are best avoided anyway (although I think the intention in 152e12dc22cc0fd07cf90bcd35ae0e05b8b46fa0 might have been to wait long enough to ensure that nothing undesired would occur, rather than waiting for something specific to occur). Task-number: QTBUG-65012 Task-number: QTBUG-105810 Pick-to: 6.5 6.6 Change-Id: If6a86d955e19810cb06de659f5e39b50a72fa762 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* doc: Rename to Qt Quick Examples - Pointer HandlersShawn Rutledge2023-07-021-2/+2
| | | | | | | | This seems to be still a consistent naming convention for example docs. Pick-to: 6.6 Change-Id: I508526ec992222da1c971bc327dd9c83a21640aa Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io>
* Fix TapHandler signals in combination with exclusiveSignalsShawn Rutledge2023-04-111-18/+27
| | | | | | | | | | | | | TapHandler does not emit any singleTapped or doubleTapped signals after emitting it once, if exclusiveSignals is set to `SingleTap | DoubleTap`. This change corrects the behavior by resetting m_tapCount properly. Fixes: QTBUG-111800 Pick-to: 6.5 Change-Id: Ice7af2f41c2f30448004033d8330e733abe44110 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* Don't emit doubleTapped when the buttons are differentMatthias Rauter2023-03-091-4/+8
| | | | | | | | | | | | A left-click followed by right-click was interpreted as a double-click. This is different from what I am used to and different from what I expect. This patch changes the behavior such that only clicks of the same button are interpreted as double click. Pick-to: 6.2 6.4 6.5 6.5.0 Fixes: QTBUG-111557 Change-Id: Id0d83ca66944497710d8f659ed5a6d1e4260a2d9 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Document the Pointer Handlers exampleShawn Rutledge2023-03-021-1/+3
| | | | | | | | | | | Animated gifs were captured with byzanz-record, then converted to webp: gif2webp -lossy -min_size -q 40 -m 6 -mt -metadata none in.gif -o out.webp Pick-to: 6.2 6.4 6.5 Fixes: QTBUG-96915 Change-Id: Iee2f4ef774de7862d93c7e4cdf7b2b5e0553bec4 Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io> Reviewed-by: Doris Verria <doris.verria@qt.io>
* doc: Add snippets and animations illustrating TapHandler.GesturePolicyShawn Rutledge2023-03-021-43/+88
| | | | | | | | | | | | | | | | | | | | | | People are constantly confused by GesturePolicy and its default value, so we really need a "glanceable" reference in the docs to show the differences between use cases. Also clarify the pitfalls with the default DragThreshold value. We switch from the \value tag to a 2-column \table because the \image would otherwise break the table, and also because it saves space and acts as a meaningful reminder to have the animation right under the enum value that is being documented. Pick-to: 6.5 6.4 6.2 Task-number: QTBUG-70397 Task-number: QTBUG-73262 Task-number: QTBUG-100534 Task-number: QTBUG-107239 Task-number: QTBUG-111310 Change-Id: I1ff45f58a8a8edf55f4a8696d881aa9e0bedcfe3 Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io>
* doc: Update QML eventPoint; fix GrabTransition linkShawn Rutledge2023-02-211-6/+6
| | | | | | | | | | | | | | | | | | | | 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. Pick-to: 6.2 6.4 6.5 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>
* TapHandler: ignore untracked moving points; treat touchpad as mouseShawn Rutledge2023-02-211-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | TapHandler must decide on press whether it's interested in tracking a particular point further, to see if a qualifying tap occurs, and should only care about those points it decided to track. But if it did not decide to track it, wantsEventPoint() should never care about the point movement after press; nor about hovering points either. The line in QQuickPointerDeviceHandler::wantsPointerEvent() checking pointingDevice()->pointerType() != Finger was also making touchpad behavior inconsistent with mouse behavior, which is why this bug appeared on macOS but not on Linux: QQuickPointerDeviceHandler needs to care about the incoming event's buttons on all devices except touchscreens. It's probably been causing other symptoms on touchpads since a97760a336c597327cb82eebc9f45c793aec32c9. For the test, a05cbaaae505dba2546c593e22fe2f9047c0de4b restored the cumulative native gesture scaling as it should be: so if we try to scale by 1.1 twice in a row, the result is it's scaled by 1.21. Pick-to: 6.2 6.4 6.5 Fixes: QTBUG-108896 Change-Id: I3da8878648b89cce5d1a48fa02dffaefead2ac90 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Doris Verria <doris.verria@qt.io>
* Add FOREIGN declaration for QEventPointSami Shalayel2022-11-111-3/+3
| | | | | | | | | | | | Add a foreign declaration to QEventPoint such that qml compilers can work correctly with it. Also fix the links to eventPointer in the documentation, and duplicate the list of properties of the C++ api. Fixes: QTBUG-107624 Change-Id: I11c4a4a416a40d40fc7ce45d7f894406035a6d87 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* TapHandler: don't cancel on releaseShawn Rutledge2022-10-231-13/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The previous fix for QTBUG-94012 was in conflict with the idea that TapHandler could be used to augment behavior on other event-handling Items: it would emit canceled rather than tapped whenever there was a rival exclusive grabber, unless that grabber was an event-filtering item. The bug I was trying to fix was in the Qt Quick 3D dynamictexture example: if you click on a TextEdit in a subscene to set the cursor position, a TapHandler on the entire View3D should not react, because something in the subscene was already reacting. The event accepted flag also does not stop propagation in other subscenes. This bug should rather be fixed by changing gesturePolicy so that the outer TapHandler does try to take the exclusive grab, and then it is stolen by TextEdit because TapHandler's default grabPermissions include ApprovesTakeOverByAnything. Handlers in general are useful to augment existing behavior of Items. At least gesturePolicy and grabPermisions are available to fine-tune the stealing of the exclusive grab; but when TapHandler is using a stealthy passive grab (which it does with the default gesturePolicy), we don't want to prevent it from reacting. This reverts the TapHandler changes from commit d342b8f77658537c4fd3318982d2ae7a964b6426 but keeps the autotest, which is now improved by checking multiple gesturePolicy values and checking for the canceled signal if the policy specifies an exclusive grab. Also call QEventPoint::setAccepted(false) if the gesturePolicy is DragThreshold, because if the TapHandler is getting by with a passive grab, it should not interfere with delivery to other items. This makes touch behavior more consistent with mouse behavior. Pick-to: 6.4 Fixes: QTBUG-99887 Fixes: QTBUG-105609 Task-number: QTBUG-94012 Change-Id: Ib8f80d4e6523b01ef204a69f1f30f010bee6eb8f 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>
* Add TapHandler.exclusiveSignals to enable single/double tap exclusivityShawn Rutledge2022-10-191-6/+59
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If exclusiveSignals == NotExclusive (the default), behavior remains as it was: singleTapped() and doubleTapped() are emitted as the taps occur, so it's not very useful to react on singleTapped() if you mean to distinguish these two cases. If exclusiveSignals == SingleTap, the doubleTapped signal will not be emitted at all, and therefore singleTapped can be emitted immediately and unambiguously. If exclusiveSignals == DoubleTap, the singleTapped signal will not be emitted at all, and therefore doubleTapped can be emitted immediately and unambiguously. If exclusiveSignals == SingleTap | DoubleTap, we must wait qApp->styleHints()->mouseDoubleClickInterval() milliseconds after a tap is detected before emitting either signal, so that they are distinct and can be used to drive behavior that should not occur in other cases. A triple-tap will not trigger either signal. [ChangeLog][QtQuick][Event Handlers] TapHandler.exclusiveSignals now lets you make the singleTapped and doubleTapped signals exclusive. Task-number: QTBUG-65088 Fixes: QTBUG-107264 Change-Id: Ifb2c4b72759246c64b3bfa2f776c28266806b985 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io>
* Use SPDX license identifiersLucie Gérard2022-06-111-38/+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>
* Quick: includemocsMarc Mutz2022-04-291-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. Pick-to: 6.3 6.2 5.15 Task-number: QTBUG-102948 Change-Id: I695daa12613de3bada67eb69a26a8dce07c4b85e Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Doc: Fix documentation warningsTopi Reinio2021-12-061-9/+9
| | | | | | | | Fix warnings related to the introduction of the TreeView QML type, as well as other minor issues. Change-Id: Icdcb61b4de0144ca426b1ab5a17ddc0ddc523773 Reviewed-by: Venugopal Shivashankar <Venugopal.Shivashankar@qt.io>
* Add TapHandler.gesturePolicy: DragWithinBounds enum value; examplesShawn Rutledge2021-12-021-1/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On a touchscreen, right-clicking is not directly possible; so sometimes a long-press gesture is used as a substitute. The next thing a UI designer would want would then be a way of showing feedback that a long-press is in progress, rather than simply waiting for the long-press to occur and then surprising the user with some instant action. For example, a menu might begin to open as the user holds down the touchpoint; but before the long-press gesture is complete, the user can simply release, to cancel the gesture and close the menu. The timeHeld property could drive the animation, to avoid needing a separate animation type; in fact the reason timeHeld exists is to make it easy to emulate this sort of touch-press animation, like one that occurs on touchscreens since Windows 7. But after the menu is open, the user would probably expect to be able to drag the finger to a menu item and release, to select the menu item. For such a purpose, the existing gesture policies weren't very useful: each of them resets the timeHeld property if the user drags beyond the drag threshold; so if the user expects to drag and release over a menu item, then the timeHeld property cannot drive the menu-opening animation, because the menu would disappear as soon as the user drags a little. So it makes more sense to have a gesturePolicy that acts like WithinBounds, but also applies the same policy to the timeHeld property and the longPressed signal. We don't care about the drag threshold: if the user is holding down a finger, it's considered to be a long-press-in-progress, regardless of how far it has moved since press (as long as it stays within the parent's bounds). An example of such a menu is added. The menu must have TapHandler as its root object, because it reacts to press-and-drag within some larger item, larger than the menu itself. For example such a menu could be used in a canvas-like application (drawing, diagramming, dragging things like photos or file icons, or something like that): dragging items on the canvas is possible, but long-pressing anywhere will open a context menu. But in this example so far, only the menu is implemented. It's a pie menu, because those are particularly touch-friendly; but perhaps for the mouse, a conventional context menu would be used. [ChangeLog][QtQuick][Event Handlers] TapHandler now has one more gesturePolicy value: DragWithinBounds; it is similar to WithinBounds, except that timeHeld is not reset during dragging, and the longPressed signal can be emitted regardless of the drag threshold. This is useful for implementing press-drag-release components such as menus, while using timeHeld to directly drive an "opening" animation. Change-Id: I298f8b1ad8f8d7d3c241ef4fdd68e7ec8d8b5bdd Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* Add button argument to the TapHandler.[single|double|]tapped signalsShawn Rutledge2021-09-081-9/+16
| | | | | | | | | | | | | | | | | | | | | | | | It would be better to emit the whole pointer event (by pointer because it's non-copyable, or make it copyable and emit by value), but we can't. So we just add the button being tapped; more information is available from the eventpoint argument and TapHandler's point property. To avoid name clashes with anything that's already called "button" in anyone's QML (which is quite likely, actually), the new signal argument is unnamed, so that users will be required to write a function signature that gives it a name rather than relying on context injection. [ChangeLog][QtQuick][Event Handlers] TapHandler's tapped(), singleTapped() and doubleTapped() signals now have two arguments: the QEventPoint instance, and the button being tapped. If you need it, you should write an explicit function for the signal handler: onTapped: function(point, button) { ... } or onDoubleTapped: (point, button)=> ... Fixes: QTBUG-91350 Task-number: QTBUG-64847 Pick-to: 6.2 6.2.0 Change-Id: I6d25300cbfceb56f27452eac4b29b66bd1b2a41a Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* doc: Add a TapHandler button snippetShawn Rutledge2021-08-051-0/+2
| | | | | | | | | It was ironic that it's the most obvious use case of TapHandler but we didn't have some easy copy-and-paste code for making your own button. Pick-to: 6.1 6.2 Change-Id: I680b6f828f0df82e2ab8b434a2e76aabb21fc2b9 Reviewed-by: Paul Wicking <paul.wicking@qt.io>
* doc: Improve the Input Handlers index pageShawn Rutledge2021-08-051-4/+9
| | | | | | | | | | | | | - Document the exclusive/passive grab concepts better - Mention gesturePolicy's impact on grab behavior in the TapHandler docs too - More links - Add a couple of snippets illustrating simple use cases with handlers - Don't bother mentioning Qt.labs.handlers anymore Task-number: QTBUG-68110 Pick-to: 5.15 6.1 6.2 Change-Id: I5e6f538c2bc8cafef679f535a5248b218b4a8068 Reviewed-by: Paul Wicking <paul.wicking@qt.io>
* Allow pointer handlers to be added to QQuick3DModel objectsShawn Rutledge2021-06-031-2/+5
| | | | | | | | | | | | | | | | | | | | | | 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>
* TapHandler: don't emit tapped() if non-filtering grabber on releaseShawn Rutledge2021-05-311-1/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This comes up for example in qtquick3d/examples/quick3d/dynamictexture: A TapHandler detects clicks on a 3D door model, to trigger the animation to open the door. But onto the door is mapped a subscene containing a TextEdit. If the user clicks in the text to set the cursor position: 1) TapHandler gets the press first (it's a handler, handlers go before items like the View3D), and takes a passive grab. 2) View3D does picking, discovers the subscene on the door surface and begins subscene delivery 3) TextEdit takes the exclusive grab 4) On release, the main DA goes first again; TapHandler gets the event because of its passive grab; but in QQTapHandler::handleEventPoint() we can see that there is another exclusive grabber, which indicates that it (the TextEdit) has taken full responsibility for handling the event sequence. TapHandler cancels the press and doesn't emit tapped(). 5) TextEdit gets the event via the subscene agent because of its exclusive grab; it sees a click and sets cursor position. On the other hand, if we did not check QQuickItem::filtersChildMouseEvents(), we would break some Flickable "interop" tests which expect that handlers can react in spite of Flickable having a grab. Being excessively "grabby" seems to go with the child-filtering concept, so let's continue to let TapHandler react in spite of the grabber in that case. It remains to be seen if we need alternate behavior in other scenarios, which would indicate the need for another enum property or so. Fixes: QTBUG-94012 Task-number: QTBUG-92944 Change-Id: I7d2b03fcb0d286d581547a14e71c27086a9b25f6 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Remove QQWindowPriv::is[Mouse|Touch|Tablet]EventShawn Rutledge2021-03-191-3/+4
| | | | | | | They are moved to QQuickDeliveryAgentPrivate. Change-Id: I5d6656dd6362dd03f0f4321cff07a8b207fadd39 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* QQuickSinglePointHandler: don't reset the point in hover handlersRichard Moe Gustavsen2021-03-051-0/+2
| | | | | | | | | | | | | | | | | A HoverHandler should not reset the reported position when it receives a mouse release. As it stands, a HoverHandler, like all the other SinglPointHandlers, will emit a position change of (0, 0) when clicking on it. This patch will factor the reset code into the virtual handleEventPoint(). By doing so, the subclasses can choose to call the base implementation to opt in for the "reset" logic. This patch will let all the subclasses, except HoverHandler, do that. Fixes: QTBUG-83980 Pick-to: 6.1 Change-Id: Idc5720a2aad2b0b5714807965e0edc4e8325bfdc Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Allow parent to filter out-of-bounds synth-mouse for grabbing handlerShawn Rutledge2020-11-301-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Consider Flickable { Text { TapHandler { gesturePolicy: TapHandler.ReleaseWithinBounds } } } On press, TapHandler gets the exclusive grab. Now drag vertically. The Text is short in stature, so your finger soon strays out of bounds of the Text, likely before you have dragged past the drag threshold. In this case, we want Flickable to continue to filter the move events because of the fact that TapHandler is the grabber. If it was a MouseArea instead of a TapHandler, it already worked that way; so this makes behavior of handlers more consistent with that. More specifically: QQuickPointerTouchEvent::touchEventForItem() now generates a touch event even if the touchpoint is not within the bounds of the given item, but is grabbed by one of that item's handlers. Until now, we had that exception only if it was grabbed by the item itself. tst_FlickableInterop::touchAndDragHandlerOnFlickable now always drags the delegate at index 2 (the third one) from its upper-right corner, upwards and to the left. The first drag goes outside the delegate's bounds, but the Flickable/ListView/TableView filters and takes over anyway (on the next drag), to prove that it is correctly depending on the grab that the TapHandler (or DragHandler) took on press. Pick-to: 5.15 Pick-to: 6.0 Fixes: QTBUG-75223 Change-Id: Ie4e22c87be0af9aa3ff0146067b7705949b15c40 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Remove QQuickPointerEvent etc.; deliver QPointerEvents directlyShawn Rutledge2020-09-181-36/+40
| | | | | | | | | | | | | | | | | | | | | | | 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>
* Remove QQuickPointerDevice in favor of QPointingDeviceShawn Rutledge2020-06-231-1/+1
| | | | | | | | | | | | | | ...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>
* Merge remote-tracking branch 'origin/5.14' into 5.15Qt Forward Merge Bot2019-12-091-5/+4
|\ | | | | | | | | | | | | Conflicts: src/qml/common/qv4compileddata_p.h Change-Id: I1150c8cd0161f0e22137d383013751394ae64e18
| * TapHandler: don't reject stationary touchpointsShawn Rutledge2019-12-061-5/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | Multiple TapHandlers must be able to react to multiple touchpoints. Often when multiple touchpoints are in contact, some of them will be stationary. In that case TapHandler should not give up its active state, which is the result of returning false from wantsEventPoint(). This partially reverts commit dcc7367997e7241918cdf0c702c7bb8325eb1ad4. Fixes: QTBUG-76954 Change-Id: I836baf771f09d48be8d032472b0c3143e8f7f723 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* | Merge remote-tracking branch 'origin/5.14' into 5.15Qt Forward Merge Bot2019-10-041-5/+5
|\| | | | | | | | | | | | | | | Conflicts: src/imports/qtquick2/plugins.qmltypes src/quick/items/qquickitemsmodule.cpp Change-Id: I841c65c9c131354788b4f3fcfe3d7ed27be316d5
| * Merge remote-tracking branch 'origin/5.13' into 5.14Liang Qi2019-09-121-5/+5
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: src/qml/jsruntime/qv4engine.cpp src/quick/handlers/qquicktaphandler.cpp src/quick/items/qquicktableview.cpp Done-With: Richard Moe Gustavsen <richard.gustavsen@qt.io> Done-With: Ulf Hermann <ulf.hermann@qt.io> Done-With: Shawn Rutledge <shawn.rutledge@qt.io> Change-Id: If9558a33f01693ce96420c094e0b57dfff0626cd
| | * Doc: Fix documentation warnings for qtdeclarativeTopi Reinio2019-08-291-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After recent changes to QDoc, it now correctly warns about missing documentation for QML method parameters - fix all of these and also do some minor language editing. Remove duplicated entries for - \qmlmodule Qt.labs.qmlmodels - \group qtjavascript as they were causing issues. Change-Id: I55cd670cc8a0cc6427cdb7945dbd7c28ea94f796 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* | | Add dragThreshold property to Event HandlersShawn Rutledge2019-09-191-8/+1
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* / Use QSH::mouseDoubleClickDistance() and touchDoubleTapDistance()Shawn Rutledge2019-08-121-9/+7
|/ | | | | | | | | | | | ... in documentation links and in implementation, now that they have been added. The doc links to QPlatformTheme::MouseDoubleClickDistance and QPlatformTheme::TouchDoubleTapDistance were dead ends because of those being private; and user code needed a way to read the values. So now there is new API in QStyleHints. Fixes: QTBUG-76944 Change-Id: I86bce4c7fe08c9da33745a4eed450757b3a30b03 Reviewed-by: Paul Wicking <paul.wicking@qt.io>
* Merge remote-tracking branch 'origin/5.12' into 5.13Qt Forward Merge Bot2019-07-121-9/+0
|\ | | | | | | | | | | | | | | | | Required a change to a #include; qquicksinglepointhandler.cpp was (at least on Android) only seeing QQuickSinglePointHandler as a forward declaration, so dereferencing it was a problem. The header that defines it does #include the one it replaces here. Change-Id: I6bc30ff9a91f55350172e4a4bcaaa7f99a2ffb28
| * TapHandler: wait until after tapped is emitted to reset point.positionShawn Rutledge2019-07-051-9/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We don't want it to hold its position indefinitely after the button is released. But in practice, reset() gets called again anyway in QQuickSinglePointHandler::handlePointerEventImpl(), _after_ handleEventPoint(), which means after tapped() is emitted. Having the point hold its position that much longer is convenient for applications and more consistent with the state expressed by the release event. Also amend the documentation. Partially reverts 17237efaefabe924599abe00e92d8b54032d7915 [ChangeLog][Event Handlers][Important Behavior Changes] TapHandler.point now holds the release position while the tapped() signal is emitted. Fixes: QTBUG-76871 Task-number: QTBUG-64847 Change-Id: I621a2eba4507a498788e9384344e8b4b7da32403 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* | Merge remote-tracking branch 'origin/5.12' into 5.13Qt Forward Merge Bot2019-05-161-6/+21
|\| | | | | | | Change-Id: Ia93dc734ce25b3134b0f905f473a0c30777ceaf1
| * Document TapHandler.tapped and [single|double]Tapped eventPoint argumentShawn Rutledge2019-05-091-6/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Amends b8fd580cb3453b3850c36765c4b2537538d2f4f8 to add documentation. The eventPoint is important to get ephemeral state from the pointing device: which button was released (thus triggering the tap), which device it was, and where the release occurred. Users may expect to use the point property, but QQuickHandlerPoint::reset(QQuickEventPoint *) resets every property of the point at the same time, so the architecture currently does not allow for mixed state, i.e. having correct button state but still holding leftover position information. It may be surprising for users, but the changes to the point property are an atomic transaction that occurs before the signal. Task-number: QTBUG-61749 Task-number: QTBUG-64847 Change-Id: I33e0e232084beba8e10d8b02fa3bf85f36293358 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* | Merge remote-tracking branch 'origin/5.12' into 5.13Qt Forward Merge Bot2019-03-131-6/+13
|\| | | | | | | | | | | | | | | Conflicts: src/qml/compiler/qv4codegen.cpp src/qml/animations/qsequentialanimationgroupjob.cpp Change-Id: I8b76e509fd7c8599d4cef25181d790ee28edab54
| * Doc: Fix link issuesNico Vertriest2019-02-281-6/+13
| | | | | | | | | | Change-Id: I0e08820a6d25996fe27118f05214ff63d695d24e Reviewed-by: Venugopal Shivashankar <Venugopal.Shivashankar@qt.io>
* | Merge remote-tracking branch 'origin/5.12' into 5.13Liang Qi2019-02-011-1/+1
|\| | | | | | | | | | | | | | | Conflicts: src/qml/compiler/qv4codegen.cpp Done-With: Erik Verbruggen <erik.verbruggen@qt.io> Change-Id: I3ae3d64317e4f3fccba6605f4c6da15479ca75e0
| * TapHander: do not "want" an eventPoint that is outside parent boundsShawn Rutledge2019-01-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | So far it was checking parentContains() on press, release, or when the gesturePolicy is WithinBounds, but not for each movement when the policy is DragThreshold (the default). This might explain most of the remaining warning noise: "pointId is missing from current event, but was neither canceled nor released" because it was possible for TapHandler to remember wanting a point that it should not have wanted, but without taking any kind of grab, and then complaining when that point was no longer present. Since it did not grab, it did not get the release, unless the release was part of an event containing a point that it DID grab. Fixes: QTBUG-71887 Change-Id: I26ce62279574cf6b0150f24e486f224a604ac6b1 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* | Merge remote-tracking branch 'origin/5.12' into devLiang Qi2019-01-291-2/+9
|\| | | | | | | | | | | | | | | | | | | | | | | Conflicts: src/3rdparty/masm/yarr/YarrJIT.cpp src/qml/compiler/qv4instr_moth.cpp src/quick/handlers/qquicksinglepointhandler_p.h src/quick/handlers/qquicktaphandler.cpp src/quick/items/context2d/qquickcontext2d.cpp Done-With: Ulf Hermann <ulf.hermann@qt.io> Change-Id: I109453131f9f0a05316ae37c7d6ed1edc8c0f9d4
generated by cgit v1.2.3 (git 2.25.1) at 2025-12-01 17:15:42 +0000