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.

Fixes: QTBUG-101932
Change-Id: Ia8f31610e9252825afc7151be58765ac5217b0e8
Reviewed-by: Doris Verria <doris.verria@qt.io>
(cherry picked from commit 79893e1773be9d04208243cb88c1daf793d830a4)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>

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.

Task-number: QTBUG-67283
Change-Id: I63563bbeb6f60f89d2c99660400dca7fab78a294
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
(cherry picked from commit 0dc4fd240a2897c5c443a0ef6d84c416843e4938)
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>

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>

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>

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>

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>

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>

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>

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>

They are moved to QQuickDeliveryAgentPrivate.

Change-Id: I5d6656dd6362dd03f0f4321cff07a8b207fadd39
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>