| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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
Pick-to: 6.0
Pick-to: 6.0.0
Task-number: QTBUG-86729
Change-Id: Ieb1af38c118dadf8cdf8ae19f92002207d71d5b5
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@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>
|
|
|
|
|
|
| |
Task-number: QTBUG-86729
Change-Id: I35dc7ac91d2507a229dc1dde19f380e7111a4757
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
| |
tst_qqflickable::nestedStopAtBounds, nestedSliderUsingTouch
tst_QQuickMouseArea::preventStealing, nestedFlickableStopAtBounds
tst_QQuickMultiPointTouchArea::inFlickable2, inFlickableWithPressDelay
tst_QQuickPathView::nestedinFlickable, touchButtonOnFlickable, touchGrabCausesMouseUngrab
tst_qqmlpropertycache::derivedGadgetMethod
Task-number: QTBUG-86729
Change-Id: Ie11a50c25f90fde2636b05a72f51640643b33dec
Reviewed-by: Fabian Kosmale <fabian.kosmale@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>
|
|\
| |
| |
| |
| |
| |
| | |
Conflicts:
tests/auto/quick/qquickmousearea/BLACKLIST
Change-Id: I3de2c6377d57f5f9204d2cfc688d50a7a0b4150c
|
| |
| |
| |
| |
| |
| | |
Task-number: QTBUG-82282
Change-Id: I4794bea023f45b3bdac2f19a68550c7116a49fa2
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|\|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This partially reverts commit 51e02fdc02c3cc2dbf9d2ba0b3fb709a6cd4e32e.
Task-number: QTBUG-78153
Change-Id: I421fdc3acefd11cabfc192eb06c3cd92c0e76149
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|/
|
|
|
|
| |
Task-number: QTBUG-82043
Change-Id: I1490ef6875e46cee5c23a205ba19dc150e52ea18
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
| |
Fixes: QTBUG-78153
Change-Id: Ib8ab2ace4e43f5020059b964951ed11c0f7fc4bd
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
| |
Task-number: QTBUG-78153
Change-Id: Ifdca53d4eed452067ba7f75ae0b3e74cf2027895
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It seems that qtestlib has never really supported mouse state
handling for multiple buttons (see QTBUG-64030). And the current
implementation of this test relied on QGuiApplication to generate
mouse releases when necessary. Since a37785ec7638e7485112b87dd7e767881fecc114,
qtestlib does not rely on QGuiApplication to deduce mouse button
state, but requires explicit mouse press/release events via
QTest::mouse* APIs, thus causing this auto test to fail.
Refactor the auto test to use QTest::mouse* APIs. This change depends
on a fix for QTBUG-64030.
Task-number: QTBUG-63786
Change-Id: Id24526714ec9716a0126e8288e5e8974074ebc9e
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
Direct pushed since the dev branch was deadlocked.
Signed-off by Lars Knoll.
Task-number: QTBUG-63786
Change-Id: I37a426b5c12bda9da8880065821ed9df099d7de1
|