| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
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>
(cherry picked from commit b09ce7dcd8ecf24ef23da8197a64e3fced3fc894)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
QQuickPointerHandler::handlePointerEvent() calls setActive(false)
when wantsPointerEvent() returns false (except for a NativeGesture
event), for the sake of deactivating reliably when it receives an
event which it does not handle. Now we need one more exception, because
it's not what we want in DragHandler while dragging: If we get a
wheel event, that should not interrupt the current drag operation.
Thus, we change the logic in wantsPointerEvent to consider even events
we wouldn't normally handle while the DragHandler is active.
In handlePointerEventImpl, we then simply ignore them.
Fixes: QTBUG-91549
Change-Id: I24e8bd890a21b244c9964f4df76986688085fa87
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
(cherry picked from commit 40bbf1e8fddebb0974426a03b0f48dfc08f942de)
|
|
|
|
|
|
|
|
|
|
|
|
| |
Followup to ca7cdd71ee33f0d77eb6bf1367d2532e26155cb2 : when overriding
a virtual function, it's good practice to call the base class function,
in the absence of any reason not to.
Fixes: QTBUG-93880
Change-Id: Icbd04faec51d55d8fbf73319bd20f5846761d3d5
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
(cherry picked from commit a10eeee97d42f05409074f69cc99d9a8da5db077)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
Change-Id: I300547361dbe895b67caeee0d47f416426444552
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
(cherry picked from commit c740a9d30571079fa22fd26cb8e72df6ca28c7b2)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
No gesture handling has been implemented in DragHandler (although we could).
It just made the target item jump unintentionally.
QQuickMultiPointHandler::wantsPointerEvent() returns true for gestures,
because PinchHandler handles them, and the pattern is that base classes
only rule out some kinds of events but leave the final decision up to
the leaf class.
The autotest has to use a touchpad now, not the primary pointing device,
because QQuickPointerDeviceHandler::wantsPointerEvent() returns false
if pointerType != Finger and acceptedButtons() is not satisfied.
Fixes: QTBUG-92165
Change-Id: I984de750c9ae892f3ee61c7ed5b3ac4a7d187024
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
(cherry picked from commit 73051631545dc59d4419a5ef2202355349aab480)
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
Change-Id: I3a9b92d70f99497ee58ad8557d90d521fbe16d41
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
(cherry picked from commit fc636af3a723ee8b4ee42cf71864ae0df5ca4621)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
|
|
|
|
|
|
|
|
| |
Remove all qmake project files, except for examples which are used to
test that qmake continues to work.
Change-Id: Ic4abb72dc2dcd75df7a797c56056b6b3c5fe62ac
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Consider
Flickable {
Text {
TapHandler { gesturePolicy: TapHandler.ReleaseWithinBounds }
}
}
On press, TapHandler gets the exclusive grab. Now drag vertically.
The Text is short in stature, so your finger soon strays out of bounds
of the Text, likely before you have dragged past the drag threshold.
In this case, we want Flickable to continue to filter the move events
because of the fact that TapHandler is the grabber. If it was a
MouseArea instead of a TapHandler, it already worked that way; so this
makes behavior of handlers more consistent with that.
More specifically: QQuickPointerTouchEvent::touchEventForItem() now
generates a touch event even if the touchpoint is not within the bounds
of the given item, but is grabbed by one of that item's handlers. Until
now, we had that exception only if it was grabbed by the item itself.
tst_FlickableInterop::touchAndDragHandlerOnFlickable now always drags
the delegate at index 2 (the third one) from its upper-right corner,
upwards and to the left. The first drag goes outside the delegate's
bounds, but the Flickable/ListView/TableView filters and takes over
anyway (on the next drag), to prove that it is correctly depending
on the grab that the TapHandler (or DragHandler) took on press.
Pick-to: 5.15
Pick-to: 6.0
Fixes: QTBUG-75223
Change-Id: Ie4e22c87be0af9aa3ff0146067b7705949b15c40
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
| |
Change-Id: I9d01dc00c68979aa9288820fddaaa7b0208bec9b
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In particular, on press when QQuickFlickable::filterPointerEvent() calls
captureDelayedPress() and will return true, it also accepts the event to
stop propagation. It becomes the grabber as a consequence of that.
On a future move event, when the drag threshold is exceeded while the
delayed press timer is still running, Flickable already has the grab
(but it accepts the event again), and QQuickFlickablePrivate::drag()
calls setKeepMouseGrab(true). In this case we still want to prevent any
children's DragHandlers from seeing the event, because a DragHandler
will also see that the drag threshold was exceeded and try to steal the
grab. A DragHandler can steal the grab only if there was no press
delay: then it sees the initial press because Flickable does NOT stop
event propagation (does not accept the event), so it can take a passive
grab and continue to wait for the drag threshold to be exceeded,
regardless of what else happens.
In case of multiple touchpoints, allPointsGrabbed() returns false if the
Flickable has only grabbed one point; but we want to avoid delivering
handlers in children just on the basis of that grabbed touchpoint being
within their bounds, even though other points may be delivered to
various handlers.
This fixes tst_FlickableInterop::touchAndDragHandlerOnFlickable.
The blacklisting of dragHandlerInSiblingStealingGrabFromMouseAreaViaTouch
was bogus (it's in the mousearea_interop test).
Pick-to: 6.0
Task-number: QTBUG-86729
Change-Id: I9f0d42e97de4f4a3b4f7773800a8d59dc34a0553
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In several places these were doing stuff like
touch.press(1, p1).commit();
QTRY_VERIFY(devPriv->pointById(0)->passiveGrabbers.contains(drag));
The point ID is really the key in activePoints, it doesn't necessarily
start from 0; so pointById() has to be given the same point ID that was
used in the event, otherwise it will construct a new point(0).
But now tst_MptaInterop::touchesThenPinch fails further down: after the
complicated series of events, when only one point is still being dragged,
DragHandler fails to grab it and start dragging for some reason.
dragHandlerInParentStealingGrabFromItem() uses mouse not touch.
Pick-to: 6.0
Task-number: QTBUG-86729
Change-Id: I7ad0d3f30cb5fee15fe83183d62ee10a020c14df
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The QQuickPointerHandler::grabChanged() signal now has QEventPoint by
value rather than by pointer (because it's a value type, whereas in Qt 5
it was a QObject).
Amends a97759a336c597327cb82eebc9f45c793aec32c9
Pick-to: 6.0
Task-number: QTBUG-86729
Change-Id: I5514dc1b49a0b47276c41264e18f6a541bc2a3f0
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
QQuickWindowPrivate::deliverPressOrReleaseEvent() calls
QPointerEvent::clearPassiveGrabbers() for every QEventPoint that has
the Pressed state. This is consistent with the idea that for every
press (a different mouse button or a different touchpoint), we start
over with event delivery so that different items and handlers can see
what's going on and decide whether it's relevant for them. But
QQuickPointerHandler::onGrabChanged() reacts with setActive(false).
So for example if we press left mouse button, then keep holding it
and press right mouse button, PointHandler changes its active state
twice, because its passive grab was cleared and then we visit it again;
it's still interested in tracking the mouse, so it takes another passive
grab and becomes active again. Avoiding emitting activeStateChanged
in this case would seem a bit contrived. As long as the release of
one button doesn't make PointHandler completely lose interest
prematurely, QTBUG-66360 can still be considered fixed, I think.
Pick-to: 6.0
Task-number: QTBUG-66360
Task-number: QTBUG-86729
Change-Id: I132a8c5d1878769481b8afcc62ba237b4498b069
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Followup to 1457df74f4c1d770e1e820de8cd082be1bd2489e : if an item that
has acceptTouchEvents() == true merely fails to accept one touch event,
that does not mean a mouse event should be sent.
Finish changing the default to false: handling touch events is opt-in,
just like handling mouse events; most items don't. And if you opt in,
then you MUST handle touch events, because you will NOT receive mouse
events as a fall-back.
Now that Flickable handles touch, filtering multi-touch events becomes
relevant. There was a failure in tst_touchmouse::mouseOnFlickableOnPinch
when Flickable grabs a stationary touchpoint at the same time as another
touchpoint is pressed, preventing a child PinchArea from reacting.
So there's a new rule: just as we start over with event delivery when a
new point is pressed, QQuickFlickable::filterPointerEvent() should also
not immediately grab when any point is newly pressed; it can afford to
wait, because it's filtering, so it will be able to see if one point is
dragged past the drag threshold later on.
When a parent (such as Flickable) contains only mouse-handling items
(such as MouseArea), the parent should filter the touch event if it is
able (if acceptTouchEvents() returns true). Flickable is now able to.
Filtering parents that are not able to filter touch events can still
filter a synth-mouse event as before. But filtering both must be
avoided: then we would have the problem that Flickable filters a touch
move, sees that it's being dragged past the drag threshold, and sets
d->stealMouse to true to indicate that it wants to steal the _next_
event; then it filters a synth-mouse move, and that's perceived as being
the next event even though it's just a different view of the same event,
so it steals it. In tst_qquickflickable::nestedMouseAreaUsingTouch we
rely on the delay caused by waiting for the next event: the MouseArea is
trying to drag an item and the Flickable wants to flick; both of them
decide on the same event that the drag threshold is exceeded. But
MouseArea calls setKeepMouseGrab() immediately, whereas Flickable
doesn't try to steal the grab until the next event, and then it sees the
keepMouseGrab flag has been set, so it doesn't do it. If Flickable
could filter the same event twice (once as touch, once as synth-mouse),
this logic doesn't work, so it's effectively "more grabby" than
intended. So it works better to have it filter only the actual touch
event, not the synth-mouse that comes after.
When the child has pointer handlers, we need to visit them, and
therefore we should let Flickable filter a touch event on the way.
tst_FlickableInterop::touchDragFlickableBehindButton() depends on this.
[ChangeLog][QtQuick][QQuickWindow] In Qt 6, a QQuickItem subclass must
explicitly call setAcceptTouchEvents(true) to receive QTouchEvents,
and then it must handle them: we no longer fall back to sending a
QMouseEvent if the touch event is not accepted. If it has additionally
called setFiltersChildMouseEvents(true), then it will filter touch
events, not any synthetic mouse events that may be needed for some
children.
Task-number: QTBUG-87018
Fixes: QTBUG-88169
Change-Id: I8784fe097198c99c754c4ebe205bef8fe490f6f4
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
| |
Task-number: QTBUG-88541
Change-Id: I35b3f99c4268b6615da373f90b53b6ca6ef16fce
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
WheelHandler was only reacting to one wheel event between mouse moves,
because it got added to the QQPointerHandlerPriv::deviceDeliveryTargets()
vector, and was not removed at the beginning of delivery of subsequent
events, as QQuickWindowPrivate::deliverPointerEvent() does. (In Qt 5
the equivalent vector was cleared in QQuickPointerMouseEvent::reset().)
Wheel events are delivered via deliverSinglePointEventUntilAccepted()
(grabbing the wheel is still not implemented). Native gesture events
are delivered that way too; and sure enough, the same bug happens on the
macOS trackpad, whether you are attempting to do pinch zoom or just
two-finger-flick.
tst_QQuickWheelHandler::nestedHandler() sends multiple wheel events
in a row, so we do have some test coverage, and hopefully this issue
explains why it needed to be blacklisted.
Fixes: QTBUG-88428
Task-number: QTBUG-86729
Change-Id: Id1ed4a38dfa3eb2253c4a60f09f80aea0f69707e
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
QQuickWindowPrivate::cloneMouseEvent() renamed to clonePointerEvent()
and generalized to be able to clone any of the kinds of QPointerEvent
that we're interested in replaying. Now it is used only in
QQuickFlickablePrivate::captureDelayedPress().
Reverts f278bb7c66bb00c9f81b7a3aceeb94cb9b3a1b66 and
012a4528a515af8d7ec7dbc05a38d8fd0d6d4d1b (don't skip
tst_TouchMouse::buttonOnDelayedPressFlickable). Some test changes
from f128b5dee8a2a03ebc55ed0cd1e749a6599282c3 also get reverted.
QEventPoint should always have valid velocity now, so
Flickable no longer has to calculate it for itself.
Removing that became necessary to fix the movingAndFlicking test.
Adds logging categories qt.quick.flickable.filter and .replay.
Fixes: QTBUG-85607
Task-number: QTBUG-83437
Task-number: QTBUG-78818
Task-number: QTBUG-61144
Task-number: QTBUG-88038
Task-number: QTBUG-88138
Change-Id: I0ed6802dff5e5d1595adddc389642925f1f2c93d
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
|
|
|
| |
In Qt 6, setAcceptTouchEvents(true) must be done explicitly for an
item to receive touch events.
Task-number: QTBUG-86729
Change-Id: Ib18db22b6a7213dfcfdf091d554ef60fbede6111
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
|
|
| |
PointerHandlers see more events now.
Task-number: QTBUG-86729
Change-Id: I4dbddc8b54292450cf5ffb77489178a8a824b90d
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
| |
Task-number: QTBUG-86729
Change-Id: I47a0a4aad7cff956b2ebd450870d625f817690d4
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
|
|
|
|
| |
Check the actual touchpoint's grabbers instead of the synth-mouse.
Anyway it looked odd to press touchPoint ID 1 and then look for the
persistent point with ID 0 on the primary pointing device, which isn't
always a mouse.
Task-number: QTBUG-86729
Change-Id: I0a27fdd931059b30b0b5a54328bbef6254d26e04
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
| |
Task-number: QTBUG-86729
Change-Id: Ia4db0a98a4977cb89799c5749983a370d35317a7
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
|
| |
Modify special case locations to use the new API as well.
Task-number: QTBUG-86815
Change-Id: I3b964e3baf0cc7040830156dac30358ea1152801
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
|
|
|
|
|
|
| |
Task-number: QTBUG-86729
Change-Id: I35dc7ac91d2507a229dc1dde19f380e7111a4757
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
| |
Task-number: QTBUG-86729
Change-Id: I49fb86e867afeee2f0567dc3498598b249ae5e08
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Call onGrabChanged on Pointer Handlers during grab transitions:
this was missing in a97759a336c597327cb82eebc9f45c793aec32c9.
Flickable needs to receive an ungrab by child-event-filtering,
in order to set its pressed state back to false (as in the
cancelOnHide autotest). This is best done as a result of the
QPointingDevice::grabChanged signal, while trying to send the ungrab
to the item that was the grabber, rather than as a special case.
Thus, QQuickWindowPrivate::onGrabChanged (the handler for the
QPointingDevice::grabChanged signal) is now the only place from which
we call QQuickItem::mouseUngrabEvent() and touchUngrabEvent().
But the result is that they are called in more cases than before,
so some tests need adjustment. touchUngrabEvent() is not sent
unless the event is available and we can verify that all points
have been released. This is important for MultiPointTouchArea:
it will react by ending interaction with all points at once.
Another thing that's important to MPTA and multi-touch handlers is that
QQuickWindowPrivate::deliverPointerEvent() must not clear grabbers of
points that are not yet released, in the case that only some points are.
QQuickWindowPrivate::removeGrabber() now calls
QPointingDevicePrivate::removeGrabber() with its optional cancel
argument, so that it will emit either a cancel or an ungrab transition.
That's only relevant for Pointer Handlers, whereas QQuickItem
mouseUngrabEvent and touchUngrabEvent don't make a distinction.
Task-number: QTBUG-86729
Change-Id: Idf03aef2e2182398e0fc4a606c0ddbb2aaed5681
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
| |
Task-number: QTBUG-86729
Change-Id: Ib2585663d8cc213ccd14d1fa5d3bd854062b09c9
Reviewed-by: Daniel Smith <Daniel.Smith@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
qtbase/2692237bb1b0c0f50b7cc5d920eb8ab065063d47 and the associated
Qt Quick change to do direct delivery of QPointerEvents seem to have
broken a number of tests as they are currently written. It looks bad;
however I spent a lot of time already on some older "basic" tests
like tst_qquickwindow, touchmouse, tst_qquickflickable etc. and found
a lot of things to fix while doing that; so at least those aren't broken
now. Troubleshooting each test takes time. Hopefully it will turn out
that many of these failures are related (there seems to be something in
common about handlers and items stealing touch grabs from each other).
Task-number: QTBUG-86729
Change-Id: I14acf57fc83fa961a25f91108dcd4aea42b54435
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When creating a target item list for handling pointer events, put
children after the parent item if they have negative z-order value.
This fixes an issue where an item does not receive a pointer event if
there is a child item that accepts the event even when that child item
is shown under the parent item as per the stacking order.
Fixes: QTBUG-83114
Pick-to: 5.15
Change-Id: I711faa22516f5c2396b1138dc507bcaa4ba22241
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After qtbase b50daef9771d8829fc7f808898cbe051a5464b79, a mouse move
event that does not contain a mouse location different than the last
known location is no longer delivered.
It's intended to be OK to set DragHandler.threshold to 0, and this test
was checking functionality in that case; but we now need to move the
mouse at least one pixel to test it. Then, the drag threshold is
immediately exceeded, the drag begins, translation starts to occur, etc.
Amends ab5df626bef9365089ce716ce476bccae1d0a04b
Task-number: QTBUG-85431
Change-Id: I89c0dc13ed06fbf1443f42fa5b63713da56ecf6d
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is an intermediate step to get Qt Quick working again after
qtbase 4e400369c08db251cd489fec1229398c224d02b4.
- QQuickEventPoint::id() is no longer unique across devices, because now
eventPoint.event.device tells which specific device the event comes from.
(In Qt 5, we could not yet add the device pointer to QInputEvent.)
- However, MultiPointTouchArea's docs say that each pointId is unique,
and so do the HandlerPoint docs (for similar use cases with PointHandler).
So we still need the same hack using a Qt-specific short device ID
to unique-ify the QEventPoint::id(). Now we use the device index
in QInputDevice::devices() as the short ID.
- Otherwise, we trust QInputDevice::systemId() and QEventPoint::id()
more than before.
- Use QMutable* classes from qevent_p.h to continue using setters
that were in QTouchEvent before, etc. But setTouchPoints() is
not there, so we have to make new event instances in a couple of cases.
- QGuiApplicationPrivate::setMouseEventCapsAndVelocity() and
setMouseEventSource() are gone.
- Use (compiler-written) event copy constructors when possible.
Task-number: QTBUG-72173
Change-Id: I3915dc535ae4c5a81cbf333aba9355f01c420c15
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's a cosmetic change at this time, because we have declared
using TouchPoint = QEventPoint;
Also replace Qt::TouchPointState enum with QEventPoint::State.
Task-number: QTBUG-72173
Change-Id: Ife017aa98801c28abc6cccd106f47a95421549de
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a PointerHandler with a custom cursor deactivates, the cursor
wasn't restored until the next mouse move.
I was writing a test to ensure that there were no bugs analogous
to QTBUG-85303 with a handler that uses its active state to change
the cursor (unlike HoverHandler which changes it whenever the
mouse is hovering) and found this new bug.
Pick-to: 5.15
Fixes: QTBUG-85325
Task-number: QTBUG-85303
Change-Id: I4ea8dbd267046c8e972e723cc491bd44bbbfd7f2
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
...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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Several event accessors were deprecated in
qtbase/24e52c10deedbaef833c0e2c3ee7bee03eacc4f5.
Replacements were generated by clazy using the new qevent-accessors check:
$ export CLAZY_CHECKS=qevent-accessors
$ export CLAZY_EXPORT_FIXES=1
$ ../qt6/configure -platform linux-clang -developer-build -debug
-no-optimize-debug -opensource -confirm-license -no-pch QMAKE_CXX=clazy
$ make
$ cd ../../qt6/qtdeclarative
$ find . -name "*.clazy.yaml"
$ clang-apply-replacements .
Task-number: QTBUG-20885
Task-number: QTBUG-84775
Change-Id: I1be5819506fd5039e86b4494223acbe193e6b0c9
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
|
| |
Also add the missing cmake file for mousearea_interop
Task-number: QTBUG-84869
Change-Id: I7e48653c815aaaa3e23824783f6a0ff390c0907a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
|
|
|
|
|
| |
Change-Id: Ia0a075e3199eab735f9b289873beeb8730ebc47e
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
| |
Change-Id: If8daa6152a563d4309d7342414780ef75b9f5589
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
|
|\
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
dependencies.yaml
src/qml/qml/qqmlengine.cpp
Change-Id: I6a73fd1064286f4a2232de85c2ce7f80452d4641
|
| |\
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
src/imports/qtqml/plugin.cpp
src/qml/qml/qqml.h
src/qml/qml/qqmlmetatype.cpp
src/qml/qml/qqmlmetatype_p.h
src/qml/qml/qqmltypeloader.cpp
src/qml/types/qqmlbind.cpp
src/quick/items/qquickitemsmodule.cpp
tests/auto/qml/qqmlecmascript/tst_qqmlecmascript.cpp
Change-Id: I52548938a582cb6510271ed4bc3a9aa0c3c11df6
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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>
|
| | |
| | |
| | |
| | |
| | |
| | | |
Task-number: QTBUG-81993
Change-Id: I378e4873e9cf8e8805eaaf8cf0dd8e0afaf11108
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
| |/
| |
| |
| |
| |
| |
| |
| |
| | |
The cursor cannot be moved on macOS >= 10.14.
Task-number: QTBUG-76312
Task-number: QTBUG-81884
Change-Id: Iec73d572d2ccc0a4be8cc6c2c0b445329a200609
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |
| |
| |
| |
| |
| |
| | |
Change-Id: I48d7fd306f3d1b161a8e73029282ee591b1ef612
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Liang Qi <liang.qi@qt.io>
|
|\|
| |
| |
| | |
Change-Id: I0c5b939c70bdb91ccdf7068784308416dcaa5736
|
| |\
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
src/quick/items/qquickitemsmodule.cpp
src/quick/items/qquickitemview.cpp
Change-Id: I02191959a5023c4320f5487a7fb3a71f8711195f
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Task-number: QTBUG-81290
Change-Id: I58f64f5eabdb72f2f01bf72e988941521a89d331
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|