Qt 6.5.8-lts release Conflicts solved: dependencies.yaml Change-Id: Id2eeb915139bdd1943ffc498173db540f22ca2f3
Qt 6.5.7-lts release Conflicts solved: dependencies.yaml Change-Id: I8fbe9c1606825b726adf95e69a4fa86e2196f4e8
This reverts commit da5933f22c00270ac9083a089686e5c54e0057da. Revert of commercial SPDX license identifiers is required for the Qt 6.5.x opensource releases, Qt 6.5.4 onwards. Change-Id: Ic056fb761f242af0ec4c883ecb35d50804c1c67c Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
You can continue scrolling the main list with the mouse wheel even after reaching the end of the nested list. When using a trackpad, behavior is now the same. Added tst_qquickflickable::nestedSameDirectionTrackpad. nestedSameDirection.qml or the example from QTBUG-126514 is suitable for manual testing. Since we add a custom QPointingDevice to simulate a trackpad, use it in nestedTrackpad() too, for better realism. Fixes: QTBUG-124478 Change-Id: I9b9c9a41afcfa5d950093a31682013ae9e917f1a Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io> Reviewed-by: Ulf Hermann <ulf.hermann@qt.io> (cherry picked from commit 6d921e2d0ec6bec154ee03bbf70b882117bfcb2d) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org> (cherry picked from commit e1121fb1a072c2f2454addf1412390603580f553)
...to fix snapping behavior of
ListView { snapMode: SnapOneItem; delegate: ListView { ...} }
It doesn't accept the event with ScrollBegin phase, so shouldn't do it
for the ScrollEnd phase either.
Accepting ScrollEnd unconditionally broke nested ListView, for example,
where the higher-level one wouldn't snap back to the delgate and would
get stuck in a moving state -- that is, until you click it so that the
mouseReleaseEvent cleans it up.
Fixes: QTBUG-126042
Change-Id: I94b0a3570e4750d68501095c56f06f5cca31923f
Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
(cherry picked from commit c3a1a91581d1cb9517ee4ee45e139f80340248ee)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit 39dfd69e79652a630abefe24ffc730f1d89deb48)
(cherry picked from commit 2435e16255854946cc4fd90ba5e9cb8fe442fdcf)
When pressDelay > 0, if Flickable receives mouse or touch release before it has sent the delayed press, it needs to send the delayed press before allowing the release to be seen, in some sense. Further back in d02131e743597b9bd3070d986c61a1c91ea8317a the continuation of release event delivery after the delayed press seems to have been more limited in scope, to say the least. 8673ae8bb6d4bac01cc54638a7d617072299a808 added localPos = window()->mouseGrabberItem()->mapFromScene(...) QQuickWindowPrivate::cloneMouseEvent(event, localPos) window()->sendEvent(window()->mouseGrabberItem(), mouseEvent) where QQuickWindow::sendEvent() was _not_ the same as sending the event to the whole window (the grabber is the intended recipient, but sendEvent() was taking care of child event filtering back then). But over time we became convinced that sendEvent() should not exist, because it was used for non-standard forms of event delivery, could be hacked over time to do arbitrary things, and bypassed any old-school QObject event filters that users might expect to work. In bfde65a8180e3dbf811e757f6d95f9554f622475 though, it was assumed that since the delayed press got delivered to the whole scene, the release should be too. Now it looks a bit redundant: one can see in the debugger that the release gets an extra nested delivery to the whole scene again, after being partially delivered before the delayed press is sent. But that might be risky to change right now. So at the time of writing d7623d79ef4bc9533fced027bf1d173d68b4eba6, QQuickFlickable::mouseReleaseEvent() used an item-localized position (leftover code from 8673ae8bb6d4bac01cc54638a7d617072299a808) and it seemed reasonable to follow that precedent to handle delivery of a delayed touch press and then the release; but in retrospect, 1) we're sending the event to a window, so we don't expect the grabber-localized position to be retained; 2) in fact, QQuickDeliveryAgentPrivate::translateTouchEvent() treats the local position as scene position. QTBUG-118069 occurred because of this assumption being violated. 3) Even for mouse release, it no longer makes sense to localize to the grabber, now that we are sending the event to the window rather than just to the grabber (for quite a number of years already). It will get relocalized during delivery to each item and handler visited. 4) Maybe it doesn't even matter whether there is a grabber or not: we could resend the release to the whole scene regardless. But this patch is conservative; and now we optimize slightly by using QObject::isQuickItemType() rather than qmlobject_cast. tst_qquickflickable::pressDelay() tests the same old scenarios as before, but now with both mouse and touch, and gets a general revamping while we're at it. Fixes: QTBUG-118069 Change-Id: I0f33d23ac1eae9fd697f2eca315107169619706c Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io> Reviewed-by: Santhosh Kumar <santhosh.kumar.selvaraj@qt.io> (cherry picked from commit 45d4ccc765b7fae86aca749f7b0aabc9c4671b23) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org> (cherry picked from commit ca9e3ee30fe6e1756c219d9383667c26ada97a60) Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
If a TouchCancel event is sent to a Flickable, it should abort any current dragging operation done by the user. This patch will ensure that we do so. Fixes: QTBUG-117160 Change-Id: Iff332e597a0502396c2fd0e4988f01ab2119314d Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io> Reviewed-by: Seokha Ko <seokha.ko@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> (cherry picked from commit 5093e4c24347a2044e23ba057c0dfdc64df5019d) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org> (cherry picked from commit 3544aae7286902d22b5bdd3a0d5ee89578ce8814)
Updated the commercial SPDX-License-Identifier to the files in tqtc-qtdeclarative. Examples, tests, or documentation files were not updated. Task-number: QTQAINFRA-5900 Change-Id: I74e2ac15b270b503edc80369b126913dd2ec33e1 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
If Flickable has an exclusive grab (e.g if it's being dragged), and at the same time, a child has a passive grab (e.g a TapHandler inside a child of the content item), Flickable ends up getting the same pointer events twice. The reason this happens is because Flickable has a childMouseEventFilter. So the flickable will first get all the pointer events since it has an exclusive grab, just to see that the filter will receive the same events once more, as they next are delivered to the passive grabbers. The result is that Flickable will handle all pointer events (move, release etc) twice when it has en exclusive grab, which will even cause the flickable from stop flicking prematurely if the mouse release ends up outside the bounds of the flickable (because of a double call to handleReleaseEvent(), which will set stealMouse to false too early). To fix this, this patch will make sure that we don't handle any pointer events in the childMouseEventFilter if we already have an exclusive grab. After all, having an exclusive grab means that we're already getting the events the "normal" way, and shouldn't handle the same events once more. Fixes: QTBUG-104987 Change-Id: Iaed49cb860cf50ea38a70a6e546d9dcf25cce444 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io> (cherry picked from commit 1bac9de1136c8d52650199f9defefae2f1d6a1a5) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
If there are multiple moves between touch down and release, but they are merged, or if there is only one move, flick occurs but no movement signal is generated. So, send movementStarted if the view is moving in handleReleaseEvent Fixes: QTBUG-112924 Change-Id: I774799bac2a00296a72005dcfa9ade6683836d08 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io> (cherry picked from commit e6a363efe86dd6acbceade28d5eddbdca9c7b805) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>