aboutsummaryrefslogtreecommitdiffstats
path: root/tests/auto/quick/pointerhandlers/qquickhoverhandler/tst_qquickhoverhandler.cpp
Commit message (Collapse)AuthorAgeFilesLines
* tst_HoverHandler::window: Place window away from menu bar on macOSTor Arne Vestbø6 days1-1/+1
| | | | | | Pick-to: 6.10 6.8 6.5 Change-Id: I783d368dc9dffd20dad4b238e55d26da57d11d7b Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* Fix QQuickItemPrivate::eventHandlingBounds()Shawn Rutledge12 days1-0/+5
| | | | | | | | | | The second two arguments are width and height, not bottom-right coordinates. So after shifting the rectangle left and upwards, we need to add twice the margin to width and height, to have the same margin all the way around. Amends 8115731466b579f33295d5c8a71506475750284e Change-Id: I83797ffd460ee47599170090aefcda544c3e4483 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* Add effectivelyClipsEventHandlingChildren; skip event delivery when irrelevantShawn Rutledge2025-11-171-2/+166
| | | | | | | | | | | | | | | If a QEventPoint is clearly outside an item _and_ the bounds of all its children, or is simply outside the bounds of an item that clips its children, we can stop recursion, for purposes of QPointerEvent delivery, finding which items/handlers are hovered, or which could control the cursor shape. effectivelyClipsEventHandlingChildren() is also recursive, but at least the result gets cached. Task-number: QTBUG-140340 Task-number: QTBUG-115179 Change-Id: I085e38964de6993fa82ad3bd1256868125fde090 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* tst_HoverHandler::movingItemWithHoverHandler: check cursor changeShawn Rutledge2025-11-151-1/+1
| | | | | | | | | | | If an item with a HoverHandler with cursorShape moves under the mouse cursor, flushFrameSynchronousEvents() should cause the cursor to change shape, along with hovering the item. Amends cd7c5f94a0ed64c52d31998957134d099313932a Task-number: QTBUG-53987 Change-Id: I0fc3b093ac5377fd81205c6f50498bd8f817aa51 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* Stabilize tst_HoverHandler::movingItemWithHoverHandlerShawn Rutledge2025-11-061-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | We know QCursor::setPos() doesn't work on Wayland; but let's detect when it doesn't work, at runtime, and skip the rest of the test. The reason for the change 1c7213dbc00fa595aeaa98ad5631bac56782599e was that if there is no mouse, or if it never moves, QGuiApplicationPrivate::lastCursorPosition might not have changed from its initial offscreen position. So that's why this test does not send any explicit mouse moves. But the window should receive an Enter event, and QGuiAppPrivate::processEnterEvent() should set lastCursorPosition. If that also didn't happen after showing the window with the cursor above it, it's not Qt Quick's problem. flushFrameSynchronousEvents() may not be able to hover and un-hover the moving item if it doesn't know where the cursor is. If you have no mouse, the item can't be hovered anyway (except that we might fake it with the touchmouse, but that is not being tested here). Fixes: QTBUG-76312 Fixes: QTBUG-81884 Fixes: QTBUG-103065 Fixes: QTBUG-111294 Change-Id: I76512ccf717385f32fe123b7c6898bff4eb17385 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Blacklist tst_HoverHandler::twoHandlersTwoTouches for now; rearrangeShawn Rutledge2025-10-231-1/+1
| | | | | | | | | | | | | So when we touch-press the right HoverHandler, the left stays hovered sometimes. Hmm. Let's check the right one first, and see if that's also flaky. Subsequent hover patches may affect behavior here: that's what we are checking for. Task-number: QTBUG-141430 Change-Id: I10709cc454f25be91159c520a385603de7067acf Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Add tst_HoverHandler::twoHandlersTwoTouchesShawn Rutledge2025-10-211-0/+42
| | | | | | | | | | | | | | | | | | | | Clarify that the touch-hover behavior doesn't depend on touch->mouse synthesis. We started faking hover on touchscreens because MouseArea can handle synth-mouse events coming from touchscreens, so containsMouse was reacting to touchpoints: then QTBUG-40856 came along, and the fix for it cemented some rules in place. Then HoverHandler was added, and it was deemed reasonable to get similar behavior, even though it handles touch events directly: if your fingertip is touching, then the rest of your finger is hovering (just as the mouse cursor is hovering at the same time that the mouse button is pressed). In this test case, HoverHandler directly handles touch events, and there is no touchmouse. So far, we still have Qt 5 behavior: HoverHandler is a single-point handler, and if you try to press two of them with two fingers, the first one "wins". But this might need to change later, to support multi-finger hover. Task-number: QTBUG-40856 Change-Id: If46d766d80534d729d254ca12ed1069c1d94e7a4 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* tst_HoverHandler::touchDrag: QCOMPARE(QPoint, QPoint)Shawn Rutledge2025-10-211-2/+2
| | | | | | | | | QCOMPARE(QPointF, QPoint) requires too much precision: it can fail by a fractional pixel. Amends ff4c2c311f1957ebacb66f0d35406a51da2a544e Pick-to: 6.10 6.8 Change-Id: Icdcc895e855ea305090d1d4863b7c0f078922427 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* tst_HoverHandler::deviceCursor: more feedback about hovered stateShawn Rutledge2025-10-171-0/+4
| | | | | | | | | See which HoverHandlers are hovered when testing by hand, even if cursor-changing is buggy. Also check the mouse HoverHandlers after sending a QTabletEvent. Change-Id: I7ffa165235eaa8ac726733a27de728ef9a88a7c4 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* tst_qquickhoverhandler::asProperty(): remove redundant codeOliver Eftevaag2025-10-151-2/+0
| | | | | | | | | QQuickTest::showView() already ensures that a window becomes visible. We don't need to repeat that manually in the test after calling it. Pick-to: 6.10 Change-Id: Id8cadeb619544ee7b871fdff98f4b93a8a0c52ed Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* PointerHandler: Add handler to parent also on componentComplete()Oliver Eftevaag2025-07-181-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | It was possible for a handler to not be added to its parent item via data_append() when the handler is created as a property binding: ``` Item { id: parentItem property HoverHandler handler: HoverHandler { parent: parentItem } } ``` In that case, the HoverHandler won't be added to the parent item's default list property (data), since it's being assigned to a different property instead (handler). data_append() was the main way that pointer handlers installed themselves to items, but it is skipped in this case. Now we also call QQuickItemPrivate::addPointerHandler() in componentComplete() if the pointer handler was not already added. Pick-to: 6.10 Change-Id: I5c797f6abcfb19af7e897354fba39dd536e66140 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* DeliveryAgent: clear deviceDeliveryTargets before hover deliveryShawn Rutledge2025-04-161-0/+11
| | | | | | | | | | | | | | | | deliverPointerEvent() and deliverSinglePointEventUntilAccepted() already clear the QQuickPointingDeviceExtra::deliveryTargets list before each event delivery (since a97759a336c597327cb82eebc9f45c793aec32c9 and 262d7eb305e1dea8dac660bec3ccc50193258ea9). deliverHoverEvent() needs to do that too: in case there are a lot of hover delivery targets and the user doesn't move the mouse for a long time, but the scene is continuously updated, flushFrameSynchronousEvents() keeps sending hover events, and this list would keep growing if we don't clear it each time. Fixes: QTBUG-135975 Pick-to: 6.5 6.8 6.8.3 6.9 Change-Id: Ia91e3c977b45fc964228d3aad89938435f437449 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Tests: include QTest, not QtTestGiuseppe D'Angelo2025-04-151-1/+2
| | | | | | | | | | | | | Never use module-wide inclusions. They blow up build times. For QtTest this is usually just a typo (QTest was meant instead). Add missing includes as needed. In the diffs I've spotted other huge inclusions (QtQuick, QtQml), but those need more attention. Task-number: QTQAINFRA-7110 Pick-to: 6.9 6.8 Change-Id: I74bf3fe212f50a7a3a6af2b1c80bbcaabc2516d7 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* tests: Swap QScopedPointer<QPointingDevice> for unique_ptr touchscreenShawn Rutledge2025-03-291-1/+1
| | | | | | | | | | | | The default device from QTest::createTouchDevice() is a touchscreen, so we should call it that, to disambiguate touchpads (a few tests use them). And QScopedPointer is discouraged nowadays. Task-number: QTBUG-132212 Pick-to: 6.8 6.9 Change-Id: I2aeaf8cee3c7b6041945506e11fa62d7c923c556 Reviewed-by: Axel Spoerl <axel.spoerl@qt.io> Reviewed-by: Frederic Lefebvre <frederic.lefebvre@qt.io>
* Set fix position tst_QQuickHoverHandler::window to fix flakinessFrédéric Lefebvre2025-03-261-0/+3
| | | | | | | | | | | | | | | | tst_QQuickHoverHandler::window() is flaky on Opensuse, where the cursor is not hovering the window when it is failing. Set fix position to the window for the cursor to always hover at the right position. Unblacklist tst_QQuickHoverHandler::window() on Opensuse as it is no longer flaky. Fixes: QTBUG-122405 Pick-to: 6.9 6.8 6.5 Change-Id: I0c78e80d19c59e95d58765ce2f6e201121e14236 Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
* Correct license for test filesLucie Gérard2024-02-271-1/+1
| | | | | | | | | | | | | | According to QUIP-18 [1], all test files should be LicenseRef-Qt-Commercial OR GPL-3.0-only [1]: https://contribute.qt-project.org/quips/18 Pick-to: 6.7 Task-number: QTBUG-121787 Change-Id: I26d72e8de04d4c7c57b3b7838af5d033265de5ba Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Kai Köhne <kai.koehne@qt.io> Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* HoverHandler: setHovered(false) for any pointer event outside boundsShawn Rutledge2024-02-211-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | 8e822e981d91e688799c8670f11dfdf6aaf9e0d1 was expecting HoverHandler to receive a QTabletEvent when hover leaves. That worked before bbcc2657fa0dbf715e6db7d675662e4be94a1e04: a HoverHandler had a passive grab, so it would receive the next QTabletEvent that moved outside the item. Now that we stopped doing passive grabs, the event that indicates that the cursor is leaving the item is always a QMouseEvent sent from QQuickDeliveryAgentPrivate::deliverHoverEvent(). If the mouse event says the cursor is outside the item, it doesn't matter what device it came from: this handler is no longer hovered. But as before, if the position is still inside, and a particular HoverHandler is hovered because a tablet stylus was previously detected, do not un-hover merely because of a synth-mouse event at the same position. Amends 79893e1773be9d04208243cb88c1daf793d830a4 Fixes: QTBUG-116505 Task-number: QTBUG-101932 Pick-to: 6.5 6.6 6.7 Change-Id: Id0b622fad524ae4be8b37b9cb55e68384056964a Reviewed-by: Doris Verria <doris.verria@qt.io> Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Ensure that HoverHandler reacts if a touchpoint moves out of boundsShawn Rutledge2023-12-281-0/+43
| | | | | | | | | | | | | | | We rely on QQuickDeliveryAgentPrivate::flushFrameSynchronousEvents() mostly, but it doesn't get invoked without a window update request. So there is a special case when a touchpoint moves _out_ of an item that has a HoverHandler but is not reacting to touch in other ways: we just need to send another artificial hover event for each touchpoint to each hovered item to inform handlers about the new hover position. Fixes: QTBUG-120346 Pick-to: 6.2 6.5 6.6 6.7 Change-Id: I479362a2663943eb495fe0be418009165c7134bd Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Santhosh Kumar <santhosh.kumar.selvaraj@qt.io>
* Update cursor if frame-synchronous hover update discovers hover changeShawn Rutledge2023-11-181-0/+29
| | | | | | | | | | | | Also mark cursor as dirty and force update after shape change. Done-with: Matthias Rauter <matthias.rauter@qt.io> Fixes: QTBUG-53987 Fixes: QTBUG-90457 Task-number: QTBUG-54019 Pick-to: 6.5 6.6 Change-Id: I64d9f5d0a39dbf141a8e82bee824b47a8884139b Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* Monthly re-run of clang-tidy qt-* checks (11/2022)Marc Mutz2022-11-021-8/+8
| | | | | Change-Id: Ie7d9117f627984c4af2cf600c8e9119abf306319 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* QQuickItem: don't disable hover if a hover handler is activeRichard Moe Gustavsen2022-10-311-0/+40
| | | | | | | | | | | | | | | | | | | | | | QQuickItemPrivate::subtreeHoverEnabled should be true for an item if the item itself, or any descendants, are listening for hover. And the item itself is listening for hover if hoverEnabled is true, or if it has hover handlers. But QQuickItemPrivate::setHasHoverInChild() didn't take the latter into account. This meant that if a leaf item with a hover handler called setHasHoverInChild(false) at runtime (if the _item_ itself didn't need hover anymore), we also cleared subtreeHoverEnabled for the handler (unless the item had a descendant that subscribed for hover). This meant that it would be skipped during hover event delivery. This patch will make sure that an item cannot set subtreeHoverEnabled to false if it's in conflict with one of its hover handlers. Pick-to: 6.4 Change-Id: I89fb387430d9de31c5e1f4b137a37620dcc8a55c Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* QQuickHoverHandler: listen for parent changes, and update hasHoverInChildRichard Moe Gustavsen2022-10-311-0/+64
| | | | | | | | | | | | | | | | | | | 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>
* Attempt to stabilize tst_HoverHandler::deviceCursor (part 2)Shawn Rutledge2022-10-191-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | CI logs tell us that QTRY_COMPARE(mouseHandler->isHovered(), true) has been failing sometimes. It's not supposed to fail, because we are sending a mouse move event that should result in HoverHandler detecting hovering (as opposed to using QCursor::setPos(), which is known for being a more thorough test on window systems that support it, but also not working on some systems). On the hypothesis that this has something to do with timing, avoid checking isHovered() until after we have verified that the mouse-handling HoverHandler has received an event with a timestamp at least 100 ms after the one that went to the last tablet-handling HoverHandler, and only in that case continue with checking hover states and the cursor. And anyway, if it keeps failing, we might at least get the qCDebug line in the logs to be able to check the timestamps. Amends 79893e1773be9d04208243cb88c1daf793d830a4 Pick-to: 6.4 Task-number: QTBUG-107763 Change-Id: Id7c657bfadf7b49ba3440e28d13121c041d38816 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Attempt to stabilize tst_HoverHandler::deviceCursorShawn Rutledge2022-10-191-7/+5
| | | | | | | | | | | | | | | | | | If the test can't send QTabletEvents, we can't use AA_SynthesizeMouseForUnhandledTabletEvents to test device-specific cursor conflicts. There is so little left to test that we might as well skip it. Since QTest::mouseMove() takes a delay argument, we don't need to use qWait(). It should not have resulted in any flakiness, but we might as well remove it to save a little time. Amends 79893e1773be9d04208243cb88c1daf793d830a4 Pick-to: 6.4 Task-number: QTBUG-107763 Change-Id: Ic83a80f83fe51ad9413e21c5ca48c338d9ca3728 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Port from container::count() and length() to size()Marc Mutz2022-10-071-42/+42
| | | | | | | | | | | | | | | | | | | | This is a semantic patch using ClangTidyTransformator as in qtbase/df9d882d41b741fef7c5beeddb0abe9d904443d8: auto QtContainerClass = anyOf( expr(hasType(cxxRecordDecl(isSameOrDerivedFrom(hasAnyName(classes))))).bind(o), expr(hasType(namedDecl(hasAnyName(<classes>)))).bind(o)); makeRule(cxxMemberCallExpr(on(QtContainerClass), callee(cxxMethodDecl(hasAnyName({"count", "length"), parameterCountIs(0))))), changeTo(cat(access(o, cat("size"), "()"))), cat("use 'size()' instead of 'count()/length()'")) a.k.a qt-port-to-std-compatible-api with config Scope: 'Container', with the extended set of container classes recognized. Change-Id: Idb1f75dfe2323bd1d9e8b4d58d54f1b4b80c7ed7 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* QQuickItem: document and test how hover events work wrt the enabled propertyRichard Moe Gustavsen2022-09-161-0/+36
| | | | | | | | | | | | | | | | The current documentation for the "enabled" property claims that "This property holds whether the item receives mouse and keyboard events.". This is not completely true. Hover events have been enabled for disabled items for a long time, to e.g show tooltips, also for disabled items. Since changing this would cause regressions, and since hover events can anyway be switched on and off with a separate, explicit, API, document (and test) that this is how hover events actually work. Task-number: QTBUG-30801 Pick-to: 6.4 Change-Id: I59409cbb33fb3e2275809156c245e28c21891bbc Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* DA: ignore disabled HoverHandlers when delivering hover eventsRichard Moe Gustavsen2022-09-161-0/+47
| | | | | | | | | | | | | | | | | | | | | 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/+98
| | | | | | | | | | | | | | | | | | | | | | | 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>
* Use SPDX license identifiersLucie Gérard2022-06-111-27/+2
| | | | | | | | | | | | Replace the current license disclaimer in files by a SPDX-License-Identifier. Files that have to be modified by hand are modified. License files are organized under LICENSES directory. Pick-to: 6.4 Task-number: QTBUG-67283 Change-Id: I63563bbeb6f60f89d2c99660400dca7fab78a294 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* QQuickMouseArea: let MouseArea reject hover eventsRichard Moe Gustavsen2022-03-281-4/+4
| | | | | | | | | | | | | | | From testing Qt 6.1, a MouseArea should not accept hover events, and as such, block hover events from propagating. This patch will make sure that QQuickMouseArea rejects hover events, and thereby restore the behavior Qt had up till Qt 6.1. Fixes: QTBUG-95726 Fixes: QTBUG-95398 Pick-to: 6.3 6.2 Change-Id: I1b929092a3004dd47ef1b6d1a957837ccedc7390 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* QQuickDeliverAgent: don't propagate hover to siblingsRichard Moe Gustavsen2022-03-261-4/+4
| | | | | | | | | | | | | From testing Qt 6.1, hover events should not propagate between siblings. As soon as a leaf item is found that receives a hover events, the event should only propagate up the parent chain starting from the leaf item. Pick-to: 6.3 6.2 Change-Id: I7448f5322f529addb2260b0ee2b02d2cfadb55e1 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Mitch Curtis <mitch.curtis@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Do not rely on transitive includes in testsFabian Kosmale2022-02-141-0/+1
| | | | | Change-Id: Icb68dbecab6f675352cd58333c82fa6648025367 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* macOS: Skip test only if cursor can't be movedVolker Hilsheimer2021-12-111-3/+2
| | | | | | | | | | | | | | It's not ideal to use QCursor::setPos in tests (see QTBUG-76312) to test mouse related user input code, but it usually works locally (perhaps after giving permissions) and in CI as well (once provisioned correctly) so at least try to move the cursor, and only skip if the position isn't taken. Task-number: QTBUG-76312 Task-number: QTBUG-98492 Pick-to: 6.2 Change-Id: Ic0db2f6de71da389486e0cb74815f59878ac63d2 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Add HoverHandler.blocking propertyShawn Rutledge2021-12-091-4/+18
| | | | | | | | | | | | | | | 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/+23
| | | | | | | | | | | | | | | 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>
* Consolidate test helpers into private librariesMitch Curtis2021-09-131-4/+5
| | | | | | | | | | | | | | | | | | | | Previously each test would include and build sources from the shared folder. Now we make those sources a library, build it once, then have each test link to it instead. We also take the opportunity to move some helpers that qtquickcontrols2 had added into the quicktestutils library where it makes sense, and for the helpers that don't make sense to be there, move them into quickcontrolstestutils. We add the libraries to src/ so that they are internal modules built as part of Qt, rather than tests. That way we can use them in a standalone test outside of qtdeclarative. Task-number: QTBUG-95621 Pick-to: 6.2 Change-Id: I0a2ab3976fdbff2e4414df7bdc0808f16453b80a Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* QQuickHoverHandler: don't use passive grabsRichard Moe Gustavsen2021-07-011-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Stabilize tst_HoverHandler::movingItemWithHoverHandler()Shawn Rutledge2021-07-011-1/+1
| | | | | | | | | | It tries to move the "paddle" from its old position, out from under the cursor, and back under the cursor again; but it was moving its left edge to be under the cursor. That didn't necessarily work with arbitrary high-dpi scale factors. Change-Id: I8d52ed34c5d4dcc6d20c6aefa1c7bce7516138bd Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Autotests: stabilize hover event deliveryRichard Moe Gustavsen2021-03-261-0/+7
| | | | | | | | | | | | | | | | | | The most likely reason why hover event tests are failing, is because we get duplicated hover move events on the side from QQuickDeliveryAgentPrivate::flushFrameSynchronousEvents(). Since such events are delivered at rather random points in time, they can easily affect the tests. Especially since QTest::mouseMove() will deliver the move event sync to the application, followed by a qGuiApp->processEvents(), which will flush out any other mouse events queued up from QPA. Fixes: QTBUG-92000 Change-Id: I8fa1ce6771f18664c6cd4d9e3d32218938547ddd 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>
* Change the cursor within HoverHandler.marginShawn Rutledge2020-06-301-0/+51
| | | | | | | | | | | | | The visual cursor feedback was inconsistent with the hovered property when a margin is set. Amends 1c44804600ad3dbeb60d1f5209ce9cf937d30ab3 Pick-to: 5.15 Fixes: QTBUG-85303 Task-number: QTBUG-68073 Change-Id: I25506baecaecbd6450a0e95786f103024b46b1b8 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Add PointerHandler.cursorShape propertyShawn Rutledge2020-01-311-0/+46
| | | | | | | | | | | | | | | | | | 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>
* Tests: Fix warnings about ignoring return value of ↵Friedemann Kleint2019-04-081-1/+1
| | | | | | | | | | | | | | QTest::qWaitForWindowExposed() Fix warnings like: ../shared/particlestestsshared.h: In function 'QQuickView* createView(const QUrl&, int)': ../shared/particlestestsshared.h:64:33: warning: ignoring return value of 'bool QTest::qWaitForWindowExposed(QWindow*, int)', declared with attribute nodiscard [-Wunused-result] by checking the return and adding some handling. Change-Id: I1390f9738430042fcc45e243567a9d5a4f632a6d Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Fix a bug where hover events were not sent if the mouse was never movedJan Arve Sæther2019-03-041-0/+37
| | | | | | | | | | | | | This happened if the "real mouse" was never moved, since moving the real mouse caused it to update the internal QQuickWindowPrivate::lastMousePosition. If the window never got any mouse events, it would therefore fail to generate proper hover events. However, if the window got exposed under a mouse cursor it would generate a hover enter event. We therefore update lastMousePosition when that happens also. Change-Id: I77d9b1bd779a813756c4056b015f2e81664b6d36 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Add a HoverHandler autotestShawn Rutledge2018-08-231-0/+234
Change-Id: I223bad4f8117af76ad2a5079ecc0b73c2eba94bc Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2025-12-01 23:58:35 +0000