| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
Change-Id: Icd92121bb65ffca1135c1ef69b90d8a8955c1df0
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
(cherry picked from commit b788ef085c66d95aa75052c079d9d2fe15bc7f16)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
|
|
|
|
| |
Change-Id: I627754227cda376eea1bafedcdd163094941725a
Reviewed-by: Qt Submodule Update Bot <qt_submodule_update_bot@qt-project.org>
|
|
|
|
|
| |
Change-Id: I497c80c19d6bc9aba7876132ed0ef20aec632810
Reviewed-by: Qt Submodule Update Bot <qt_submodule_update_bot@qt-project.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Use QQuickTest::showView() consistently to reduce boilerplate
- Use QTest::mouse*() where possible rather than constructing QMouseEvents
(and potentially getting them wrong)
- Use QPointingDevicePrivate::firstPointExclusiveGrabber() on a specific
device to check grab state rather than QQWindow::mouseGrabberItem()
- The warning "event went missing during delivery!" has been removed,
so tst_QQuickMouseArea::nestedEventDelivery() shouldn't expect it
Task-number: QTBUG-86729
Change-Id: Ieb1af38c118dadf8cdf8ae19f92002207d71d5b5
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit f1a9c9b4273ec6104a0543b5cf48281141f613e6)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
|
|
|
|
| |
Change-Id: Ib40299337a3f0eabc0c87e871242558520f91dda
Reviewed-by: Qt Submodule Update Bot <qt_submodule_update_bot@qt-project.org>
|
|
|
|
|
| |
Change-Id: Ie0f6533c6f5458aedf78a7191b4044eb3a9823d7
Reviewed-by: Qt Submodule Update Bot <qt_submodule_update_bot@qt-project.org>
|
|
|
|
|
|
|
|
|
|
|
| |
Restore the position of the single event point after event delivery.
Where possible, don't make a localized copy which explicitly shares
its data with the original anyway. Instead, access the original
directly.
Change-Id: I5efa44c336eddeef1a1ab00dc91e2d0f223ed31d
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Most of the time, QQuickWindowPrivate::deliverMatchingPointsToItem()
doesn't need to call item->mouseUngrabEvent() because all grab changes
are notified via the connection from signal QPointingDevice::grabChanged
to slot QQuickWindowPrivate::onGrabChanged(). But in this case,
MouseArea only accepts the event, rather than taking the grab itself.
Therefore at the time the grab is "stolen", there was not yet any
grabber, because grabbing is done after delivery. But we still need to
inform MouseArea that it's not getting the grab it expects to get, so
that it can reset its pressed state. But we don't want it to be
redundant (other tests are counting events, and we don't want repeated
ungrabs to show up in those); so now we have to track whether the item
on which we're about to call mouseUngrabEvent() has already gotten it.
This illustrates another problem with the tradition of accepting events
and being unclear about what it means. Grabbing is one thing, ending
delivery is another.
Amends a97759a336c597327cb82eebc9f45c793aec32c9
Task-number: QTBUG-55325
Task-number: QTBUG-86729
Change-Id: I8150f901e00e7a71499fc98ab54f0ba75370f3ec
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a QQuickWindow is deactivated, visiting every item in the entire
scene to tell them the news isn't very efficient, especially considering
that the only item that overrode this virtual function has been
QQMouseArea, throughout the lifetime of Qt 5. If it's important to
cancel grabs of MouseAreas, then it's equally important to cancel grabs
of MultiPointTouchArea, pointer handlers, etc. It should be OK to
delete the virtual function since it was never documented, and marked
\internal, so hopefully no users are depending on it.
The existing tst_QQuickMouseArea::pressedCanceledOnWindowDeactivate()
test continues to pass, which proves that the WindowDeactivate event
still has the desired effect on MouseArea.
Change-Id: I0109370aba14096fb7777a83cf1b6763ac58013f
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
| |
Change-Id: I3b2d1fbc4b62b501aa6ed748a692cb4bba261c5e
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
|
|
| |
-changes to Qt Quick QML Types and OpenGL support
-content from doc/src/qmlapp/applicationdevelopers.qdoc
Task-number: QTBUG-87156
Change-Id: I3384e5bfa070c891015e5aa4af2e2c0b2dae35cf
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
|
|
|
|
|
|
|
| |
Task-number: QTBUG-88650
Change-Id: I2cac1b8ca7ec8ed8401206cf761244b3f483ca14
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
|
|
|
|
| |
Change-Id: I1250aec61bac08e4b658ae24a51fab5d54576c14
Reviewed-by: Qt Submodule Update Bot <qt_submodule_update_bot@qt-project.org>
|
|
|
|
|
|
|
|
| |
Also don't mention qmlExecuteDeferred: That one is internal anyway
(albeit not explicitly marked as such yet).
Change-Id: Icef5fb4092b6a109613ae1f2e90fcff93d7c0b4b
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
|
|
|
|
|
| |
Change-Id: If3640ef5cbb6df4b199b481410e79e94ea763645
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
| |
We don't need to handle symbol clashes with QtQuick1 anymore.
[ChangeLog][QtQml] The functions qmlDebug, qmlInfo, and qmlWarning are
no longer available in the QtQml namespace. Use their counterparts in
the global namespace.
Fixes: QTBUG-88637
Change-Id: Ia74510bd711790cebf55de4cd668891712f6835e
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The goal is to un-blacklist the test for QTBUG-60123. To that end:
revert 7b2e2117162594a2d0234bb02408f5b5a446488b and its followup
6933b7e8e6dc279a8eb34e1f4c60bc109dfb7d26. There is no detailed bug
report explaining exactly why those were done, just the comment on code
review: "This fixes the desktop components' combo box on linux
re-opening at random times", probably referring to a combobox popup
window in Controls 1. But when using QWidget::createWindowContainer()
in two different windows and clicking MouseAreas in each of them, it
turns out that this change of focus is causing the mouse grab to be
canceled. The grab should be naturally given up after mouse release;
canceling prematurely doesn't make sense.
The Qt 5 fix for this bug was e0c30279ec1fad88346ed3fb483bc3c672fdd01b
which tracked the grab on a per-window basis. It would be difficult to
do that again now (change QPointingDevicePrivate::setExclusiveGrabber()
to store a separate grabber for each window in which a grab occurred?
what could go wrong...) It seems odd to have the same QEventPoint
grabbed in two different windows at the same time, but popups need event
forwarding so maybe that was why (if a MouseArea triggers the popup,
should it stay pressed and keep its grab? the subsequent mouse moves and
the release need to be forwarded to the popup, so maybe something inside
the popup needs a grab, simultaneously or not). Anyway we don't have
actual popup windows in Controls 2 right now; and we know that event
forwarding for popups needs work in QtGui so that it will be easier when
we try again to have them in Qt Quick (QTBUG-68080). So perhaps the
original workaround has outlived its usefulness: popup event forwarding
needs to be handled at the lower layer, not in Qt Quick.
Task-number: QTBUG-57253
Task-number: QTBUG-60123
Task-number: QTBUG-86729
Change-Id: I56dbc3bb94f66a7f26f79a97bcb2f2bbc0b7aa92
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I guess I must have thought it would be more realistic that way;
but sending an explicit WindowDeactivate as we had it in early Qt 5
seems to keep the test passing now, and is probably more reliable.
The original purpose of the test seems to be to verify the recursive
delivery to all items via virtual QQuickItem::windowDeactivateEvent(),
which MouseArea (and no other item!) overrides to ungrab the mouse.
This mostly reverts commit 1c451b40aee66a38ca3d61e5beec4ae8c986c8ed.
Change-Id: I0c6f953514095a491120a0aac9944dc8b04ca17d
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
| |
Change-Id: Ib6da28cb87975ead3e7c695d455639a39e3982cb
Reviewed-by: Qt Submodule Update Bot <qt_submodule_update_bot@qt-project.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When doing static builds, mkspecs/qml_module.prf embeds the qmldir
file and any additional foo.qml files into a generated Qt resource
file.
The resource name is called qmake_<qml_plugin_uri>.qrc.
In turn, certain Qt modules and plugins code call
Q_INIT_RESOURCE(<qml_plugin_uri>) to initialize the resources.
When Qt is built with CMake there were 2 differences.
Because the resource files are not compiled into the static libraries
but rather passed around as object files, there is no need to
call Q_INIT_RESOURCE() anymore.
The second difference was that the generated resource name for
resources containing the qmldir file was '<qml_plugin_uri>_qmldir'.
The differences in the CMake build caused issues when linking a
QtQuick3D example project with a static Qt.
That happened due to the mismatch of the generated resource name in
the Q_INIT_RESOURCE() call.
Unfortunately these calls can't be removed during the build system
transition phase because that would break qmake Qt builds.
To fix this, change the name of the CMake generated resource to match
the qmake name. This avoids the undefined symbol errors during
linking, but is actually a no-op! That's because the global
initializer in the linked resource object file will be called before
the manual Q_INIT_RESOURCE() call, effectively making the latter a
no-op.
Note there is one more difference regarding the CMake build. The Qt
CMake builds creates 2 different resource files, one for the qmldir
file (inside qt6_add_qml_module) and another separate resource for qml
files (inside qt6_target_qml_files).
qmake in comparison creates only one resource file for both.
In practice this shouldn't affect or break anything, because even if
there is no explicit Q_INIT_RESOURCE() call for the qml files
resource, the global initializer will still be called from the linked
in object file.
An issue might happen if there are qml files, but no qmldir file,
because then the qmake-required Q_INIT_RESOURCE() would not be called
due to the missing qmldir resource (as generated by CMake).
I think such a scenario is very unlikely if not impossible.
Task-number: QTBUG-88425
Change-Id: Ib12d93d0dae52785ba8182db6829f03524723ca7
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After any call to qt6_add_resources we need to record info about the
resource object files. These will be embedded into the appropriate prl
files to ensure that any application built with qmake links in the
resources (only relevant for static Qt builds).
The implementation is a bit ugly, but it gets the job done for now.
It checks for the existence of an internal Qt function in the public
macros and calls it if it's available. That will only happen when
doing Qt builds. For regular app projects the functions will not be
called, but we don't generate .prl files for such projects either way.
Note that this comes with the same limitation as described in the
changes for fixing QTBUG-88425. Specifically, the functions will only
record resource object files for targets built as part of the current
CMake invocation (aka just one repo for non-top-level builds).
This handles the most common issues, but is not a complete fix.
Task-number: QTBUG-87702
Change-Id: If632fdf9867cec4b24b1c6136d23ee9d8b56e650
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
| |
Change-Id: I854332ef6d9ef327ece0c22bdf064dd83cb943aa
Reviewed-by: Qt Submodule Update Bot <qt_submodule_update_bot@qt-project.org>
|
|
|
|
|
|
|
| |
Change-Id: I4bb4a66b7ccca838e058962bbc297659b273c78e
Done-with: Fabian Kosmale <fabian.kosmale@qt.io>
Fixes: QTBUG-84416
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
| |
Change-Id: Id81fcbd8e6869239ad4625907819987463443d07
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
|
|
|
|
|
|
|
|
| |
-fixes qdoc warnings
Task-number: QTBUG-86102
Change-Id: I2e2a2f98d7127629bedc06612d6c6b4f7e57fb52
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Collect content of 'qmldir' file that is generated by
'qt6_add_qml_module' and 'qt6_target_qml_files' functions, instead
of write content to file immediately.
Use 'cmake_language(DEFER CALL)' to call 'configure_file' write
whole 'qmldir', when finalizing CMAKE_CURRENT_SOURCE_DIR scope.
This way a reconfiguration will not rewrite the files,
touch the timestamps, and thus needlessly rebuild.
Task-number: QTBUG-88172
Change-Id: Idca68e4ceed13d0aa7eac443e769d5677557b880
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
|
|
|
|
|
|
|
| |
So we can remove it.
Change-Id: I037373f85c696ce04c55920b41377cc9843b0da3
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
|
|
|
|
| |
Change-Id: I709c6a74dc6a3eb0cdd3e94168921274f90df4a4
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
|
|
|
|
| |
QMutableTouch/SinglePointEvent can be publicly copy constructed from their
non-mutable counterparts, make use of that.
Change-Id: I7f56a9f9649bb7726cca1eaddccfdc3f21d47554
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
|
| |
was only possible if qml_network is disabled
Pick-to: 5.15
Change-Id: If8a8addc0aa5c4c768dd7df3aa4d627f82a78059
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
|
|
|
|
|
| |
Change-Id: Iba9f99f0fcdb7692ceadaec223d82e425f1e424b
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We need to resolve the types for QML elements in two passes because only
after finishing the parsing we have the QML-declared methods and
properties available. We already need the base type before, though.
Also, there can be multiple methods of the same name. We need API to
access them.
It also turns out that the internal name of the "var" type has to be
QVariant in order to match reality. "var" properties and unnamed
arguments to JS functions are implemented as QVariant.
Change-Id: I541f11e96db72d832f4e4443d3a5d31079a56575
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
| |
Change-Id: I7c5999f339e0d6ee25cc69d48296ddd51d529036
Reviewed-by: Qt Submodule Update Bot <qt_submodule_update_bot@qt-project.org>
|
|
|
|
|
|
|
| |
Output the command line, exit status, exit code, stderr and stdout.
Change-Id: I81a813bc44b7caf4c25d9097e8fbcbc3295ac6ec
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
| |
Change-Id: I173e2ff05b3fc3bbe56df423abcbfc84bdc2a17a
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
|
|
|
|
|
|
|
| |
In this case we need to pass a pointer to the return variant itself, not
to its data.
Change-Id: I86e468f106f29e1f1be8adee9882d465fd6da533
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Upon a QWindow destroy() and show() we can get to syncAndRenderer
with sync not requested. It will be followed by a full sync+render
request afterwards, but first we need to gracefully survive that
somewhat obscure initial round (obscure because the window is fully
usable, so we get a swapchain, but then we do not sync, so there is no
QSGRenderer created)
Exhibited by tst_qquickwindow::headless. It correctly showed a warning
on all platforms and rhi backends, but was only fatal on macOS and Metal
for some reason.
Fixes: QTBUG-88513
Change-Id: I0396b648af0fd2bef2964b79a28359a7f806530d
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
|
|
|
|
|
|
|
|
| |
Scene graph changes are documented in the section further down.
Task-number: QTBUG-88152
Change-Id: I6362999e6830e05981e95af78b3d2f00b5e398e3
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
|
|
|
|
|
|
|
|
|
|
| |
QQuickItem::grabMouse() is deprecated, and cannot be used at all when
there is no current event being delivered. But we can still use
QPointingDevicePrivate::setExclusiveGrabber().
Task-number: QTBUG-86729
Change-Id: I215de471e6dc44551720bc4c766b22cdfee94423
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
|
|
|
|
| |
- The view-showing boilerplate is reduced
- Uncommented and fixed up some statements that were failing at one time
- Fixed override warnings
- Use qCDebug not qDebug
Change-Id: Ib437cc985c03776492da2502ecdb5176afadadf2
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now the boilerplate for most QML-using C++ tests can be reduced from
QQuickView window;
QByteArray errorMessage;
QVERIFY2(QQuickTest::initView(window, testFileUrl("myitems.qml"),
true, &errorMessage), errorMessage.constData());
window.show();
QVERIFY(QTest::qWaitForWindowExposed(&window));
QVERIFY(window.rootObject() != nullptr);
to
QQuickView window;
QVERIFY(QQuickTest::showView(window, testFileUrl("myitems.qml")));
The idea to dump the QML error output was nice, but the engine already
generates QWARN output like this (lines partially wrapped, URL elided for brevity):
QWARN : tst_TouchMouse::touchPointDeliveryOrder() [ 0.000 W] default unknown -
file:/...rder.qml:14:29: Cannot assign to non-existent property "pill"
Rectangle { anchors.pill: parent; color: "lightsteelblue" }
^
FAIL! : tst_TouchMouse::touchPointDeliveryOrder() 'QQuickTest::showView(window,
testFileUrl("touchpointdeliveryorder.qml"))' returned FALSE. ()
Loc: [/home/rutledge/dev/qt6/qtdeclarative/tests/auto/quick/touchmouse/tst_touchmouse.cpp(1343)]
Improves on a804f31ee2665501c1894cbae8302db181090bd5
Change-Id: I92b8e3720bb5b1d009580bb74566690ad3d5292c
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes tst_QQuickListView::touchCancel again. In this scenario, a
TouchCancel is sent, but gets turned into an UngrabMouse for delivery to
the MouseArea which is the current grabber.
We try to avoid calling QQuickWindow::mouseGrabberItem() because it's
too vague a question to ask (which mouse? or did you mean the synth-mouse
during synthesis from a touch or tablet event?); and now it acts different
anyway, because eventsInDelivery.top() is an UngrabMouse, which did not
include a pointer to the QPointingDevice until now. So now we turn
the UngrabMouse event into a QSinglePointEvent so that it's possible to
get exclusiveGrabber() and check that the grabber is not the same
Flickable. (Otherwise, the grabber that's getting ungrabbed is usually
the child receiver item sent to childMouseEventFilter().)
Task-number: QTBUG-86729
Task-number: QTBUG-74679
Change-Id: I6dfd96686bdfb54723bbe093406b6ab1f75de855
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
|
|
|
|
|
| |
Prove that we can drag multiple Flickables with multiple touchpoints now.
[ChangeLog][QtQuick][Flickable] Flickable now handles touch events directly:
you can now drag multiple Flickables with multiple touchpoints.
Fixes: QTBUG-30840
Change-Id: I0a3e58595a67f5afb4b93ad64d5280cb3fc52f7a
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
| |
Task-number: QTBUG-88169
Change-Id: Iaea3959365a580f3f8d2dd7ab2b227933e79cf59
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In QQuickWindow, we instantiate QQuickPaletteProviderPrivateBase, which
in turn instantiates its updateChildrenPalettes method, which then calls
QQuickItemPrivate::inheritPalette. However, QQIP is an incomplete type
at this point. Including qquickitemprivate_p.h would currently create a
cyclic dependency, and breaking that dependency might mean outlining
performance sensitive code.
Thus we instead (ab)use the fact that updateChildrenPalettes is virtual,
do nothing in the specialization for QQuickWindow and instead implement
the method in the same way as an override in QQuickWindowPrivate.
Task-number: QTBUG-88457
Change-Id: I49b357d7a67f1945a4d3c25e8cabd428d1454aa7
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
|
|
|
| |
Two cases fail due to attempting to query the MTLRenderCommandEncoder
in a state where QRhi::beginPass() was not yet called. This is invalid
and we should not test for it either.
Change-Id: Ieaaaabd275db68be98365fb76a39f30a635d3543
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
|
|
|
|
|
|
| |
Task-number: QTBUG-84416
Change-Id: I79048233041802fe74e28b07def5ca0a3181c358
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
|
|
| |
This is a single char16_t, not an array of them.
Pick-to: 5.15
Change-Id: I55d23ebb5f2abebd43cd4160a75d373706392ddf
Reviewed-by: Fabian Kosmale <fabian.kosmale@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>
|
|
|
|
|
| |
Change-Id: Ia7f63103a32fbdd0f80d77483893ee458b9fdd6e
Reviewed-by: Qt Submodule Update Bot <qt_submodule_update_bot@qt-project.org>
|