| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
Fixes: QTBUG-87150
Change-Id: If99a06a07892bdfef7b6b1e8fa737480750992fe
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
(cherry picked from commit 56f428c360191230b571969a2651e85380030afa)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There was a mismatch for the cache key: sometimes using the original url
as specified in the QML code, sometimes using the resolved url (which has,
for example, a relative path expanded to absolute). Change this to be
consistent.
Fixes: QTBUG-88673
Change-Id: I201750716d3ba6dbe73a4799ac56f26f9b8ec820
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
(cherry picked from commit f95b99902fae6e53a9da5fbccb6e1616299fb3bf)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
|
|
|
|
|
|
|
|
|
|
| |
Needed in order to allow for the declarative registration of classes implementing
interfaces.
Fixes: QTBUG-88623
Change-Id: Id9c1ae92774dd9c316ceaa737cb48ef28f56545c
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
(cherry picked from commit 87533900738d65ad278722b292852c998e987c10)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
lineCount is not reset when replacing a multi-line QML Text 'text'
property with an "" empty string. Also, the lineCountChanged signal is
not emitted
Task-number: QTBUG-84458
Change-Id: Ic3c02e6a90e6675eadbaafc6af6ab0356ee98123
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
(cherry picked from commit ae1b9c6d94001411efeef600e22638906e0fa990)
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
|
|
|
|
|
|
|
|
|
|
| |
Otherwise the generated type registrations .cpp file will not be able
to include the sources.
Change-Id: I7821c7674b4341546da2fc49e584bf10cc60b46f
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
(cherry picked from commit 06c31f386f8664343debd219a522a8897df0f3ec)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_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: Id7193f64093c20bb798b6bc6fbf87f1ce41364d7
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
(cherry picked from commit 220cbb6dab74b7ee924b44d89f657cfc86f9e8ec)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While the parent class (QWindow) has that property, QDoc does not
allow documenting properties from base classes. The documentation
for QQuickWindow::transientParent includes QML-specific information,
so use QDOC_PROPERTY macro in the header file to make the property
documentation visible.
Change-Id: Ib281c776717e09e6929420c6173a520613356d91
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
(cherry picked from commit 29a32e17e1a11af8312be269c6b8085385524155)
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>
|