summaryrefslogtreecommitdiff
path: root/src/quick/handlers/qquickhoverhandler.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Document the Pointer Handlers exampleShawn Rutledge2023-03-021-1/+1
| | | | | | | | | | | 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: remove docs for HoverHandler.dragThresholdShawn Rutledge2023-03-021-0/+7
| | | | | | | | | Like acceptedButtons, HoverHandler.dragThreshold is irrelevant. Pick-to: 6.2 6.4 6.5 Task-number: QTBUG-95395 Change-Id: I059e99449cff946b2caa945022b1f4bd4d2f845b Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* QQuickHoverHandler: listen for parent changes, and update hasHoverInChildRichard Moe Gustavsen2022-10-311-12/+39
| | | | | | | | | | | | | | | | | | | 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>
* 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>
* Fix typo in docsShawn Rutledge2022-10-081-1/+1
| | | | | | | | I can guess which keyboard I wrote that with. Pick-to: 6.4 Change-Id: I9b99e142a117b8c7dd81399e65659fee93f95104 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Ensure that item appearance is updated when hover state changesShawn Rutledge2022-09-271-2/+8
| | | | | | | | | | | | | | If a HoverHandler is enabled/disabled, or a MouseArea.hoverEnabled is set or unset, its parent may need to change its hovered appearance. Marking an item dirty is enough to ensure that flushFrameSynchronousEvents() will be called, in case there was no other event or property change to trigger that. Pick-to: 6.4 Task-number: QTBUG-46460 Fixes: QTBUG-106704 Change-Id: I5ced5f673baf387bbd0ee678e120538d1bb61c0e Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* QQuickHoverHandler: setHasHoverInChild to false when disabledRichard Moe Gustavsen2022-09-161-1/+19
| | | | | | | | | | | | | | | | 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>
* DA: ignore disabled HoverHandlers when delivering hover eventsRichard Moe Gustavsen2022-09-161-3/+1
| | | | | | | | | | | | | | | | | | | | | According to the documentation for HoverHandler::enabled, a disabled hover handler will not accept any mouse events. It therefore follows naturally that a disabled HoverHandler should also not affect event propagation elsewhere. This patch will change the implementation, so that we don't deliver hover events to HoverHandlers that are disabled. This also means that disabled HoverHandlers will no longer block propagation to its siblings. [ChangeLog][QtQuick][HoverHandler] Disabled hover handlers will no longer receive hover events, or block siblings from being hovered. Pick-to: 6.4 6.3 6.2 Fixes: QTBUG-106548 Change-Id: I7f2e459ba39f1e23cdb13bf94f8754e185dcd0c1 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Ensure that multiple HoverHandlers can react to multiple device typesShawn Rutledge2022-08-251-0/+3
| | | | | | | | | | | | | | | | | | | | | | | 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>
* Remove flushFrameSynchronousEvents from qquickwindow_p.hJohan Solbakken2022-07-171-1/+1
| | | | | | Change-Id: Ib1ae19eac2a5a95b71345b80075f871ea82fa928 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> 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>
* doc: Fix inherited property docs in HoverHandlerShawn Rutledge2022-04-281-0/+92
| | | | | | | | | | | | Some base class snippets use TapHandler, but it's better to show snippets specifically with HoverHandler. These snippets are also runnable and thus testable. Fixes: QTBUG-95395 Task-number: QTBUG-101932 Pick-to: 6.3 6.2 5.15 Change-Id: Ibcdc30ff8a785a3651177c79522332cf09c3013c Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
* Add HoverHandler.blocking propertyShawn Rutledge2021-12-091-0/+16
| | | | | | | | | | | | | | | As with WheelHandler, sometimes users want to let the hover events propagate (which has been the default all along), but sometimes it's not appropriate to allow parents of nested items to show hover feedback. [ChangeLog][QtQuick][HoverHandler] HoverHandler now has a property called blocking, which is false by default; but if set to true, it prevents hover events from propagating to items "under" this handler's parent, and their HoverHandlers. Task-number: QTBUG-85926 Change-Id: I26f89482e294c7a6b30a55a7e23ac444a0d1ac7f Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* HoverHandler: allow cursorShape binding before parentItem is setShawn Rutledge2021-12-031-0/+1
| | | | | | | | | | | | | | | 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>
* HoverHandler: don't change state if the event involves buttonsShawn Rutledge2021-07-151-0/+3
| | | | | | | | | | | | | | | | In the bug, HoverHandler was getting "hovered" during clicking, even though it already had the opportunity to be hovered while the mouse got into its parent's bounds (and at that time, it got un-hovered while Button was hovered instead). It gets hovered because QQuickDeliveryAgentPrivate::deliverMatchingPointsToItem() calls QQuickItemPrivate::handlePointerEvent() on the ListView's contentItem, because it has a handler. So it seems HoverHandler should not react to that event, because a button is being pressed. Fixes: QTBUG-72843 Pick-to: 5.15 6.1 6.2 Change-Id: I0bbcd351130a8d16165f04809c039b24b3864bf9 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* QQuickHoverHandler: don't use passive grabsRichard Moe Gustavsen2021-07-011-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | QQuickDeliveryAgent will clear the list of passive grabbers when we deliver: 1. a QPointerEvent::isEndEvent() from deliverPointerEvent() 2. a QEventPoint::Pressed event from deliverPressOrReleaseEvent() In other words, QQuickDeliveryAgent will clear the list of grabbers whenever it receives a mouse press or release. This doesn't work well with hover handlers, which were using passive grabs to ensure receiving updates: they also lost their grabs on press and release. This has some implications: 1. the list of hover items (QQuickDeliveryAgentPrivate::hoverItems) will no longer be in sync with the items we deliver events to. 2. a hover handler stacked underneath another hover handler will stop working. The reason is that QQuickDeliveryAgent detects that hoverItems is not empty, and as such, assumes that all handlers will receive events from their passive grabs. (which is no longer the case after the clear) So letting hover handlers rely on passive grabbing currently fails. It was also confusing that we delivered some of the hover events from deliverHoverEvent(), and others from passive grabs in deliverPointerEvent(). In Qt Quick 3D, when the hover is delivered because of a passive grab, we need to use sceneTransform; but when picking is done, the transform was already done at the same time. But hover events that come from flushFrameSynchronousEvents() always need to go through picking, and that happens frequently, so it's more consistent if we just rely on it all the time. In addition, the previous solution was assuming that only one leaf item would be under the mouse. This fails when you have siblings that overlap (and each sibling has HoverHandlers). While we could try to be more careful about when, and which, grabbers we clear here and there from QQuickDeliveryAgent, it seems better to dodge the whole passive grabber logic for hover handlers, and instead send all hover events directly from deliverHoverEvent(). This because we anyway need to traverse all the items in the application on each pointer move to check if new items are being hovered. So we might as well send out hover events in the same go. That way the logic becomes a bit easier to follow, and don't need to worry about keeping the hoveredItems list in sync with passive grabbing. tst_qquickhoverhandler: hoverHandlerAndUnderlyingMouseArea: - HoverHandlers have (conceptually) never stopped hover events from propagating to the parent. Still, this test checks that a MouseArea underneath a HoverHandler is not hovered. Since this now actually works, the test is changed. mouseAreaAndUnderlyingHoverHandler: - MouseArea now accepts hover events, which will stop propagation. This is done to preserve the same behavior as before. But this also means that a MouseArea that has another MouseArea as a direct child (which was a special case from before) will no longer get hover events after the child has accepted them. For the same reason, an item's HoverHandlers will also not get hover events if there is a child that is accepting them, as in this test case. Fixes: QTBUG-34882 Fixes: QTBUG-63670 Pick-to: 6.2 Change-Id: Id38042bcbd1c3ca5403b4b81b875b84196fcfc76 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Allow pointer handlers to be added to QQuick3DModel objectsShawn Rutledge2021-06-031-2/+4
| | | | | | | | | | | | | | | | | | | | | | 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>
* 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>
* QQuickHoverHandler: listen for HoverLeave eventsRichard Moe Gustavsen2021-03-111-0/+16
| | | | | | | | | | Let HoverHandler listen for HoverLeave events, so that we can explicitly tell it to leave its hovering state from the outside. The new function gets used in a follow up patch. Change-Id: Ieaaeb7dc4e4afc96bb60c7abfd34f2c2c09bef47 Reviewed-by: Shawn Rutledge <shawn.rutledge@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>
* Remove QQuickPointerEvent etc.; deliver QPointerEvents directlyShawn Rutledge2020-09-181-10/+10
| | | | | | | | | | | | | | | | | | | | | | | 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>
* Deliver QTabletEvents to pointer handlersv5.15.0-alpha1Shawn Rutledge2020-02-111-2/+17
| | | | | | | | | | | | | | | | | | | | At this time, there are not yet any specialized handlers to do anything specifically with tablet events; but we demonstrate how to use HoverHandler to detect the type of stylus in use, and how to use PointHandler to draw on a Canvas. Unfortunately, events of types TabletEnterProximity and TabletLeaveProximity are not delivered to the window, only to QGuiApplication. So HoverHandler can detect when the stylus is moved out of its parent Item (as long as it's still hovering over the tablet surface), but cannot detect when the stylus leaves the tablet completely. In Qt 5 that would require a custom application subclass (see qtbase/examples/widgets/widgets/tablet/tabletapplication.cpp). Fixes: QTBUG-79660 Change-Id: I81fdb99082dc41c0455085e6b6d3952402bf8742 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* Add PointerHandler.cursorShape propertyShawn Rutledge2020-01-311-0/+51
| | | | | | | | | | | | | | | | | | 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>
* HoverHandler: handle all device types; hovered=false on touch releasev5.14.0-alpha1Shawn Rutledge2019-09-191-5/+6
| | | | | | | | | | | | | | | It doesn't make sense to show hover feedback after releasing a touchpoint just because the core pointer cursor happened to move along with the touchpoint, so we explicitly set the hovered property to false when the touchpoint is released. However the next mouse movement will set it back to true again if the mouse cursor is still inside. This is especially important for touchscreen-based haptic interfaces: any hover feedback should be shown when a finger is dragged into an interface element and hidden again when the finger is released. Change-Id: Iff7f23f089466cc0da94d2a46690719f6d70cae2 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* Merge remote-tracking branch 'origin/5.12' into 5.13Qt Forward Merge Bot2019-08-281-3/+21
|\ | | | | | | Change-Id: I0ae0a162e133cffd8fb1a2c6b70826e50f06facd
| * Add missing HoverHandler docsShawn Rutledge2019-08-261-3/+21
| | | | | | | | | | | | | | | | | | It was intended to inherit most of the docs from SinglePointHandler; but the hovered property is unique. Task-number: QTBUG-68072 Change-Id: I4b49569c9966b9252a61e40e8b07ef98f34849a4 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* | Merge remote-tracking branch 'origin/5.12' into 5.13Qt Forward Merge Bot2019-07-121-0/+3
|\ \ | |/ | | | | | | | | | | | | | | 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
| * Move Event Handler acceptedButtons check back up to QQPDeviceHandlerShawn Rutledge2019-07-051-0/+3
|/ | | | | | | | | | | | Reverts what's left of e53510944169ac9f6753e0d14e1b24a24ff7bd9a (amends 73258eca7ab7e3981d9f4aaa5484020cb67854a0): MultiPointHandler is not only for touch handling anymore. DragHandler in particular needs to respect the acceptedButtons property. Fixes: QTBUG-76875 Fixes: QTBUG-76582 Change-Id: I414e785dd09b297c93e5e9f162be23e4a44eca54 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* Doc: Fix QDoc warningsPaul Wicking2018-10-011-1/+1
| | | | | Change-Id: I19545953bde10d4ccc2f37843dcda2569dc77df4 Reviewed-by: Martin Smith <martin.smith@qt.io>
* Fix potential nullptr-derefErik Verbruggen2018-09-131-2/+2
| | | | | | | Task-number: QTBUG-70142 Change-Id: I97fe80e94a553d81695f4516e84ff8ac0d086347 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* HoverHandler: stop handling any points outside the parent ItemShawn Rutledge2018-08-171-1/+1
| | | | | | | | | After 6008c5ded48b6d03d56bf4c4ab96177fbb185f93, QQuickPointerHandler::wantsEventPoint() does not check parentContains() so we have to do it in HoverHandler itself. Change-Id: I5bdebc251091367dbebfbab1fcb81c0b120d7902 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Fix PointerHandler constructors and destructorsShawn Rutledge2018-07-271-2/+1
| | | | | | | | | | | | | - 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-1/+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>
* Add HoverHandler to detect a hovering mouse pointerShawn Rutledge2018-06-281-0/+107
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>
View Lorry Controller Status