summaryrefslogtreecommitdiff
path: root/src/quick/handlers/qquickpointerhandler.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Use correct names for QEventPoint::State, PointerDevice::GrabTransitionShawn Rutledge2023-04-141-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | Qt::TouchPointState is not the actual type here, and we should not encourage e.g. making a comparison between eventPoint.state and Qt.TouchPointMoved in an onGrabChanged handler. The equivalence is an internal detail; and eventPoint can come from any pointing device, not only from a touchscreen. QEventPoint is a Q_GADGET; we keep the registration to expose it as a value type (eventPoint). But such types cannot be created in QML, and we also need to give it an uppercase name to scope the enum values that it declares: that's a new foreign namespace called EventPoint. So it's possible to compare an eventPoint instance's state property against EventPoint.Pressed, and so on. Also show complete QML syntax in the \value tables where PointerDevice::GrabTransition is emitted to QML, namely PointerDevice::grabChanged and PointerHandler::grabChanged. Amends b43a873264d012dc0a0e574ea53335a40af8aa38 Task-number: QTBUG-102160 Change-Id: If1a97f21d8e005e3692298b8512f7f8b56a92c97 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Doc: Remove duplicate words (typos)Andreas Eliasson2023-03-071-1/+1
| | | | | | Pick-to: 6.5 6.4 6.2 Change-Id: Ibd29739b894598e5d7837ed5f9150e08ca07fa35 Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
* doc: Update QML eventPoint; fix GrabTransition linkShawn Rutledge2023-02-211-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. 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>
* Pointer handlers: don't emit canceled() when an extra button interruptsShawn Rutledge2022-12-151-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Add FOREIGN declaration for QEventPointSami Shalayel2022-11-111-2/+2
| | | | | | | | | | | | 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>
* QQuickHoverHandler: listen for parent changes, and update hasHoverInChildRichard Moe Gustavsen2022-10-311-1/+4
| | | | | | | | | | | | | | | | | | | A QQuickHoverHandler is normally created by the QML engine, but can sometimes also be created directly from C++. And for the latter case, QQuickHoverHandler::componentComplete() will not be called. This causes a problem, since it takes care of subscribing for hover events on the parent item. To support creating hover handlers from c++, we therefore need to also subscribe to hover events from the constructor. Moreover, since the parentItem can change at runtime, we also need a virtual function that informs it when the parent item changes, so that we can remove hover subscription from the old parent, and subscribe for it on the new parent. Pick-to: 6.4 Change-Id: I52f3cd16d6bbfbbe2e4c3c019efdc7f06c5f2c31 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* QQuickHoverHandler: setHasHoverInChild to false when disabledRichard Moe Gustavsen2022-09-161-0/+2
| | | | | | | | | | | | | | | | Toggle setHasHoverInChild in sync with the handler being enabled. This fixes a bug: if a HoverHandler is hovered, and somehow the enabled property is programmatically set to false with no mouse moveement and without any other scenegraph changes (i.e. no item gets marked dirty and therefore flushFrameSynchronousEvents() doesn't run), its hovered property now changes to false immediately, as it should. The DA will get less items to traverse, so this is also an optimization. Pick-to: 6.4 Change-Id: I24be7d25ee15180fff010cc1c532266cd6e73ffb Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Ensure that multiple HoverHandlers can react to multiple device typesShawn Rutledge2022-08-251-0/+1
| | | | | | | | | | | | | | | | | | | | | | | 1c44804600ad3dbeb60d1f5209ce9cf937d30ab3 had some known incompleteness in QQuickItemPrivate::effectiveCursorHandler because it couldn't be finished in Qt 5; but HoverHandlers with different acceptedDevices and acceptedPointerTypes were working together in Qt 6.0 and 6.1 to an extent. Perhaps for this case it helped that HoverHandlers got passive grabs, but we stopped that in bbcc2657fa0dbf715e6db7d675662e4be94a1e04. So now, as with mouse events, we need to ensure that when a HoverHandler detects a particular stylus device in a QTabletEvent and chooses a different cursor, it is applied to the window. At this time, since QQuickDeliveryAgentPrivate::deliverHoverEvent() sends a synth-mouse event, it's not suitable for tablet hover; so we depend on correct implementation of allPointsGrabbed() to ensure that QQuickDeliveryAgentPrivate::deliverUpdatedPoints() will visit all the HoverHandlers, in this case only. Pick-to: 6.3 6.4 Fixes: QTBUG-101932 Change-Id: Ia8f31610e9252825afc7151be58765ac5217b0e8 Reviewed-by: Doris Verria <doris.verria@qt.io>
* doc: Add missing PointerHandler.CanTakeOverFromItems enum valueShawn Rutledge2022-08-161-0/+2
| | | | | | | | Amends 0a3eec60cab3c453b378ee45ac335e0dc2951f4b Pick-to: 6.2 6.3 6.4 5.15 Change-Id: Iae9d1b2b68dc48a52adf0438a09af8e53f5527f1 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* Consistently set and reset QQuickPointerHandler's currentEventVolker Hilsheimer2022-07-111-3/+4
| | | | | | | | | | | Set the pointer before we deliver to the handler implementation, and reset to nullptr afterwards. Fixes: QTBUG-104325 Pick-to: 6.4 6.3 6.2 Change-Id: I37ddcb7b20760867ebfd3f23449c6a83088926aa Reviewed-by: Mitch Curtis <mitch.curtis@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@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>
* Code tidiesZhang Hao2022-01-261-1/+1
| | | | | | | Delete the conditional judgment that must be established Change-Id: I2db7292cb368a979821336d5a639df9fb8e7e959 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Allow reparenting Pointer HandlersShawn Rutledge2021-12-101-1/+15
| | | | | | | | | | | | [ChangeLog][Event Handlers] The parent property of any Pointer Handler is now settable. Fixes: QTBUG-84730 Task-number: QTBUG-85926 Task-number: QTBUG-17286 Change-Id: Id738dd783de1acfbef9b5be203025040b0913008 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* HoverHandler: allow cursorShape binding before parentItem is setShawn Rutledge2021-12-031-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 Pick-to: 6.2 5.15 Change-Id: Id0defac7a238df522e8eee69f71e83a3947560af Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* 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. Pick-to: 6.2 Change-Id: I3b48165c04ef84288472963e39eafc0868c14c49 Reviewed-by: Paul Wicking <paul.wicking@qt.io>
* 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>
View Lorry Controller Status