| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
The test fails for MinGW in the CI for unknown reasons. Output
the error string on failure.
Change-Id: I96415c9d5753f9013be22b55884175fda6604130
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
(cherry picked from commit cffae9109eecc838a5b107cc58f43637a3c3279e)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
|
|
|
|
|
|
|
|
| |
Use new qChecksum overload
Change-Id: Ia2990e3491ee0c4029bba8e645109b03ac5001db
Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
(cherry picked from commit 5aec31639c503bfe00249c65a13d0f34f93edcc1)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
|
|
|
|
|
|
|
|
| |
The test fails for MinGW in the CI for unknown reasons.
Change-Id: I20199704a9c810499551b8952375926902a75aa0
Reviewed-by: Tony Sarajärvi <tony.sarajarvi@qt.io>
(cherry picked from commit 3c049c7a996d156c2faf9a257e209fe8b23d1151)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
|
|
|
|
|
|
|
|
|
|
| |
pro2cmake did not convert the QTEST_FUNCTION_TIMEOUT environment
variable. As a result, when the test runs for more than 300s, it gets
killed by the watchdog.
Change-Id: I370d2c1b7a129c41d690d41e84f0a51810d37160
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
(cherry picked from commit d5ac54da624dbaebc865c8243a5e1c33d5e1c7ba)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the target of a proxy was extensible, we did not set the
iteratorTarget to its correct value, and thus the ForInIteratorObject
would not be usable.
Fixes: QTBUG-86323
Change-Id: Id1924ac4087bab38c006b8eba92b619b79d36b7a
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
(cherry picked from commit dd740d6b3469448dc1fd31c1742781e923e9f274)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Replace the dubious function eventLoopWait() by
QThread::msleep() since it causes a warnings flood when using MinGW:
tst_qqmltimer::stopWhenEventPosted() QEventDispatcherWin32::wakeUp: Failed to post a message (Not enough quota is available to process this command.)
tst_qqmltimer::stopWhenEventPosted() QEventDispatcherWin32::wakeUp: Failed to post a message (Not enough quota is available to process this command.)
tst_qqmltimer::stopWhenEventPosted() QEventDispatcherWin32::wakeUp: Failed to post a message (Not enough quota is available to process this command.)
tst_qqmltimer::stopWhenEventPosted() QEventDispatcherWin32::wakeUp: Failed to post a message (Not enough quota is available to process this command.)
tst_qqmltimer::stopWhenEventPosted() QEventDispatcherWin32::wakeUp: Failed to post a message (Not enough quota is available to process this command.)
tst_qqmltimer::stopWhenEventPosted() QEventDispatcherWin32::wakeUp: Failed to post a message (Not enough quota is available to process this command.)
tst_qqmltimer::stopWhenEventPosted() QEventDispatcherWin32::wakeUp: Failed to post a message (Not enough quota is available to process this command.)
tst_qqmltimer::stopWhenEventPosted() QEventDispatcherWin32::wakeUp: Failed to post a message (Not enough quota is available to process this command.)
Change-Id: I161d1d025f79560b21aaaeb510e4956eba54bdea
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
(cherry picked from commit d9a6c45a06f23cdd896e5360cc3cd3608fea4c3e)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
|
|
|
|
|
|
|
|
|
|
| |
Remove import sorting due to the fact that sorting imports can break code.
[ChangeLog][QML Tooling][qmlformat] Remove import sorting and the (now obsolete) -n parameter to disable it
Fixes: QTBUG-89295
Change-Id: I5ff13d0ae3c715db7645b412152aadb31811ce5a
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
(cherry picked from commit cf3e0559b01b249a6ec06f8826e8e05aca1301ec)
|
|
|
|
|
|
|
|
|
|
| |
And fix up some incorrect qmake project files
Change-Id: Ia6d27ac68195635021fe7c4a5f06386a60f3f323
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
(cherry picked from commit c1c4a874e31ba108a3600fbbb0aee7fc0bf34601)
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
|
|
|
|
|
|
|
|
|
|
|
| |
Makes the code typesafe, simplifies the data structures, and fixes
a compiler warning from implicit conversion from/to int.
Fixes: QTBUG-89356
Change-Id: I52d834811fa7325788fc71ea20f78b4afe3fdb86
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
(cherry picked from commit 8257cf75c68bd3d2a2af0cd8260e3cc96f5d0df4)
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Usually libraries get a lib prefix when using MinGW but plugins are expected
to not have a prefix, causing the plugin to not load properly.
This change fixes this by using the MODULE keyword.
Fixes: QTBUG-89187
Change-Id: Icd543015805a8157d59c20e86134421911930ea1
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
(cherry picked from commit 323cdf820c723660f3c67c3fd583f0b28c8d80a2)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
|
|
|
|
|
|
|
|
|
|
| |
By showing the tableview, we can be sure that headerviews will be
visible even in the syncView has an empty model.
Fixes: QTBUG-87526
Change-Id: I68c8b119122a2d2f88c2afbeb2d6c71a83a3ce33
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
(cherry picked from commit 27c254203b3e7dd6d3a4445feb205fbe98c32d30)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
|
|
|
|
|
|
| |
Change-Id: Icf31fbe473e5b0659cfe09d5bef8652c22a2b1ce
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
(cherry picked from commit 355ff606853d885b9ad7c6e1549c3f25bfa48a2c)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
We set QProperty bindings up in the wrong way: Parent components would
overwrite their child component's binding. This patch reverses the
order, fixing the bug.
Task-number: QTBUG-87153
Change-Id: I3e90d1d14a41a7c5c337745f1453484d360a3979
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
(cherry picked from commit 96e321bc5cf3c1a6d52374a6f4070a438032b08d)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
Fixes: QTBUG-75223
Change-Id: Ie4e22c87be0af9aa3ff0146067b7705949b15c40
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit 1e1674849a89db54cdbcc4e995300e3ec1624c3a)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
|
|
|
|
|
|
| |
Change-Id: Id12b484634d66d3f46c7905e233beb6cd5897979
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
(cherry picked from commit 468888cf08c181366df94627522b9e282d364b81)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
|
|
|
|
|
|
|
|
|
| |
The lancelot test has shown sensitivity to timing on some platforms;
this change improves stability there.
Change-Id: I9c8519423635fc22724d96e0a09bcdd1dd0a0102
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
(cherry picked from commit 473ce18934d067dd3fcfd5ac4c1e8d54235497c5)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Property pointer p needs to be checked for nullptr value in
QV4::ProxyObject::virtualGetOwnProperty(). This can happen when calling
hasOwnProperty() or propertyIsEnumerable().
Fixes: QTBUG-88786
Change-Id: I43da58fed4d8656f9187213f7317f17398739e34
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
(cherry picked from commit 9b321a34490cd17c0eb043b69bd7c9d8d8f513d5)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
|
|
|
|
|
|
|
|
| |
Fixes: QTBUG-88761
Change-Id: Ia5df65a4a09a7554a7d0cca4533f766cb5abe97b
Reviewed-by: Miikka Heikkinen <miikka.heikkinen@qt.io>
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
(cherry picked from commit bbb6298204b95f049c8a177365125247ba49dba3)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
|
|
|
|
|
|
|
|
|
|
| |
While dev/6.0 uses CMake as a main build system, just in case we will run qmake tests in CI, make sure it works
Leftover of 3a5617dc45e281552b9c1f7a04f0561b8fa14d94
Change-Id: I32efba9140206f0dfb2e8458fe5c6a2d4d51dbc7
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
(cherry picked from commit fc4d721e5fdeeced3ab1ca0eb6803c58a22a8763)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The delegate items are destroyed through an event loop by a call to a
deleteLater(). This, however, doesn't work when the application is
in the process of exiting and the event loop is already closed (i.e.
we're in a stack unwinding part that starts after app.exec())
Combat this situation by setting a parent of the to-be-deleted object
to some QObject that will be destroyed e.g. QCoreApplication::instance()
before the program finishes. As QObjects clean their children on
destruction, this will make sure that we cleanup the previously leaking
thing regardless of the event loop
Added a test to check that delegates are destroyed (as a separate binary
due to differences in main() function)
Fixes: QTBUG-87228
Change-Id: I59066603b77497fe4fd8d051798c3e4b47c119f0
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
(cherry picked from commit 3a5617dc45e281552b9c1f7a04f0561b8fa14d94)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
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>
(cherry picked from commit c5c05498a7e79c1868551192921a42236ecbf5f8)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
Task-number: QTBUG-86729
Change-Id: I5514dc1b49a0b47276c41264e18f6a541bc2a3f0
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
(cherry picked from commit e94eeb48b5a7f6a53ff9e48ffc216113852bccf4)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
Task-number: QTBUG-66360
Task-number: QTBUG-86729
Change-Id: I132a8c5d1878769481b8afcc62ba237b4498b069
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit d15f6e0b237107d176a9790da609ff72ce3111f3)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
Task-number: QTBUG-86729
Change-Id: I7ad0d3f30cb5fee15fe83183d62ee10a020c14df
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
(cherry picked from commit d0733d14063bbe62082b581599e78e312d3008be)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
|
|
|
|
|
|
|
|
|
|
| |
The bit flags in QAccessible::State are unsigned, numeric literals are
signed, resulting in compiler warnings when comparing. Instead of
QCOMPARE'ing bitflags that are used for booleans, use QVERIFY.
Change-Id: I9fd6906a8c1c1e356f8e6c5b36d40f6c41590ee8
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
(cherry picked from commit 22e13d41b0e8085b25b669eb7d23744252f2c117)
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
| |
Task-number: QTBUG-88650
Change-Id: I2cac1b8ca7ec8ed8401206cf761244b3f483ca14
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@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: I4bb4a66b7ccca838e058962bbc297659b273c78e
Done-with: Fabian Kosmale <fabian.kosmale@qt.io>
Fixes: QTBUG-84416
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
| |
Change-Id: I709c6a74dc6a3eb0cdd3e94168921274f90df4a4
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
|
| |
Output the command line, exit status, exit code, stderr and stdout.
Change-Id: I81a813bc44b7caf4c25d9097e8fbcbc3295ac6ec
Reviewed-by: Fabian Kosmale <fabian.kosmale@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>
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
| |
Flickable moves after taking over the grab, but this test was failing
anyway. Might as well check for everything in one loop of move events.
Change-Id: Iafa21cdfb88df36337e4350934d3bf569418bdca
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
| |
Task-number: QTBUG-88541
Change-Id: I35b3f99c4268b6615da373f90b53b6ca6ef16fce
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Copying/assigning polymorphic types is a code smell, use separate
instances instead in the tests. Those should perhaps be rewritten
to use a data driven testing approach, there's a lot of code
repetition.
In the test API implementation, first evaluate the parameters for
the event, then construct the event once with the correct values.
Change-Id: I2572772698cb0204f5ff950741b9fe3805fae15d
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
|
|
|
|
|
|
|
| |
Prepare for upcoming changes in qtbase.
Change-Id: I592fe857dde13ce570f1525b5f327a07773be123
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
|
|
|
|
|
|
|
|
| |
All other type names are actual C++ type names. Also, correctly resolve
qreal if its type is overridden at configure time.
Change-Id: Ia2a1b4309f94e8c72461ee69005b1bdee6337370
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|