qiurui
/
qtdeclarative
mirror of https://github.com/qt/qtdeclarative.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
qtdeclarative/tests/auto/quick/touchmouse/tst_touchmouse.cpp

1660 lines
64 KiB
C++
Raw Normal View History

Use SPDX license identifiers Replace the current license disclaimer in files by a SPDX-License-Identifier. Files that have to be modified by hand are modified. License files are organized under LICENSES directory. Pick-to: 6.4 Task-number: QTBUG-67283 Change-Id: I63563bbeb6f60f89d2c99660400dca7fab78a294 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2022-05-13 13:12:05 +00:00
// Copyright (C) 2020 The Qt Company Ltd.
// SPDX-License-Identifier: LicenseRef-Qt-Commercial OR GPL-3.0-only WITH Qt-GPL-exception-1.0
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
#include <QtTest/QtTest>
Amend TouchMouse::buttonOnDelayedPressFlickable to test delayed tap This test is for Flickable with pressDelay set to a testable timeout value. For some reason it only checked trying to flick before the press delay is over, or holding and waiting for the press delay to expire. But if the user taps a child MouseArea before the press delay expires (neither moving nor waiting), at the moment of release it's supposed to send the delayed press and then the release, so that the MouseArea gets "clicked" almost as if there was no delay. Lack of test coverage allowed a regression in this functionality for 2 minor versions: 5.10 and 5.11. Task-number: QTBUG-61144 Task-number: QTBUG-69059 Change-Id: I0d8867587e6877359c41ec5fc3a5cdd17447d0b8 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2018-10-02 07:34:05 +00:00
#include <QDebug>
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
#include <QtGui/qstylehints.h>
touchmouse autotest: add debug operator for the test-specific Event type It's nice to be able to do qDebug() << eventItem->eventList when troubleshooting behavior in case of test failure. Change-Id: I2b50d5b092a0c9eb4eab3105be66a36aedf871bb Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2017-05-11 11:47:58 +00:00
#include <private/qdebug_p.h>
Remove QQuickPointerEvent etc.; deliver QPointerEvents directly QEventPoint does not have an accessor to get the QPointerEvent that it came from, because that's inconsistent with the idea that QPointerEvent instances are temporary, stack-allocated and movable (the pointer would often be wrong or null, therefore could not be relied upon). So most functions that worked directly with QQuickEventPoint before (which fortunately are still private API) now need to receive the QPointerEvent too, which we choose to pass by pointer. QEventPoint is always passed by reference (const where possible) to be consistent with functions in QPointerEvent that take QEventPoint by reference. QEventPoint::velocity() should be always in scene coordinates now, which saves us the trouble of transforming it to each item's coordinate system during delivery, but means that it will need to be done in handlers or applications sometimes. If we were going to transform it, it would be important to also store the sceneVelocity separately in QEventPoint so that the transformation could be done repeatedly for different items. Task-number: QTBUG-72173 Change-Id: I7ee164d2e6893c4e407fb7d579c75aa32843933a Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
2020-07-23 11:56:26 +00:00
#include <QtGui/private/qpointingdevice_p.h>
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
#include <QtQuick/qquickview.h>
#include <QtQuick/qquickitem.h>
Keep track of grabbing inside QQuickEventPoint With this we can get rid of "itemForTouchPointId" which kept track of the individual grabbing of touch points. The new approach allows big cleanups and makes understanding the code easier. Change-Id: I19f7cda1b430e088ada707b2e75d97ca8dbadcc5 Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
2016-07-24 21:15:31 +00:00
#include <QtQuick/private/qquickevents_p_p.h>
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
#include <QtQuick/private/qquickmousearea_p.h>
#include <QtQuick/private/qquickmultipointtoucharea_p.h>
#include <QtQuick/private/qquickpincharea_p.h>
#include <QtQuick/private/qquickflickable_p.h>
Keep track of grabbing inside QQuickEventPoint With this we can get rid of "itemForTouchPointId" which kept track of the individual grabbing of touch points. The new approach allows big cleanups and makes understanding the code easier. Change-Id: I19f7cda1b430e088ada707b2e75d97ca8dbadcc5 Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
2016-07-24 21:15:31 +00:00
#include <QtQuick/private/qquickwindow_p.h>
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
#include <QtQml/qqmlengine.h>
#include <QtQml/qqmlproperty.h>
Consolidate test helpers into private libraries Previously each test would include and build sources from the shared folder. Now we make those sources a library, build it once, then have each test link to it instead. We also take the opportunity to move some helpers that qtquickcontrols2 had added into the quicktestutils library where it makes sense, and for the helpers that don't make sense to be there, move them into quickcontrolstestutils. We add the libraries to src/ so that they are internal modules built as part of Qt, rather than tests. That way we can use them in a standalone test outside of qtdeclarative. Task-number: QTBUG-95621 Pick-to: 6.2 Change-Id: I0a2ab3976fdbff2e4414df7bdc0808f16453b80a Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
2021-08-06 10:27:35 +00:00
#include <QtQuickTestUtils/private/qmlutils_p.h>
#include <QtQuickTestUtils/private/viewtestutils_p.h>
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
Amend TouchMouse::buttonOnDelayedPressFlickable to test delayed tap This test is for Flickable with pressDelay set to a testable timeout value. For some reason it only checked trying to flick before the press delay is over, or holding and waiting for the press delay to expire. But if the user taps a child MouseArea before the press delay expires (neither moving nor waiting), at the moment of release it's supposed to send the delayed press and then the release, so that the MouseArea gets "clicked" almost as if there was no delay. Lack of test coverage allowed a regression in this functionality for 2 minor versions: 5.10 and 5.11. Task-number: QTBUG-61144 Task-number: QTBUG-69059 Change-Id: I0d8867587e6877359c41ec5fc3a5cdd17447d0b8 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2018-10-02 07:34:05 +00:00
Q_LOGGING_CATEGORY(lcTests, "qt.quick.tests")
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
struct Event
{
Event(QEvent::Type t, QPoint mouse, QPoint global)
:type(t), mousePos(mouse), mousePosGlobal(global)
{}
Remove QQuickPointerEvent etc.; deliver QPointerEvents directly QEventPoint does not have an accessor to get the QPointerEvent that it came from, because that's inconsistent with the idea that QPointerEvent instances are temporary, stack-allocated and movable (the pointer would often be wrong or null, therefore could not be relied upon). So most functions that worked directly with QQuickEventPoint before (which fortunately are still private API) now need to receive the QPointerEvent too, which we choose to pass by pointer. QEventPoint is always passed by reference (const where possible) to be consistent with functions in QPointerEvent that take QEventPoint by reference. QEventPoint::velocity() should be always in scene coordinates now, which saves us the trouble of transforming it to each item's coordinate system during delivery, but means that it will need to be done in handlers or applications sometimes. If we were going to transform it, it would be important to also store the sceneVelocity separately in QEventPoint so that the transformation could be done repeatedly for different items. Task-number: QTBUG-72173 Change-Id: I7ee164d2e6893c4e407fb7d579c75aa32843933a Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
2020-07-23 11:56:26 +00:00
Event(QEvent::Type t, const QList<QEventPoint> &touch)
:type(t)
{
for (auto &tp : touch)
points << tp;
}
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
QEvent::Type type;
QPoint mousePos;
QPoint mousePosGlobal;
Replace QTouchEvent::TouchPoint with QEventPoint It's a cosmetic change at this time, because we have declared using TouchPoint = QEventPoint; Also replace Qt::TouchPointState enum with QEventPoint::State. Task-number: QTBUG-72173 Change-Id: Ife017aa98801c28abc6cccd106f47a95421549de Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
2020-07-13 11:40:04 +00:00
QList<QEventPoint> points;
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
};
touchmouse autotest: add debug operator for the test-specific Event type It's nice to be able to do qDebug() << eventItem->eventList when troubleshooting behavior in case of test failure. Change-Id: I2b50d5b092a0c9eb4eab3105be66a36aedf871bb Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2017-05-11 11:47:58 +00:00
#ifndef QT_NO_DEBUG_STREAM
QDebug operator<<(QDebug dbg, const struct Event &event) {
QDebugStateSaver saver(dbg);
dbg.nospace();
dbg << "Event(";
QtDebugUtils::formatQEnum(dbg, event.type);
if (event.points.isEmpty())
dbg << " @ " << event.mousePos << " global " << event.mousePosGlobal;
else
Port from container::count() and length() to size() This is a semantic patch using ClangTidyTransformator as in qtbase/df9d882d41b741fef7c5beeddb0abe9d904443d8: auto QtContainerClass = anyOf( expr(hasType(cxxRecordDecl(isSameOrDerivedFrom(hasAnyName(classes))))).bind(o), expr(hasType(namedDecl(hasAnyName(<classes>)))).bind(o)); makeRule(cxxMemberCallExpr(on(QtContainerClass), callee(cxxMethodDecl(hasAnyName({"count", "length"), parameterCountIs(0))))), changeTo(cat(access(o, cat("size"), "()"))), cat("use 'size()' instead of 'count()/length()'")) a.k.a qt-port-to-std-compatible-api with config Scope: 'Container', with the extended set of container classes recognized. Change-Id: Idb1f75dfe2323bd1d9e8b4d58d54f1b4b80c7ed7 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
2022-10-05 05:29:16 +00:00
dbg << ", " << event.points.size() << " touchpoints: " << event.points;
touchmouse autotest: add debug operator for the test-specific Event type It's nice to be able to do qDebug() << eventItem->eventList when troubleshooting behavior in case of test failure. Change-Id: I2b50d5b092a0c9eb4eab3105be66a36aedf871bb Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2017-05-11 11:47:58 +00:00
dbg << ')';
return dbg;
}
#endif
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
class EventItem : public QQuickItem
{
Q_OBJECT
Test touch point delivery order Change-Id: I9b93eda0378e10bbcc274998d58f5f5ec62bb1b1 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2016-08-01 12:13:20 +00:00
Q_SIGNALS:
void onTouchEvent(QQuickItem *receiver);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
public:
use nullptr consistently (clang-tidy) From now on we prefer nullptr instead of 0 to clarify cases where we are assigning or testing a pointer rather than a numeric zero. Also, replaced cases where 0 was passed as Qt::KeyboardModifiers with Qt::NoModifier (clang-tidy replaced them with nullptr, which waas wrong, so it was just as well to make the tests more readable rather than to revert those lines). Change-Id: I4735d35e4d9f42db5216862ce091429eadc6e65d Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2018-02-21 09:41:54 +00:00
EventItem(QQuickItem *parent = nullptr)
init variables where they are declared when possible (clang-tidy) clang-tidy -p compile_commands.json $file -checks='-*,modernize-use-default-member-init,readability-redundant-member-init' -config='{CheckOptions: [{key: modernize-use-default-member-init.UseAssignment, value: "1"}]}' -header-filter='qtdeclarative' -fix Change-Id: I705f3235ff129ba68b0d8dad54a083e29fcead5f Reviewed-by: Johan Helsing <johan.helsing@qt.io>
2018-02-21 10:52:59 +00:00
: QQuickItem(parent)
Fix TouchMouse test: accept button That the EventItem would get an event is a bug in the current event handling, there is no reason for it to receive anything when it doesn't accept mouse/touch. Change-Id: I4079e6cb396cc1913f795015dcc7839ca79edb70 Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
2016-07-31 19:27:58 +00:00
{
setAcceptedMouseButtons(Qt::LeftButton);
}
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
void touchEvent(QTouchEvent *event) override
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
{
Remove QQuickPointerEvent etc.; deliver QPointerEvents directly QEventPoint does not have an accessor to get the QPointerEvent that it came from, because that's inconsistent with the idea that QPointerEvent instances are temporary, stack-allocated and movable (the pointer would often be wrong or null, therefore could not be relied upon). So most functions that worked directly with QQuickEventPoint before (which fortunately are still private API) now need to receive the QPointerEvent too, which we choose to pass by pointer. QEventPoint is always passed by reference (const where possible) to be consistent with functions in QPointerEvent that take QEventPoint by reference. QEventPoint::velocity() should be always in scene coordinates now, which saves us the trouble of transforming it to each item's coordinate system during delivery, but means that it will need to be done in handlers or applications sometimes. If we were going to transform it, it would be important to also store the sceneVelocity separately in QEventPoint so that the transformation could be done repeatedly for different items. Task-number: QTBUG-72173 Change-Id: I7ee164d2e6893c4e407fb7d579c75aa32843933a Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
2020-07-23 11:56:26 +00:00
qCDebug(lcTests) << event << "accepting?" << acceptTouch;
eventList.append(Event(event->type(), event->points()));
Q_ASSERT(event->pointCount() > 0);
point0 = event->point(0).id();
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
event->setAccepted(acceptTouch);
Test touch point delivery order Change-Id: I9b93eda0378e10bbcc274998d58f5f5ec62bb1b1 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2016-08-01 12:13:20 +00:00
emit onTouchEvent(this);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
}
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
void mousePressEvent(QMouseEvent *event) override
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
{
Remove QQuickPointerEvent etc.; deliver QPointerEvents directly QEventPoint does not have an accessor to get the QPointerEvent that it came from, because that's inconsistent with the idea that QPointerEvent instances are temporary, stack-allocated and movable (the pointer would often be wrong or null, therefore could not be relied upon). So most functions that worked directly with QQuickEventPoint before (which fortunately are still private API) now need to receive the QPointerEvent too, which we choose to pass by pointer. QEventPoint is always passed by reference (const where possible) to be consistent with functions in QPointerEvent that take QEventPoint by reference. QEventPoint::velocity() should be always in scene coordinates now, which saves us the trouble of transforming it to each item's coordinate system during delivery, but means that it will need to be done in handlers or applications sometimes. If we were going to transform it, it would be important to also store the sceneVelocity separately in QEventPoint so that the transformation could be done repeatedly for different items. Task-number: QTBUG-72173 Change-Id: I7ee164d2e6893c4e407fb7d579c75aa32843933a Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
2020-07-23 11:56:26 +00:00
qCDebug(lcTests) << event << "accepting?" << acceptMouse;
Replace calls to deprecated QEvent accessor functions Several event accessors were deprecated in qtbase/24e52c10deedbaef833c0e2c3ee7bee03eacc4f5. Replacements were generated by clazy using the new qevent-accessors check: $ export CLAZY_CHECKS=qevent-accessors $ export CLAZY_EXPORT_FIXES=1 $ ../qt6/configure -platform linux-clang -developer-build -debug -no-optimize-debug -opensource -confirm-license -no-pch QMAKE_CXX=clazy $ make $ cd ../../qt6/qtdeclarative $ find . -name "*.clazy.yaml" $ clang-apply-replacements . Task-number: QTBUG-20885 Task-number: QTBUG-84775 Change-Id: I1be5819506fd5039e86b4494223acbe193e6b0c9 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2020-06-08 07:21:58 +00:00
eventList.append(Event(event->type(), event->position().toPoint(), event->globalPosition().toPoint()));
Remove QQuickPointerEvent etc.; deliver QPointerEvents directly QEventPoint does not have an accessor to get the QPointerEvent that it came from, because that's inconsistent with the idea that QPointerEvent instances are temporary, stack-allocated and movable (the pointer would often be wrong or null, therefore could not be relied upon). So most functions that worked directly with QQuickEventPoint before (which fortunately are still private API) now need to receive the QPointerEvent too, which we choose to pass by pointer. QEventPoint is always passed by reference (const where possible) to be consistent with functions in QPointerEvent that take QEventPoint by reference. QEventPoint::velocity() should be always in scene coordinates now, which saves us the trouble of transforming it to each item's coordinate system during delivery, but means that it will need to be done in handlers or applications sometimes. If we were going to transform it, it would be important to also store the sceneVelocity separately in QEventPoint so that the transformation could be done repeatedly for different items. Task-number: QTBUG-72173 Change-Id: I7ee164d2e6893c4e407fb7d579c75aa32843933a Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
2020-07-23 11:56:26 +00:00
mouseGrabber = event->exclusiveGrabber(event->points().first());
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
event->setAccepted(acceptMouse);
}
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
void mouseMoveEvent(QMouseEvent *event) override
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
{
Remove QQuickPointerEvent etc.; deliver QPointerEvents directly QEventPoint does not have an accessor to get the QPointerEvent that it came from, because that's inconsistent with the idea that QPointerEvent instances are temporary, stack-allocated and movable (the pointer would often be wrong or null, therefore could not be relied upon). So most functions that worked directly with QQuickEventPoint before (which fortunately are still private API) now need to receive the QPointerEvent too, which we choose to pass by pointer. QEventPoint is always passed by reference (const where possible) to be consistent with functions in QPointerEvent that take QEventPoint by reference. QEventPoint::velocity() should be always in scene coordinates now, which saves us the trouble of transforming it to each item's coordinate system during delivery, but means that it will need to be done in handlers or applications sometimes. If we were going to transform it, it would be important to also store the sceneVelocity separately in QEventPoint so that the transformation could be done repeatedly for different items. Task-number: QTBUG-72173 Change-Id: I7ee164d2e6893c4e407fb7d579c75aa32843933a Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
2020-07-23 11:56:26 +00:00
qCDebug(lcTests) << event << "accepting?" << acceptMouse;
Replace calls to deprecated QEvent accessor functions Several event accessors were deprecated in qtbase/24e52c10deedbaef833c0e2c3ee7bee03eacc4f5. Replacements were generated by clazy using the new qevent-accessors check: $ export CLAZY_CHECKS=qevent-accessors $ export CLAZY_EXPORT_FIXES=1 $ ../qt6/configure -platform linux-clang -developer-build -debug -no-optimize-debug -opensource -confirm-license -no-pch QMAKE_CXX=clazy $ make $ cd ../../qt6/qtdeclarative $ find . -name "*.clazy.yaml" $ clang-apply-replacements . Task-number: QTBUG-20885 Task-number: QTBUG-84775 Change-Id: I1be5819506fd5039e86b4494223acbe193e6b0c9 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2020-06-08 07:21:58 +00:00
eventList.append(Event(event->type(), event->position().toPoint(), event->globalPosition().toPoint()));
Remove QQuickPointerEvent etc.; deliver QPointerEvents directly QEventPoint does not have an accessor to get the QPointerEvent that it came from, because that's inconsistent with the idea that QPointerEvent instances are temporary, stack-allocated and movable (the pointer would often be wrong or null, therefore could not be relied upon). So most functions that worked directly with QQuickEventPoint before (which fortunately are still private API) now need to receive the QPointerEvent too, which we choose to pass by pointer. QEventPoint is always passed by reference (const where possible) to be consistent with functions in QPointerEvent that take QEventPoint by reference. QEventPoint::velocity() should be always in scene coordinates now, which saves us the trouble of transforming it to each item's coordinate system during delivery, but means that it will need to be done in handlers or applications sometimes. If we were going to transform it, it would be important to also store the sceneVelocity separately in QEventPoint so that the transformation could be done repeatedly for different items. Task-number: QTBUG-72173 Change-Id: I7ee164d2e6893c4e407fb7d579c75aa32843933a Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
2020-07-23 11:56:26 +00:00
mouseGrabber = event->exclusiveGrabber(event->points().first());
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
event->setAccepted(acceptMouse);
}
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
void mouseReleaseEvent(QMouseEvent *event) override
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
{
Remove QQuickPointerEvent etc.; deliver QPointerEvents directly QEventPoint does not have an accessor to get the QPointerEvent that it came from, because that's inconsistent with the idea that QPointerEvent instances are temporary, stack-allocated and movable (the pointer would often be wrong or null, therefore could not be relied upon). So most functions that worked directly with QQuickEventPoint before (which fortunately are still private API) now need to receive the QPointerEvent too, which we choose to pass by pointer. QEventPoint is always passed by reference (const where possible) to be consistent with functions in QPointerEvent that take QEventPoint by reference. QEventPoint::velocity() should be always in scene coordinates now, which saves us the trouble of transforming it to each item's coordinate system during delivery, but means that it will need to be done in handlers or applications sometimes. If we were going to transform it, it would be important to also store the sceneVelocity separately in QEventPoint so that the transformation could be done repeatedly for different items. Task-number: QTBUG-72173 Change-Id: I7ee164d2e6893c4e407fb7d579c75aa32843933a Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
2020-07-23 11:56:26 +00:00
qCDebug(lcTests) << event << "accepting?" << acceptMouse;
Replace calls to deprecated QEvent accessor functions Several event accessors were deprecated in qtbase/24e52c10deedbaef833c0e2c3ee7bee03eacc4f5. Replacements were generated by clazy using the new qevent-accessors check: $ export CLAZY_CHECKS=qevent-accessors $ export CLAZY_EXPORT_FIXES=1 $ ../qt6/configure -platform linux-clang -developer-build -debug -no-optimize-debug -opensource -confirm-license -no-pch QMAKE_CXX=clazy $ make $ cd ../../qt6/qtdeclarative $ find . -name "*.clazy.yaml" $ clang-apply-replacements . Task-number: QTBUG-20885 Task-number: QTBUG-84775 Change-Id: I1be5819506fd5039e86b4494223acbe193e6b0c9 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2020-06-08 07:21:58 +00:00
eventList.append(Event(event->type(), event->position().toPoint(), event->globalPosition().toPoint()));
Remove QQuickPointerEvent etc.; deliver QPointerEvents directly QEventPoint does not have an accessor to get the QPointerEvent that it came from, because that's inconsistent with the idea that QPointerEvent instances are temporary, stack-allocated and movable (the pointer would often be wrong or null, therefore could not be relied upon). So most functions that worked directly with QQuickEventPoint before (which fortunately are still private API) now need to receive the QPointerEvent too, which we choose to pass by pointer. QEventPoint is always passed by reference (const where possible) to be consistent with functions in QPointerEvent that take QEventPoint by reference. QEventPoint::velocity() should be always in scene coordinates now, which saves us the trouble of transforming it to each item's coordinate system during delivery, but means that it will need to be done in handlers or applications sometimes. If we were going to transform it, it would be important to also store the sceneVelocity separately in QEventPoint so that the transformation could be done repeatedly for different items. Task-number: QTBUG-72173 Change-Id: I7ee164d2e6893c4e407fb7d579c75aa32843933a Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
2020-07-23 11:56:26 +00:00
mouseGrabber = event->exclusiveGrabber(event->points().first());
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
event->setAccepted(acceptMouse);
}
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
void mouseDoubleClickEvent(QMouseEvent *event) override
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
{
Remove QQuickPointerEvent etc.; deliver QPointerEvents directly QEventPoint does not have an accessor to get the QPointerEvent that it came from, because that's inconsistent with the idea that QPointerEvent instances are temporary, stack-allocated and movable (the pointer would often be wrong or null, therefore could not be relied upon). So most functions that worked directly with QQuickEventPoint before (which fortunately are still private API) now need to receive the QPointerEvent too, which we choose to pass by pointer. QEventPoint is always passed by reference (const where possible) to be consistent with functions in QPointerEvent that take QEventPoint by reference. QEventPoint::velocity() should be always in scene coordinates now, which saves us the trouble of transforming it to each item's coordinate system during delivery, but means that it will need to be done in handlers or applications sometimes. If we were going to transform it, it would be important to also store the sceneVelocity separately in QEventPoint so that the transformation could be done repeatedly for different items. Task-number: QTBUG-72173 Change-Id: I7ee164d2e6893c4e407fb7d579c75aa32843933a Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
2020-07-23 11:56:26 +00:00
qCDebug(lcTests) << event << "accepting?" << acceptMouse;
Replace calls to deprecated QEvent accessor functions Several event accessors were deprecated in qtbase/24e52c10deedbaef833c0e2c3ee7bee03eacc4f5. Replacements were generated by clazy using the new qevent-accessors check: $ export CLAZY_CHECKS=qevent-accessors $ export CLAZY_EXPORT_FIXES=1 $ ../qt6/configure -platform linux-clang -developer-build -debug -no-optimize-debug -opensource -confirm-license -no-pch QMAKE_CXX=clazy $ make $ cd ../../qt6/qtdeclarative $ find . -name "*.clazy.yaml" $ clang-apply-replacements . Task-number: QTBUG-20885 Task-number: QTBUG-84775 Change-Id: I1be5819506fd5039e86b4494223acbe193e6b0c9 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2020-06-08 07:21:58 +00:00
eventList.append(Event(event->type(), event->position().toPoint(), event->globalPosition().toPoint()));
Remove QQuickPointerEvent etc.; deliver QPointerEvents directly QEventPoint does not have an accessor to get the QPointerEvent that it came from, because that's inconsistent with the idea that QPointerEvent instances are temporary, stack-allocated and movable (the pointer would often be wrong or null, therefore could not be relied upon). So most functions that worked directly with QQuickEventPoint before (which fortunately are still private API) now need to receive the QPointerEvent too, which we choose to pass by pointer. QEventPoint is always passed by reference (const where possible) to be consistent with functions in QPointerEvent that take QEventPoint by reference. QEventPoint::velocity() should be always in scene coordinates now, which saves us the trouble of transforming it to each item's coordinate system during delivery, but means that it will need to be done in handlers or applications sometimes. If we were going to transform it, it would be important to also store the sceneVelocity separately in QEventPoint so that the transformation could be done repeatedly for different items. Task-number: QTBUG-72173 Change-Id: I7ee164d2e6893c4e407fb7d579c75aa32843933a Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
2020-07-23 11:56:26 +00:00
mouseGrabber = event->exclusiveGrabber(event->points().first());
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
event->setAccepted(acceptMouse);
}
Remove mouse grabber if touch used for mouse emulation has been grabbed If an item grabs a touch that is currently being used for mouse pointer emulation, the current mouse grabber should lose the mouse as mouse events will no longer be generated from that touch point. Example of what happens without this patch: -User touches a MouseArea. It gets pressed. -Some other item grabs that touch. -This touch eventually ends. -The MouseArea would still be pressed. And what will happens instead after this patch: -User touches a MouseArea. It gets pressed. -Some other item grabs that touch. -The MouseArea gets canceled and released -This touch eventually ends. Change-Id: I24114f18be564553a4a768243bb20379affe7a8f Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
2014-10-10 19:54:39 +00:00
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
void mouseUngrabEvent() override
Remove mouse grabber if touch used for mouse emulation has been grabbed If an item grabs a touch that is currently being used for mouse pointer emulation, the current mouse grabber should lose the mouse as mouse events will no longer be generated from that touch point. Example of what happens without this patch: -User touches a MouseArea. It gets pressed. -Some other item grabs that touch. -This touch eventually ends. -The MouseArea would still be pressed. And what will happens instead after this patch: -User touches a MouseArea. It gets pressed. -Some other item grabs that touch. -The MouseArea gets canceled and released -This touch eventually ends. Change-Id: I24114f18be564553a4a768243bb20379affe7a8f Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
2014-10-10 19:54:39 +00:00
{
Remove QQuickPointerEvent etc.; deliver QPointerEvents directly QEventPoint does not have an accessor to get the QPointerEvent that it came from, because that's inconsistent with the idea that QPointerEvent instances are temporary, stack-allocated and movable (the pointer would often be wrong or null, therefore could not be relied upon). So most functions that worked directly with QQuickEventPoint before (which fortunately are still private API) now need to receive the QPointerEvent too, which we choose to pass by pointer. QEventPoint is always passed by reference (const where possible) to be consistent with functions in QPointerEvent that take QEventPoint by reference. QEventPoint::velocity() should be always in scene coordinates now, which saves us the trouble of transforming it to each item's coordinate system during delivery, but means that it will need to be done in handlers or applications sometimes. If we were going to transform it, it would be important to also store the sceneVelocity separately in QEventPoint so that the transformation could be done repeatedly for different items. Task-number: QTBUG-72173 Change-Id: I7ee164d2e6893c4e407fb7d579c75aa32843933a Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
2020-07-23 11:56:26 +00:00
qCDebug(lcTests);
Remove mouse grabber if touch used for mouse emulation has been grabbed If an item grabs a touch that is currently being used for mouse pointer emulation, the current mouse grabber should lose the mouse as mouse events will no longer be generated from that touch point. Example of what happens without this patch: -User touches a MouseArea. It gets pressed. -Some other item grabs that touch. -This touch eventually ends. -The MouseArea would still be pressed. And what will happens instead after this patch: -User touches a MouseArea. It gets pressed. -Some other item grabs that touch. -The MouseArea gets canceled and released -This touch eventually ends. Change-Id: I24114f18be564553a4a768243bb20379affe7a8f Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
2014-10-10 19:54:39 +00:00
eventList.append(Event(QEvent::UngrabMouse, QPoint(0,0), QPoint(0,0)));
Remove QQuickPointerEvent etc.; deliver QPointerEvents directly QEventPoint does not have an accessor to get the QPointerEvent that it came from, because that's inconsistent with the idea that QPointerEvent instances are temporary, stack-allocated and movable (the pointer would often be wrong or null, therefore could not be relied upon). So most functions that worked directly with QQuickEventPoint before (which fortunately are still private API) now need to receive the QPointerEvent too, which we choose to pass by pointer. QEventPoint is always passed by reference (const where possible) to be consistent with functions in QPointerEvent that take QEventPoint by reference. QEventPoint::velocity() should be always in scene coordinates now, which saves us the trouble of transforming it to each item's coordinate system during delivery, but means that it will need to be done in handlers or applications sometimes. If we were going to transform it, it would be important to also store the sceneVelocity separately in QEventPoint so that the transformation could be done repeatedly for different items. Task-number: QTBUG-72173 Change-Id: I7ee164d2e6893c4e407fb7d579c75aa32843933a Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
2020-07-23 11:56:26 +00:00
mouseGrabber = nullptr;
Remove mouse grabber if touch used for mouse emulation has been grabbed If an item grabs a touch that is currently being used for mouse pointer emulation, the current mouse grabber should lose the mouse as mouse events will no longer be generated from that touch point. Example of what happens without this patch: -User touches a MouseArea. It gets pressed. -Some other item grabs that touch. -This touch eventually ends. -The MouseArea would still be pressed. And what will happens instead after this patch: -User touches a MouseArea. It gets pressed. -Some other item grabs that touch. -The MouseArea gets canceled and released -This touch eventually ends. Change-Id: I24114f18be564553a4a768243bb20379affe7a8f Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
2014-10-10 19:54:39 +00:00
}
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
void touchUngrabEvent() override
When stealing a touchpoint as synth. mouse, ungrab touch If you use MultiPointTouchArea to make a button component, or if you do something similar by subclassing QQuickItem and handling touch events, and you place such a component inside a Flickable, when the user presses on the button and then drags far enough that the Flickable steals the grab, the MPTA or custom item did not receive the touchUngrabEvent() callback. Now it does, so now the button will go back to released state as a result of having the grab stolen. The situation here is special in that it's the only place where a touch event is transformed to be treated as mouse in the future, usually it's either treated as touch or mouse from the start. When this happens, it's not enough to call setMouseGrabber because that doesn't send touch cancel to the previous grabber. Instead we need to explicitly call touchUngrabEvent to notify the touch handling item. The explicit setting of the grabber which was there previously is not needed, since grabMouse will update the grab based on touchMouseId. tst_QQuickMultiPointTouchArea::inFlickable2 was already testing the pressed state of the touchpoint when the grab is stolen, but it was changed in 468626e99a90d6ac21cb311cde05c658ccb3b781; now that can be restored, and we can also un-blacklist inFlickable, which was deemed unstable in 6d163779711d4601931ae0f82910794fb2498136 [ChangeLog][QtQuick] MultiPointTouchArea, and any custom Item, will now properly receive touchUngrabEvent() when the touch grab is stolen by a filtering parent Item, such as a Flickable. Task-number: QTBUG-57910 Change-Id: I4e1b23ed099f01e7eca2e8a0e7ab4c652ef00cfa Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2017-01-05 15:16:43 +00:00
{
Remove QQuickPointerEvent etc.; deliver QPointerEvents directly QEventPoint does not have an accessor to get the QPointerEvent that it came from, because that's inconsistent with the idea that QPointerEvent instances are temporary, stack-allocated and movable (the pointer would often be wrong or null, therefore could not be relied upon). So most functions that worked directly with QQuickEventPoint before (which fortunately are still private API) now need to receive the QPointerEvent too, which we choose to pass by pointer. QEventPoint is always passed by reference (const where possible) to be consistent with functions in QPointerEvent that take QEventPoint by reference. QEventPoint::velocity() should be always in scene coordinates now, which saves us the trouble of transforming it to each item's coordinate system during delivery, but means that it will need to be done in handlers or applications sometimes. If we were going to transform it, it would be important to also store the sceneVelocity separately in QEventPoint so that the transformation could be done repeatedly for different items. Task-number: QTBUG-72173 Change-Id: I7ee164d2e6893c4e407fb7d579c75aa32843933a Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
2020-07-23 11:56:26 +00:00
qCDebug(lcTests);
When stealing a touchpoint as synth. mouse, ungrab touch If you use MultiPointTouchArea to make a button component, or if you do something similar by subclassing QQuickItem and handling touch events, and you place such a component inside a Flickable, when the user presses on the button and then drags far enough that the Flickable steals the grab, the MPTA or custom item did not receive the touchUngrabEvent() callback. Now it does, so now the button will go back to released state as a result of having the grab stolen. The situation here is special in that it's the only place where a touch event is transformed to be treated as mouse in the future, usually it's either treated as touch or mouse from the start. When this happens, it's not enough to call setMouseGrabber because that doesn't send touch cancel to the previous grabber. Instead we need to explicitly call touchUngrabEvent to notify the touch handling item. The explicit setting of the grabber which was there previously is not needed, since grabMouse will update the grab based on touchMouseId. tst_QQuickMultiPointTouchArea::inFlickable2 was already testing the pressed state of the touchpoint when the grab is stolen, but it was changed in 468626e99a90d6ac21cb311cde05c658ccb3b781; now that can be restored, and we can also un-blacklist inFlickable, which was deemed unstable in 6d163779711d4601931ae0f82910794fb2498136 [ChangeLog][QtQuick] MultiPointTouchArea, and any custom Item, will now properly receive touchUngrabEvent() when the touch grab is stolen by a filtering parent Item, such as a Flickable. Task-number: QTBUG-57910 Change-Id: I4e1b23ed099f01e7eca2e8a0e7ab4c652ef00cfa Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2017-01-05 15:16:43 +00:00
++touchUngrabCount;
}
deliveryagent: cancel touch-mouse synthesis when cancelling touch event When we get a touch cancel event from QPA, the delivery agent should also reset any ongoing touch-mouse synthesis. Otherwise it will fail to deliver the next mouse press event that is synthesized thereafter, since touchMouseId will be stuck with a value different from -1 (which we test from deliverTouchAsMouse()). A bug from this is seen on iOS while selecting text. If you do a long press on top of a line edit, it will cancel the initial press sent to the input field, like it should, and use the subsequent move events to show and drag a magnifier glass around from QPA. This works fine. When you stop the drag, a popup menu will show that lets you select the word under the cursor. Now, if you click inside the line edit once more, the selection should normally be removed. But since we didn't clear touchMouseId upon receiving the initial touchCancel event when showing the magnifier, the agent will fail to deliver the press. The result is that nothing happens until you click once more inside the line edit. This patch will make sure that we reset any ongoing touch-mouse synthesis when receiving a touch cancel event. Pick-to: 6.2 Task-number: QTBUG-72110 Change-Id: I1c753736d0078c61e40ae9a6581f967ded62a175 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
2021-10-26 13:43:31 +00:00
void dumpEventList()
{
for (const auto &event : eventList)
qDebug() << event;
}
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
bool event(QEvent *event) override {
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
return QQuickItem::event(event);
}
QList<Event> eventList;
Remove QQuickPointerEvent etc.; deliver QPointerEvents directly QEventPoint does not have an accessor to get the QPointerEvent that it came from, because that's inconsistent with the idea that QPointerEvent instances are temporary, stack-allocated and movable (the pointer would often be wrong or null, therefore could not be relied upon). So most functions that worked directly with QQuickEventPoint before (which fortunately are still private API) now need to receive the QPointerEvent too, which we choose to pass by pointer. QEventPoint is always passed by reference (const where possible) to be consistent with functions in QPointerEvent that take QEventPoint by reference. QEventPoint::velocity() should be always in scene coordinates now, which saves us the trouble of transforming it to each item's coordinate system during delivery, but means that it will need to be done in handlers or applications sometimes. If we were going to transform it, it would be important to also store the sceneVelocity separately in QEventPoint so that the transformation could be done repeatedly for different items. Task-number: QTBUG-72173 Change-Id: I7ee164d2e6893c4e407fb7d579c75aa32843933a Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
2020-07-23 11:56:26 +00:00
QObject *mouseGrabber = nullptr;
init variables where they are declared when possible (clang-tidy) clang-tidy -p compile_commands.json $file -checks='-*,modernize-use-default-member-init,readability-redundant-member-init' -config='{CheckOptions: [{key: modernize-use-default-member-init.UseAssignment, value: "1"}]}' -header-filter='qtdeclarative' -fix Change-Id: I705f3235ff129ba68b0d8dad54a083e29fcead5f Reviewed-by: Johan Helsing <johan.helsing@qt.io>
2018-02-21 10:52:59 +00:00
int touchUngrabCount = 0;
bool acceptMouse = false;
bool acceptTouch = false;
bool filterTouch = false; // when used as event filter
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
bool eventFilter(QObject *, QEvent *event) override
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
{
if (event->type() == QEvent::TouchBegin ||
event->type() == QEvent::TouchUpdate ||
event->type() == QEvent::TouchCancel ||
event->type() == QEvent::TouchEnd) {
Remove QQuickPointerEvent etc.; deliver QPointerEvents directly QEventPoint does not have an accessor to get the QPointerEvent that it came from, because that's inconsistent with the idea that QPointerEvent instances are temporary, stack-allocated and movable (the pointer would often be wrong or null, therefore could not be relied upon). So most functions that worked directly with QQuickEventPoint before (which fortunately are still private API) now need to receive the QPointerEvent too, which we choose to pass by pointer. QEventPoint is always passed by reference (const where possible) to be consistent with functions in QPointerEvent that take QEventPoint by reference. QEventPoint::velocity() should be always in scene coordinates now, which saves us the trouble of transforming it to each item's coordinate system during delivery, but means that it will need to be done in handlers or applications sometimes. If we were going to transform it, it would be important to also store the sceneVelocity separately in QEventPoint so that the transformation could be done repeatedly for different items. Task-number: QTBUG-72173 Change-Id: I7ee164d2e6893c4e407fb7d579c75aa32843933a Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
2020-07-23 11:56:26 +00:00
qCDebug(lcTests) << event;
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
QTouchEvent *touch = static_cast<QTouchEvent*>(event);
Remove QQuickPointerEvent etc.; deliver QPointerEvents directly QEventPoint does not have an accessor to get the QPointerEvent that it came from, because that's inconsistent with the idea that QPointerEvent instances are temporary, stack-allocated and movable (the pointer would often be wrong or null, therefore could not be relied upon). So most functions that worked directly with QQuickEventPoint before (which fortunately are still private API) now need to receive the QPointerEvent too, which we choose to pass by pointer. QEventPoint is always passed by reference (const where possible) to be consistent with functions in QPointerEvent that take QEventPoint by reference. QEventPoint::velocity() should be always in scene coordinates now, which saves us the trouble of transforming it to each item's coordinate system during delivery, but means that it will need to be done in handlers or applications sometimes. If we were going to transform it, it would be important to also store the sceneVelocity separately in QEventPoint so that the transformation could be done repeatedly for different items. Task-number: QTBUG-72173 Change-Id: I7ee164d2e6893c4e407fb7d579c75aa32843933a Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
2020-07-23 11:56:26 +00:00
eventList.append(Event(event->type(), touch->points()));
Q_ASSERT(touch->pointCount() > 0);
point0 = touch->point(0).id();
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
if (filterTouch)
event->accept();
return true;
}
return false;
}
init variables where they are declared when possible (clang-tidy) clang-tidy -p compile_commands.json $file -checks='-*,modernize-use-default-member-init,readability-redundant-member-init' -config='{CheckOptions: [{key: modernize-use-default-member-init.UseAssignment, value: "1"}]}' -header-filter='qtdeclarative' -fix Change-Id: I705f3235ff129ba68b0d8dad54a083e29fcead5f Reviewed-by: Johan Helsing <johan.helsing@qt.io>
2018-02-21 10:52:59 +00:00
int point0 = -1;
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
};
Remove QQuickPointerEvent etc.; deliver QPointerEvents directly QEventPoint does not have an accessor to get the QPointerEvent that it came from, because that's inconsistent with the idea that QPointerEvent instances are temporary, stack-allocated and movable (the pointer would often be wrong or null, therefore could not be relied upon). So most functions that worked directly with QQuickEventPoint before (which fortunately are still private API) now need to receive the QPointerEvent too, which we choose to pass by pointer. QEventPoint is always passed by reference (const where possible) to be consistent with functions in QPointerEvent that take QEventPoint by reference. QEventPoint::velocity() should be always in scene coordinates now, which saves us the trouble of transforming it to each item's coordinate system during delivery, but means that it will need to be done in handlers or applications sometimes. If we were going to transform it, it would be important to also store the sceneVelocity separately in QEventPoint so that the transformation could be done repeatedly for different items. Task-number: QTBUG-72173 Change-Id: I7ee164d2e6893c4e407fb7d579c75aa32843933a Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
2020-07-23 11:56:26 +00:00
class GrabMonitor : public QObject
{
public:
QObject *exclusiveGrabber = nullptr;
Don't accept all QTouchEvent::points unless the item accepts touch An items that handles touch events can accept multiple touchpoints; but after visiting an item that does not handle events at all, or that relies on synth-mouse events, let the remaining touchpoints continue propagating. Do not automatically accept all touchpoints just because an item accepted a synth-mouse event, and do not auto-grab other touchpoints besides the touchmouse point. Done-with: Shawn Rutledge Pick-to: 6.2 6.4 Fixes: QTBUG-107867 Change-Id: I6c342487a4f8bacbd84e6d7e0e7c00884791a610 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Mitch Curtis <mitch.curtis@qt.io> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
2022-10-21 08:36:14 +00:00
int transitionCount = 0;
Remove QQuickPointerEvent etc.; deliver QPointerEvents directly QEventPoint does not have an accessor to get the QPointerEvent that it came from, because that's inconsistent with the idea that QPointerEvent instances are temporary, stack-allocated and movable (the pointer would often be wrong or null, therefore could not be relied upon). So most functions that worked directly with QQuickEventPoint before (which fortunately are still private API) now need to receive the QPointerEvent too, which we choose to pass by pointer. QEventPoint is always passed by reference (const where possible) to be consistent with functions in QPointerEvent that take QEventPoint by reference. QEventPoint::velocity() should be always in scene coordinates now, which saves us the trouble of transforming it to each item's coordinate system during delivery, but means that it will need to be done in handlers or applications sometimes. If we were going to transform it, it would be important to also store the sceneVelocity separately in QEventPoint so that the transformation could be done repeatedly for different items. Task-number: QTBUG-72173 Change-Id: I7ee164d2e6893c4e407fb7d579c75aa32843933a Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
2020-07-23 11:56:26 +00:00
bool fromMouseEvent = false;
bool canceled = false;
Stabilize tst_TouchMouse::strayTouchDoesntAutograb Apparently GrabMonitor sees all grab transitions in prior autotests up until strayTouchDoesntAutograb() runs; so it's surprising that it ever passed. Now we reset its state to initial conditions at the beginning. Amends 5ced8ec177fd730676eb854aea559a5f324a39b6 Pick-to: 6.2 6.4 Fixes: QTBUG-108352 Change-Id: I31c398f9cd08b2281ea82054b667437f1151f0bd Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2022-11-11 07:56:31 +00:00
void reset()
{
exclusiveGrabber = nullptr;
transitionCount = 0;
fromMouseEvent = false;
canceled = false;
}
Remove QQuickPointerEvent etc.; deliver QPointerEvents directly QEventPoint does not have an accessor to get the QPointerEvent that it came from, because that's inconsistent with the idea that QPointerEvent instances are temporary, stack-allocated and movable (the pointer would often be wrong or null, therefore could not be relied upon). So most functions that worked directly with QQuickEventPoint before (which fortunately are still private API) now need to receive the QPointerEvent too, which we choose to pass by pointer. QEventPoint is always passed by reference (const where possible) to be consistent with functions in QPointerEvent that take QEventPoint by reference. QEventPoint::velocity() should be always in scene coordinates now, which saves us the trouble of transforming it to each item's coordinate system during delivery, but means that it will need to be done in handlers or applications sometimes. If we were going to transform it, it would be important to also store the sceneVelocity separately in QEventPoint so that the transformation could be done repeatedly for different items. Task-number: QTBUG-72173 Change-Id: I7ee164d2e6893c4e407fb7d579c75aa32843933a Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
2020-07-23 11:56:26 +00:00
void onGrabChanged(QObject *grabber, QPointingDevice::GrabTransition transition, const QPointerEvent *event, const QEventPoint &point)
{
qCDebug(lcTests) << grabber << transition << event << point << point.device();
Don't accept all QTouchEvent::points unless the item accepts touch An items that handles touch events can accept multiple touchpoints; but after visiting an item that does not handle events at all, or that relies on synth-mouse events, let the remaining touchpoints continue propagating. Do not automatically accept all touchpoints just because an item accepted a synth-mouse event, and do not auto-grab other touchpoints besides the touchmouse point. Done-with: Shawn Rutledge Pick-to: 6.2 6.4 Fixes: QTBUG-107867 Change-Id: I6c342487a4f8bacbd84e6d7e0e7c00884791a610 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Mitch Curtis <mitch.curtis@qt.io> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
2022-10-21 08:36:14 +00:00
++transitionCount;
Remove QQuickPointerEvent etc.; deliver QPointerEvents directly QEventPoint does not have an accessor to get the QPointerEvent that it came from, because that's inconsistent with the idea that QPointerEvent instances are temporary, stack-allocated and movable (the pointer would often be wrong or null, therefore could not be relied upon). So most functions that worked directly with QQuickEventPoint before (which fortunately are still private API) now need to receive the QPointerEvent too, which we choose to pass by pointer. QEventPoint is always passed by reference (const where possible) to be consistent with functions in QPointerEvent that take QEventPoint by reference. QEventPoint::velocity() should be always in scene coordinates now, which saves us the trouble of transforming it to each item's coordinate system during delivery, but means that it will need to be done in handlers or applications sometimes. If we were going to transform it, it would be important to also store the sceneVelocity separately in QEventPoint so that the transformation could be done repeatedly for different items. Task-number: QTBUG-72173 Change-Id: I7ee164d2e6893c4e407fb7d579c75aa32843933a Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
2020-07-23 11:56:26 +00:00
switch (transition) {
case QPointingDevice::GrabTransition::GrabExclusive:
exclusiveGrabber = grabber;
Move event delivery from QQWindow to QQuickDeliveryAgent QQuickWindow owns QQuickRootItem which owns QQuickDeliveryAgent, so for every window there's an object responsible for event delivery, while the window itself is mainly responsible for rendering (separation of concerns). However, QQuickRootItem and QQuickDeliveryAgent can now be used in cases where the scene doesn't directly belong to a window, such as when a Qt Quick sub-scene is mapped somewhere into a Qt Quick 3D scene. In that case, we must remember which delivery agent was in use at the time when a QEventPoint is grabbed and deliver subsequent updates via the same DA. There's also a QQuickDeliveryAgent::Transform abstraction which subscene-management code (such as QQuick3DViewport) can implement, to provide a formula to map the window's scene coordinates to subscene coordinates; if defined, it will be used during delivery of subsequent updates to existing grabbers. Task-number: QTBUG-84870 Change-Id: I70b433f7ebb05d2e60214ff3192e05da0aa84a42 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
2020-07-14 18:09:57 +00:00
fromMouseEvent = event && QQuickDeliveryAgentPrivate::isMouseEvent(event);
Remove QQuickPointerEvent etc.; deliver QPointerEvents directly QEventPoint does not have an accessor to get the QPointerEvent that it came from, because that's inconsistent with the idea that QPointerEvent instances are temporary, stack-allocated and movable (the pointer would often be wrong or null, therefore could not be relied upon). So most functions that worked directly with QQuickEventPoint before (which fortunately are still private API) now need to receive the QPointerEvent too, which we choose to pass by pointer. QEventPoint is always passed by reference (const where possible) to be consistent with functions in QPointerEvent that take QEventPoint by reference. QEventPoint::velocity() should be always in scene coordinates now, which saves us the trouble of transforming it to each item's coordinate system during delivery, but means that it will need to be done in handlers or applications sometimes. If we were going to transform it, it would be important to also store the sceneVelocity separately in QEventPoint so that the transformation could be done repeatedly for different items. Task-number: QTBUG-72173 Change-Id: I7ee164d2e6893c4e407fb7d579c75aa32843933a Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
2020-07-23 11:56:26 +00:00
canceled = false;
break;
case QPointingDevice::GrabTransition::UngrabExclusive:
exclusiveGrabber = nullptr;
canceled = false;
break;
case QPointingDevice::GrabTransition::CancelGrabExclusive:
exclusiveGrabber = nullptr;
canceled = true;
break;
default:
// ignore the passive grabs since this test doesn't involve pointer handlers
break;
}
}
};
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
class tst_TouchMouse : public QQmlDataTest
{
Q_OBJECT
public:
tst_TouchMouse()
Consolidate test helpers into private libraries Previously each test would include and build sources from the shared folder. Now we make those sources a library, build it once, then have each test link to it instead. We also take the opportunity to move some helpers that qtquickcontrols2 had added into the quicktestutils library where it makes sense, and for the helpers that don't make sense to be there, move them into quickcontrolstestutils. We add the libraries to src/ so that they are internal modules built as part of Qt, rather than tests. That way we can use them in a standalone test outside of qtdeclarative. Task-number: QTBUG-95621 Pick-to: 6.2 Change-Id: I0a2ab3976fdbff2e4414df7bdc0808f16453b80a Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
2021-08-06 10:27:35 +00:00
: QQmlDataTest(QT_QMLTEST_DATADIR)
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
{}
private slots:
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
void initTestCase() override;
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
QQuickWindow: obey AA_SynthesizeMouseForUnhandledTouchEvents Until now, AA_SynthesizeMouseForUnhandledTouchEvents has only affected behavior of QGuiApplicationPrivate::processTouchEvent, but had no effect in Qt Quick. QQuickWindow also accepts the touch event just to make sure that QGuiApplication will not synthesize mouse from touch, because it would be redundant: QQuickWindow does that for itself. Now we make it have an effect in Qt Quick too: skip mouse synthesis if it is set to false. This provides a way to simplify the event delivery. If you set it false, then you cannot manipulate old mouse-only items like MouseArea and Flickable on a touchscreen. (You can of course use event handlers for that.) [ChangeLog][QtQuick][QQuickWindow] You can now disable touch->mouse event synthesis in QtQuick by calling qGuiApp.setAttribute(Qt::AA_SynthesizeMouseForUnhandledTouchEvents, false); This will simplify and speed up event delivery, and it will also prevent any and all interaction with mouse-only items like MouseArea and Flickable on a touchscreen. Task-number: QTBUG-52748 Change-Id: I71f1731b5abaeabd9dbce1112cd23bc97d24c12a Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2018-01-31 11:54:40 +00:00
void simpleTouchEvent_data();
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
void simpleTouchEvent();
Fix warnings about overloaded virtual functions in tests (CLANG). Change-Id: I1f4bda77d0520766813201726f53b439b6094a24 Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@digia.com>
2013-03-07 11:08:48 +00:00
void testEventFilter();
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
void mouse();
void touchOverMouse();
void mouseOverTouch();
void buttonOnFlickable();
When stealing a touchpoint as synth. mouse, ungrab touch If you use MultiPointTouchArea to make a button component, or if you do something similar by subclassing QQuickItem and handling touch events, and you place such a component inside a Flickable, when the user presses on the button and then drags far enough that the Flickable steals the grab, the MPTA or custom item did not receive the touchUngrabEvent() callback. Now it does, so now the button will go back to released state as a result of having the grab stolen. The situation here is special in that it's the only place where a touch event is transformed to be treated as mouse in the future, usually it's either treated as touch or mouse from the start. When this happens, it's not enough to call setMouseGrabber because that doesn't send touch cancel to the previous grabber. Instead we need to explicitly call touchUngrabEvent to notify the touch handling item. The explicit setting of the grabber which was there previously is not needed, since grabMouse will update the grab based on touchMouseId. tst_QQuickMultiPointTouchArea::inFlickable2 was already testing the pressed state of the touchpoint when the grab is stolen, but it was changed in 468626e99a90d6ac21cb311cde05c658ccb3b781; now that can be restored, and we can also un-blacklist inFlickable, which was deemed unstable in 6d163779711d4601931ae0f82910794fb2498136 [ChangeLog][QtQuick] MultiPointTouchArea, and any custom Item, will now properly receive touchUngrabEvent() when the touch grab is stolen by a filtering parent Item, such as a Flickable. Task-number: QTBUG-57910 Change-Id: I4e1b23ed099f01e7eca2e8a0e7ab4c652ef00cfa Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2017-01-05 15:16:43 +00:00
void touchButtonOnFlickable();
Fix behavior of Flickable::setPressDelay This expands the test and fixes the code. Before this patch, items would see the press event, but get the press stolen again immediately. Change-Id: Iece1d5ffbc09a98fb4bec8d810c7ad78b0f50afe Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2016-10-03 15:04:00 +00:00
void buttonOnDelayedPressFlickable_data();
Fix touch to mouse synthesis/propagation. Having mouse events synthesised from both QtGui and internally in QtQuick is not a great way togo about things, especially when QtGui doesn't have the same degree of knowledge as QtQuick about the items in the scene. Thus, we now accept all events inside QtQuick to block QtGui synthesis, which should fix a significant amount of edge-case touch breakage/bad behavior. Change-Id: I14e1c87761c8f43160049b5e6f9da15b4e5edbb7 Done-with: Martin Jones <martin.jones@jollamobile.com> Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
2013-11-13 11:41:19 +00:00
void buttonOnDelayedPressFlickable();
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
void buttonOnTouch();
void pinchOnFlickable();
void flickableOnPinch();
void mouseOnFlickableOnPinch();
Test case for tapping on stacked mouse areas Shows bug where the bottom mouse area could get a double click event out of a single tap. Change-Id: I4907a1506db2b4ccc5299d698c6e05fd02db963c Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
2012-12-19 17:29:49 +00:00
void tapOnDismissiveTopMouseAreaClicksBottomOne();
Remove mouse grabber if touch used for mouse emulation has been grabbed If an item grabs a touch that is currently being used for mouse pointer emulation, the current mouse grabber should lose the mouse as mouse events will no longer be generated from that touch point. Example of what happens without this patch: -User touches a MouseArea. It gets pressed. -Some other item grabs that touch. -This touch eventually ends. -The MouseArea would still be pressed. And what will happens instead after this patch: -User touches a MouseArea. It gets pressed. -Some other item grabs that touch. -The MouseArea gets canceled and released -This touch eventually ends. Change-Id: I24114f18be564553a4a768243bb20379affe7a8f Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
2014-10-10 19:54:39 +00:00
void touchGrabCausesMouseUngrab();
Test touch point delivery order Change-Id: I9b93eda0378e10bbcc274998d58f5f5ec62bb1b1 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2016-08-01 12:13:20 +00:00
void touchPointDeliveryOrder();
Remove mouse grabber if touch used for mouse emulation has been grabbed If an item grabs a touch that is currently being used for mouse pointer emulation, the current mouse grabber should lose the mouse as mouse events will no longer be generated from that touch point. Example of what happens without this patch: -User touches a MouseArea. It gets pressed. -Some other item grabs that touch. -This touch eventually ends. -The MouseArea would still be pressed. And what will happens instead after this patch: -User touches a MouseArea. It gets pressed. -Some other item grabs that touch. -The MouseArea gets canceled and released -This touch eventually ends. Change-Id: I24114f18be564553a4a768243bb20379affe7a8f Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
2014-10-10 19:54:39 +00:00
Fix containsMouse with touch and hoverEnabled When we synthesize a press/release from touch, the item believes that the mouse never leaves, so if we have several mouse areas, they may all claim that they contain the mouse at the same time. The solution is to synthesize a move back to the actual mouse position. Task-number: QTBUG-40856 Change-Id: I43610d95aa383f847db18b387405b0c4e91cea0f Reviewed-by: Shawn Rutledge <shawn.rutledge@theqtcompany.com>
2015-11-30 15:39:15 +00:00
void hoverEnabled();
Add TouchMouse::implicitUngrab autotest Task-number: QTBUG-57797 Task-number: QTBUG-59098 Change-Id: I3bf9ad33c22cdbd82f3efbdbfc35f63371c04bed Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2017-01-13 09:02:23 +00:00
void implicitUngrab();
deliveryagent: cancel touch-mouse synthesis when cancelling touch event When we get a touch cancel event from QPA, the delivery agent should also reset any ongoing touch-mouse synthesis. Otherwise it will fail to deliver the next mouse press event that is synthesized thereafter, since touchMouseId will be stuck with a value different from -1 (which we test from deliverTouchAsMouse()). A bug from this is seen on iOS while selecting text. If you do a long press on top of a line edit, it will cancel the initial press sent to the input field, like it should, and use the subsequent move events to show and drag a magnifier glass around from QPA. This works fine. When you stop the drag, a popup menu will show that lets you select the word under the cursor. Now, if you click inside the line edit once more, the selection should normally be removed. But since we didn't clear touchMouseId upon receiving the initial touchCancel event when showing the magnifier, the agent will fail to deliver the press. The result is that nothing happens until you click once more inside the line edit. This patch will make sure that we reset any ongoing touch-mouse synthesis when receiving a touch cancel event. Pick-to: 6.2 Task-number: QTBUG-72110 Change-Id: I1c753736d0078c61e40ae9a6581f967ded62a175 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
2021-10-26 13:43:31 +00:00
void touchCancelWillCancelMousePress();
Fix containsMouse with touch and hoverEnabled When we synthesize a press/release from touch, the item believes that the mouse never leaves, so if we have several mouse areas, they may all claim that they contain the mouse at the same time. The solution is to synthesize a move back to the actual mouse position. Task-number: QTBUG-40856 Change-Id: I43610d95aa383f847db18b387405b0c4e91cea0f Reviewed-by: Shawn Rutledge <shawn.rutledge@theqtcompany.com>
2015-11-30 15:39:15 +00:00
DeliveryAgent: don't cancelTouchMouseSynthesis() prematurely Do cancelTouchMouseSynthesis() when all touchpoints are released, or when the touchmouse is released; but not because another point is released while the touchmouse is still held. Pick-to: 6.2 6.3 Fixes: QTBUG-102996 Change-Id: I1de21c1119ab1c420f41af32580b25691d28f14e Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jarkko Koivikko <jarkko.koivikko@code-q.fi> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
2022-04-29 19:49:57 +00:00
void oneTouchInsideAndOneOutside();
Don't accept all QTouchEvent::points unless the item accepts touch An items that handles touch events can accept multiple touchpoints; but after visiting an item that does not handle events at all, or that relies on synth-mouse events, let the remaining touchpoints continue propagating. Do not automatically accept all touchpoints just because an item accepted a synth-mouse event, and do not auto-grab other touchpoints besides the touchmouse point. Done-with: Shawn Rutledge Pick-to: 6.2 6.4 Fixes: QTBUG-107867 Change-Id: I6c342487a4f8bacbd84e6d7e0e7c00884791a610 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Mitch Curtis <mitch.curtis@qt.io> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
2022-10-21 08:36:14 +00:00
void strayTouchDoesntAutograb();
Fix touch to mouse synthesis/propagation. Having mouse events synthesised from both QtGui and internally in QtQuick is not a great way togo about things, especially when QtGui doesn't have the same degree of knowledge as QtQuick about the items in the scene. Thus, we now accept all events inside QtQuick to block QtGui synthesis, which should fix a significant amount of edge-case touch breakage/bad behavior. Change-Id: I14e1c87761c8f43160049b5e6f9da15b4e5edbb7 Done-with: Martin Jones <martin.jones@jollamobile.com> Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
2013-11-13 11:41:19 +00:00
protected:
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
bool eventFilter(QObject *, QEvent *event) override
Fix touch to mouse synthesis/propagation. Having mouse events synthesised from both QtGui and internally in QtQuick is not a great way togo about things, especially when QtGui doesn't have the same degree of knowledge as QtQuick about the items in the scene. Thus, we now accept all events inside QtQuick to block QtGui synthesis, which should fix a significant amount of edge-case touch breakage/bad behavior. Change-Id: I14e1c87761c8f43160049b5e6f9da15b4e5edbb7 Done-with: Martin Jones <martin.jones@jollamobile.com> Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
2013-11-13 11:41:19 +00:00
{
Teach flickable to handle and replay touch as it does mouse QQuickWindowPrivate::cloneMouseEvent() renamed to clonePointerEvent() and generalized to be able to clone any of the kinds of QPointerEvent that we're interested in replaying. Now it is used only in QQuickFlickablePrivate::captureDelayedPress(). Reverts f278bb7c66bb00c9f81b7a3aceeb94cb9b3a1b66 and 012a4528a515af8d7ec7dbc05a38d8fd0d6d4d1b (don't skip tst_TouchMouse::buttonOnDelayedPressFlickable). Some test changes from f128b5dee8a2a03ebc55ed0cd1e749a6599282c3 also get reverted. QEventPoint should always have valid velocity now, so Flickable no longer has to calculate it for itself. Removing that became necessary to fix the movingAndFlicking test. Adds logging categories qt.quick.flickable.filter and .replay. Fixes: QTBUG-85607 Task-number: QTBUG-83437 Task-number: QTBUG-78818 Task-number: QTBUG-61144 Task-number: QTBUG-88038 Task-number: QTBUG-88138 Change-Id: I0ed6802dff5e5d1595adddc389642925f1f2c93d Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
2020-09-30 17:35:26 +00:00
if (event->isPointerEvent()) {
qCDebug(lcTests) << "window filtering" << event;
QPointerEvent *pe = static_cast<QPointerEvent*>(event);
filteredEventList.append(Event(pe->type(),
pe->points().first().position().toPoint(),
pe->points().first().globalPosition().toPoint()));
Fix touch to mouse synthesis/propagation. Having mouse events synthesised from both QtGui and internally in QtQuick is not a great way togo about things, especially when QtGui doesn't have the same degree of knowledge as QtQuick about the items in the scene. Thus, we now accept all events inside QtQuick to block QtGui synthesis, which should fix a significant amount of edge-case touch breakage/bad behavior. Change-Id: I14e1c87761c8f43160049b5e6f9da15b4e5edbb7 Done-with: Martin Jones <martin.jones@jollamobile.com> Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
2013-11-13 11:41:19 +00:00
}
return false;
}
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
private:
QQuickView *createView();
Remove QQuickPointerDevice in favor of QPointingDevice ...and generally deal with changes immediately required after adding QInputDevice and QPointingDevice. Also fixed a few usages of deprecated accessors that weren't taken care of in 212c2bffbb041aee0e3c9a7f0551ef151ed2d3ad. Task-number: QTBUG-46412 Task-number: QTBUG-69433 Task-number: QTBUG-72167 Change-Id: I93a2643162878afa216556f10808fd92e0b20071 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2020-03-26 15:50:40 +00:00
QPointingDevice *device = QTest::createTouchDevice();
Fix touch to mouse synthesis/propagation. Having mouse events synthesised from both QtGui and internally in QtQuick is not a great way togo about things, especially when QtGui doesn't have the same degree of knowledge as QtQuick about the items in the scene. Thus, we now accept all events inside QtQuick to block QtGui synthesis, which should fix a significant amount of edge-case touch breakage/bad behavior. Change-Id: I14e1c87761c8f43160049b5e6f9da15b4e5edbb7 Done-with: Martin Jones <martin.jones@jollamobile.com> Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
2013-11-13 11:41:19 +00:00
QList<Event> filteredEventList;
Remove QQuickPointerEvent etc.; deliver QPointerEvents directly QEventPoint does not have an accessor to get the QPointerEvent that it came from, because that's inconsistent with the idea that QPointerEvent instances are temporary, stack-allocated and movable (the pointer would often be wrong or null, therefore could not be relied upon). So most functions that worked directly with QQuickEventPoint before (which fortunately are still private API) now need to receive the QPointerEvent too, which we choose to pass by pointer. QEventPoint is always passed by reference (const where possible) to be consistent with functions in QPointerEvent that take QEventPoint by reference. QEventPoint::velocity() should be always in scene coordinates now, which saves us the trouble of transforming it to each item's coordinate system during delivery, but means that it will need to be done in handlers or applications sometimes. If we were going to transform it, it would be important to also store the sceneVelocity separately in QEventPoint so that the transformation could be done repeatedly for different items. Task-number: QTBUG-72173 Change-Id: I7ee164d2e6893c4e407fb7d579c75aa32843933a Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
2020-07-23 11:56:26 +00:00
GrabMonitor grabMonitor;
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
};
QQuickView *tst_TouchMouse::createView()
{
use nullptr consistently (clang-tidy) From now on we prefer nullptr instead of 0 to clarify cases where we are assigning or testing a pointer rather than a numeric zero. Also, replaced cases where 0 was passed as Qt::KeyboardModifiers with Qt::NoModifier (clang-tidy replaced them with nullptr, which waas wrong, so it was just as well to make the tests more readable rather than to revert those lines). Change-Id: I4735d35e4d9f42db5216862ce091429eadc6e65d Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2018-02-21 09:41:54 +00:00
QQuickView *window = new QQuickView(nullptr);
QQuickCanvas renames QQuickCanvas is now called QQuickWindow QQuickCanvas::rootItem is now QQuickWindow::contentItem QQuickItem::canvas is now QQuickItem::window QQuickItem::ItemChangeData::canvas is also renamed window QQuickCanvas::grabFrameBuffer is now QQuickWindow::grabWindow The functions related to the color property have dropped the clear from their names. The first three changes have interim compatibility measures in place to ease the transition. Change-Id: Id34e29546a22a74a7ae2ad90ee3a8def6fc541d2 Reviewed-by: Martin Jones <martin.jones@nokia.com>
2012-07-11 07:32:16 +00:00
return window;
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
}
void tst_TouchMouse::initTestCase()
{
QQmlDataTest::initTestCase();
qmlRegisterType<EventItem>("Qt.test", 1, 0, "EventItem");
Remove QQuickPointerEvent etc.; deliver QPointerEvents directly QEventPoint does not have an accessor to get the QPointerEvent that it came from, because that's inconsistent with the idea that QPointerEvent instances are temporary, stack-allocated and movable (the pointer would often be wrong or null, therefore could not be relied upon). So most functions that worked directly with QQuickEventPoint before (which fortunately are still private API) now need to receive the QPointerEvent too, which we choose to pass by pointer. QEventPoint is always passed by reference (const where possible) to be consistent with functions in QPointerEvent that take QEventPoint by reference. QEventPoint::velocity() should be always in scene coordinates now, which saves us the trouble of transforming it to each item's coordinate system during delivery, but means that it will need to be done in handlers or applications sometimes. If we were going to transform it, it would be important to also store the sceneVelocity separately in QEventPoint so that the transformation could be done repeatedly for different items. Task-number: QTBUG-72173 Change-Id: I7ee164d2e6893c4e407fb7d579c75aa32843933a Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
2020-07-23 11:56:26 +00:00
connect(device, &QPointingDevice::grabChanged, &grabMonitor, &GrabMonitor::onGrabChanged);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
}
QQuickWindow: obey AA_SynthesizeMouseForUnhandledTouchEvents Until now, AA_SynthesizeMouseForUnhandledTouchEvents has only affected behavior of QGuiApplicationPrivate::processTouchEvent, but had no effect in Qt Quick. QQuickWindow also accepts the touch event just to make sure that QGuiApplication will not synthesize mouse from touch, because it would be redundant: QQuickWindow does that for itself. Now we make it have an effect in Qt Quick too: skip mouse synthesis if it is set to false. This provides a way to simplify the event delivery. If you set it false, then you cannot manipulate old mouse-only items like MouseArea and Flickable on a touchscreen. (You can of course use event handlers for that.) [ChangeLog][QtQuick][QQuickWindow] You can now disable touch->mouse event synthesis in QtQuick by calling qGuiApp.setAttribute(Qt::AA_SynthesizeMouseForUnhandledTouchEvents, false); This will simplify and speed up event delivery, and it will also prevent any and all interaction with mouse-only items like MouseArea and Flickable on a touchscreen. Task-number: QTBUG-52748 Change-Id: I71f1731b5abaeabd9dbce1112cd23bc97d24c12a Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2018-01-31 11:54:40 +00:00
void tst_TouchMouse::simpleTouchEvent_data()
{
QTest::addColumn<bool>("synthMouse"); // AA_SynthesizeMouseForUnhandledTouchEvents
QTest::newRow("no synth") << false;
QTest::newRow("synth") << true;
}
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
void tst_TouchMouse::simpleTouchEvent()
{
QQuickWindow: obey AA_SynthesizeMouseForUnhandledTouchEvents Until now, AA_SynthesizeMouseForUnhandledTouchEvents has only affected behavior of QGuiApplicationPrivate::processTouchEvent, but had no effect in Qt Quick. QQuickWindow also accepts the touch event just to make sure that QGuiApplication will not synthesize mouse from touch, because it would be redundant: QQuickWindow does that for itself. Now we make it have an effect in Qt Quick too: skip mouse synthesis if it is set to false. This provides a way to simplify the event delivery. If you set it false, then you cannot manipulate old mouse-only items like MouseArea and Flickable on a touchscreen. (You can of course use event handlers for that.) [ChangeLog][QtQuick][QQuickWindow] You can now disable touch->mouse event synthesis in QtQuick by calling qGuiApp.setAttribute(Qt::AA_SynthesizeMouseForUnhandledTouchEvents, false); This will simplify and speed up event delivery, and it will also prevent any and all interaction with mouse-only items like MouseArea and Flickable on a touchscreen. Task-number: QTBUG-52748 Change-Id: I71f1731b5abaeabd9dbce1112cd23bc97d24c12a Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2018-01-31 11:54:40 +00:00
QFETCH(bool, synthMouse);
qApp->setAttribute(Qt::AA_SynthesizeMouseForUnhandledTouchEvents, synthMouse);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QQuickView window;
QVERIFY(QQuickTest::showView(window, testFileUrl("singleitem.qml")));
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
EventItem *eventItem1 = window.rootObject()->findChild<EventItem*>("eventItem1");
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
QVERIFY(eventItem1);
Remove QQuickPointerEvent etc.; deliver QPointerEvents directly QEventPoint does not have an accessor to get the QPointerEvent that it came from, because that's inconsistent with the idea that QPointerEvent instances are temporary, stack-allocated and movable (the pointer would often be wrong or null, therefore could not be relied upon). So most functions that worked directly with QQuickEventPoint before (which fortunately are still private API) now need to receive the QPointerEvent too, which we choose to pass by pointer. QEventPoint is always passed by reference (const where possible) to be consistent with functions in QPointerEvent that take QEventPoint by reference. QEventPoint::velocity() should be always in scene coordinates now, which saves us the trouble of transforming it to each item's coordinate system during delivery, but means that it will need to be done in handlers or applications sometimes. If we were going to transform it, it would be important to also store the sceneVelocity separately in QEventPoint so that the transformation could be done repeatedly for different items. Task-number: QTBUG-72173 Change-Id: I7ee164d2e6893c4e407fb7d579c75aa32843933a Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
2020-07-23 11:56:26 +00:00
auto devPriv = QPointingDevicePrivate::get(device);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
// Do not accept touch or mouse
Don't synthesize mouse from touch for items that accept touch 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>
2020-09-30 17:36:09 +00:00
eventItem1->setAcceptTouchEvents(false);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
QPoint p1;
p1 = QPoint(20, 20);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QTest::touchEvent(&window, device).press(0, p1, &window);
QQuickTouchUtils::flush(&window);
Don't synthesize mouse from touch for items that accept touch 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>
2020-09-30 17:36:09 +00:00
// Get a synth-mouse event if allowed
QCOMPARE(eventItem1->eventList.size(), synthMouse ? 1 : 0);
if (synthMouse)
QCOMPARE(eventItem1->eventList.at(0).type, QEvent::MouseButtonPress);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
p1 += QPoint(10, 0);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QTest::touchEvent(&window, device).move(0, p1, &window);
QQuickTouchUtils::flush(&window);
Fix TouchMouse test: accept button That the EventItem would get an event is a bug in the current event handling, there is no reason for it to receive anything when it doesn't accept mouse/touch. Change-Id: I4079e6cb396cc1913f795015dcc7839ca79edb70 Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
2016-07-31 19:27:58 +00:00
// Not accepted, no updates
Don't synthesize mouse from touch for items that accept touch 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>
2020-09-30 17:36:09 +00:00
QCOMPARE(eventItem1->eventList.size(), synthMouse ? 1 : 0);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QTest::touchEvent(&window, device).release(0, p1, &window);
QQuickTouchUtils::flush(&window);
Don't synthesize mouse from touch for items that accept touch 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>
2020-09-30 17:36:09 +00:00
QCOMPARE(eventItem1->eventList.size(), synthMouse ? 1 : 0);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
eventItem1->eventList.clear();
// Accept touch
Don't synthesize mouse from touch for items that accept touch 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>
2020-09-30 17:36:09 +00:00
eventItem1->setAcceptTouchEvents(true);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
eventItem1->acceptTouch = true;
p1 = QPoint(20, 20);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QTest::touchEvent(&window, device).press(0, p1, &window);
QQuickTouchUtils::flush(&window);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
QCOMPARE(eventItem1->eventList.size(), 1);
p1 += QPoint(10, 0);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QTest::touchEvent(&window, device).move(0, p1, &window);
QQuickTouchUtils::flush(&window);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
QCOMPARE(eventItem1->eventList.size(), 2);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QTest::touchEvent(&window, device).release(0, p1, &window);
QQuickTouchUtils::flush(&window);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
QCOMPARE(eventItem1->eventList.size(), 3);
eventItem1->eventList.clear();
// wait to avoid getting a double click event
QTest::qWait(qApp->styleHints()->mouseDoubleClickInterval() + 10);
// Accept mouse
eventItem1->acceptTouch = false;
eventItem1->acceptMouse = true;
Don't synthesize mouse from touch for items that accept touch 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>
2020-09-30 17:36:09 +00:00
eventItem1->setAcceptTouchEvents(false);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
eventItem1->setAcceptedMouseButtons(Qt::LeftButton);
p1 = QPoint(20, 20);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QTest::touchEvent(&window, device).press(0, p1, &window);
QQuickTouchUtils::flush(&window);
Don't synthesize mouse from touch for items that accept touch 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>
2020-09-30 17:36:09 +00:00
QCOMPARE(eventItem1->eventList.size(), synthMouse ? 1 : 0);
QQuickWindow: obey AA_SynthesizeMouseForUnhandledTouchEvents Until now, AA_SynthesizeMouseForUnhandledTouchEvents has only affected behavior of QGuiApplicationPrivate::processTouchEvent, but had no effect in Qt Quick. QQuickWindow also accepts the touch event just to make sure that QGuiApplication will not synthesize mouse from touch, because it would be redundant: QQuickWindow does that for itself. Now we make it have an effect in Qt Quick too: skip mouse synthesis if it is set to false. This provides a way to simplify the event delivery. If you set it false, then you cannot manipulate old mouse-only items like MouseArea and Flickable on a touchscreen. (You can of course use event handlers for that.) [ChangeLog][QtQuick][QQuickWindow] You can now disable touch->mouse event synthesis in QtQuick by calling qGuiApp.setAttribute(Qt::AA_SynthesizeMouseForUnhandledTouchEvents, false); This will simplify and speed up event delivery, and it will also prevent any and all interaction with mouse-only items like MouseArea and Flickable on a touchscreen. Task-number: QTBUG-52748 Change-Id: I71f1731b5abaeabd9dbce1112cd23bc97d24c12a Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2018-01-31 11:54:40 +00:00
if (synthMouse)
Don't synthesize mouse from touch for items that accept touch 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>
2020-09-30 17:36:09 +00:00
QCOMPARE(eventItem1->eventList.at(0).type, QEvent::MouseButtonPress);
Remove QQuickPointerEvent etc.; deliver QPointerEvents directly QEventPoint does not have an accessor to get the QPointerEvent that it came from, because that's inconsistent with the idea that QPointerEvent instances are temporary, stack-allocated and movable (the pointer would often be wrong or null, therefore could not be relied upon). So most functions that worked directly with QQuickEventPoint before (which fortunately are still private API) now need to receive the QPointerEvent too, which we choose to pass by pointer. QEventPoint is always passed by reference (const where possible) to be consistent with functions in QPointerEvent that take QEventPoint by reference. QEventPoint::velocity() should be always in scene coordinates now, which saves us the trouble of transforming it to each item's coordinate system during delivery, but means that it will need to be done in handlers or applications sometimes. If we were going to transform it, it would be important to also store the sceneVelocity separately in QEventPoint so that the transformation could be done repeatedly for different items. Task-number: QTBUG-72173 Change-Id: I7ee164d2e6893c4e407fb7d579c75aa32843933a Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
2020-07-23 11:56:26 +00:00
QCOMPARE(devPriv->firstPointExclusiveGrabber(), synthMouse ? eventItem1 : nullptr);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
QPoint localPos = eventItem1->mapFromScene(p1).toPoint();
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QPoint globalPos = window.mapToGlobal(p1);
QQuickWindow: obey AA_SynthesizeMouseForUnhandledTouchEvents Until now, AA_SynthesizeMouseForUnhandledTouchEvents has only affected behavior of QGuiApplicationPrivate::processTouchEvent, but had no effect in Qt Quick. QQuickWindow also accepts the touch event just to make sure that QGuiApplication will not synthesize mouse from touch, because it would be redundant: QQuickWindow does that for itself. Now we make it have an effect in Qt Quick too: skip mouse synthesis if it is set to false. This provides a way to simplify the event delivery. If you set it false, then you cannot manipulate old mouse-only items like MouseArea and Flickable on a touchscreen. (You can of course use event handlers for that.) [ChangeLog][QtQuick][QQuickWindow] You can now disable touch->mouse event synthesis in QtQuick by calling qGuiApp.setAttribute(Qt::AA_SynthesizeMouseForUnhandledTouchEvents, false); This will simplify and speed up event delivery, and it will also prevent any and all interaction with mouse-only items like MouseArea and Flickable on a touchscreen. Task-number: QTBUG-52748 Change-Id: I71f1731b5abaeabd9dbce1112cd23bc97d24c12a Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2018-01-31 11:54:40 +00:00
if (synthMouse) {
Don't synthesize mouse from touch for items that accept touch 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>
2020-09-30 17:36:09 +00:00
QCOMPARE(eventItem1->eventList.at(0).mousePos, localPos);
QCOMPARE(eventItem1->eventList.at(0).mousePosGlobal, globalPos);
QQuickWindow: obey AA_SynthesizeMouseForUnhandledTouchEvents Until now, AA_SynthesizeMouseForUnhandledTouchEvents has only affected behavior of QGuiApplicationPrivate::processTouchEvent, but had no effect in Qt Quick. QQuickWindow also accepts the touch event just to make sure that QGuiApplication will not synthesize mouse from touch, because it would be redundant: QQuickWindow does that for itself. Now we make it have an effect in Qt Quick too: skip mouse synthesis if it is set to false. This provides a way to simplify the event delivery. If you set it false, then you cannot manipulate old mouse-only items like MouseArea and Flickable on a touchscreen. (You can of course use event handlers for that.) [ChangeLog][QtQuick][QQuickWindow] You can now disable touch->mouse event synthesis in QtQuick by calling qGuiApp.setAttribute(Qt::AA_SynthesizeMouseForUnhandledTouchEvents, false); This will simplify and speed up event delivery, and it will also prevent any and all interaction with mouse-only items like MouseArea and Flickable on a touchscreen. Task-number: QTBUG-52748 Change-Id: I71f1731b5abaeabd9dbce1112cd23bc97d24c12a Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2018-01-31 11:54:40 +00:00
}
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
p1 += QPoint(10, 0);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QTest::touchEvent(&window, device).move(0, p1, &window);
QQuickTouchUtils::flush(&window);
Don't synthesize mouse from touch for items that accept touch 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>
2020-09-30 17:36:09 +00:00
QCOMPARE(eventItem1->eventList.size(), synthMouse ? 2 : 0);
if (synthMouse)
QCOMPARE(eventItem1->eventList.at(1).type, QEvent::MouseMove);
QQuickWindow: obey AA_SynthesizeMouseForUnhandledTouchEvents Until now, AA_SynthesizeMouseForUnhandledTouchEvents has only affected behavior of QGuiApplicationPrivate::processTouchEvent, but had no effect in Qt Quick. QQuickWindow also accepts the touch event just to make sure that QGuiApplication will not synthesize mouse from touch, because it would be redundant: QQuickWindow does that for itself. Now we make it have an effect in Qt Quick too: skip mouse synthesis if it is set to false. This provides a way to simplify the event delivery. If you set it false, then you cannot manipulate old mouse-only items like MouseArea and Flickable on a touchscreen. (You can of course use event handlers for that.) [ChangeLog][QtQuick][QQuickWindow] You can now disable touch->mouse event synthesis in QtQuick by calling qGuiApp.setAttribute(Qt::AA_SynthesizeMouseForUnhandledTouchEvents, false); This will simplify and speed up event delivery, and it will also prevent any and all interaction with mouse-only items like MouseArea and Flickable on a touchscreen. Task-number: QTBUG-52748 Change-Id: I71f1731b5abaeabd9dbce1112cd23bc97d24c12a Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2018-01-31 11:54:40 +00:00
// else, if there was no synth-mouse and we didn't accept the touch,
// TouchUpdate was not sent to eventItem1 either.
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QTest::touchEvent(&window, device).release(0, p1, &window);
QQuickTouchUtils::flush(&window);
Don't synthesize mouse from touch for items that accept touch 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>
2020-09-30 17:36:09 +00:00
QCOMPARE(eventItem1->eventList.size(), synthMouse ? 4 : 0);
QQuickWindow: obey AA_SynthesizeMouseForUnhandledTouchEvents Until now, AA_SynthesizeMouseForUnhandledTouchEvents has only affected behavior of QGuiApplicationPrivate::processTouchEvent, but had no effect in Qt Quick. QQuickWindow also accepts the touch event just to make sure that QGuiApplication will not synthesize mouse from touch, because it would be redundant: QQuickWindow does that for itself. Now we make it have an effect in Qt Quick too: skip mouse synthesis if it is set to false. This provides a way to simplify the event delivery. If you set it false, then you cannot manipulate old mouse-only items like MouseArea and Flickable on a touchscreen. (You can of course use event handlers for that.) [ChangeLog][QtQuick][QQuickWindow] You can now disable touch->mouse event synthesis in QtQuick by calling qGuiApp.setAttribute(Qt::AA_SynthesizeMouseForUnhandledTouchEvents, false); This will simplify and speed up event delivery, and it will also prevent any and all interaction with mouse-only items like MouseArea and Flickable on a touchscreen. Task-number: QTBUG-52748 Change-Id: I71f1731b5abaeabd9dbce1112cd23bc97d24c12a Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2018-01-31 11:54:40 +00:00
if (synthMouse) {
Don't synthesize mouse from touch for items that accept touch 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>
2020-09-30 17:36:09 +00:00
QCOMPARE(eventItem1->eventList.at(2).type, QEvent::MouseButtonRelease);
QCOMPARE(eventItem1->eventList.at(3).type, QEvent::UngrabMouse);
QQuickWindow: obey AA_SynthesizeMouseForUnhandledTouchEvents Until now, AA_SynthesizeMouseForUnhandledTouchEvents has only affected behavior of QGuiApplicationPrivate::processTouchEvent, but had no effect in Qt Quick. QQuickWindow also accepts the touch event just to make sure that QGuiApplication will not synthesize mouse from touch, because it would be redundant: QQuickWindow does that for itself. Now we make it have an effect in Qt Quick too: skip mouse synthesis if it is set to false. This provides a way to simplify the event delivery. If you set it false, then you cannot manipulate old mouse-only items like MouseArea and Flickable on a touchscreen. (You can of course use event handlers for that.) [ChangeLog][QtQuick][QQuickWindow] You can now disable touch->mouse event synthesis in QtQuick by calling qGuiApp.setAttribute(Qt::AA_SynthesizeMouseForUnhandledTouchEvents, false); This will simplify and speed up event delivery, and it will also prevent any and all interaction with mouse-only items like MouseArea and Flickable on a touchscreen. Task-number: QTBUG-52748 Change-Id: I71f1731b5abaeabd9dbce1112cd23bc97d24c12a Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2018-01-31 11:54:40 +00:00
}
// else, if there was no synth-mouse and we didn't accept the touch,
// TouchEnd was not sent to eventItem1 either.
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
eventItem1->eventList.clear();
// wait to avoid getting a double click event
QTest::qWait(qApp->styleHints()->mouseDoubleClickInterval() + 10);
// Accept mouse buttons but not the event
eventItem1->acceptTouch = false;
eventItem1->acceptMouse = false;
eventItem1->setAcceptedMouseButtons(Qt::LeftButton);
p1 = QPoint(20, 20);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QTest::touchEvent(&window, device).press(0, p1, &window);
QQuickTouchUtils::flush(&window);
Don't synthesize mouse from touch for items that accept touch 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>
2020-09-30 17:36:09 +00:00
QCOMPARE(eventItem1->eventList.size(), synthMouse ? 1 : 0);
QQuickWindow: obey AA_SynthesizeMouseForUnhandledTouchEvents Until now, AA_SynthesizeMouseForUnhandledTouchEvents has only affected behavior of QGuiApplicationPrivate::processTouchEvent, but had no effect in Qt Quick. QQuickWindow also accepts the touch event just to make sure that QGuiApplication will not synthesize mouse from touch, because it would be redundant: QQuickWindow does that for itself. Now we make it have an effect in Qt Quick too: skip mouse synthesis if it is set to false. This provides a way to simplify the event delivery. If you set it false, then you cannot manipulate old mouse-only items like MouseArea and Flickable on a touchscreen. (You can of course use event handlers for that.) [ChangeLog][QtQuick][QQuickWindow] You can now disable touch->mouse event synthesis in QtQuick by calling qGuiApp.setAttribute(Qt::AA_SynthesizeMouseForUnhandledTouchEvents, false); This will simplify and speed up event delivery, and it will also prevent any and all interaction with mouse-only items like MouseArea and Flickable on a touchscreen. Task-number: QTBUG-52748 Change-Id: I71f1731b5abaeabd9dbce1112cd23bc97d24c12a Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2018-01-31 11:54:40 +00:00
if (synthMouse)
Don't synthesize mouse from touch for items that accept touch 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>
2020-09-30 17:36:09 +00:00
QCOMPARE(eventItem1->eventList.at(0).type, QEvent::MouseButtonPress);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
p1 += QPoint(10, 0);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QTest::touchEvent(&window, device).move(0, p1, &window);
QQuickTouchUtils::flush(&window);
Don't synthesize mouse from touch for items that accept touch 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>
2020-09-30 17:36:09 +00:00
QCOMPARE(eventItem1->eventList.size(), synthMouse ? 1 : 0);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QTest::touchEvent(&window, device).release(0, p1, &window);
QQuickTouchUtils::flush(&window);
Don't synthesize mouse from touch for items that accept touch 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>
2020-09-30 17:36:09 +00:00
QCOMPARE(eventItem1->eventList.size(), synthMouse ? 1 : 0);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
eventItem1->eventList.clear();
// wait to avoid getting a double click event
QTest::qWait(qApp->styleHints()->mouseDoubleClickInterval() + 10);
// Accept touch and mouse
eventItem1->acceptTouch = true;
Don't synthesize mouse from touch for items that accept touch 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>
2020-09-30 17:36:09 +00:00
eventItem1->setAcceptTouchEvents(true);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
eventItem1->setAcceptedMouseButtons(Qt::LeftButton);
p1 = QPoint(20, 20);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QTest::touchEvent(&window, device).press(0, p1, &window);
QQuickTouchUtils::flush(&window);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
QCOMPARE(eventItem1->eventList.size(), 1);
QCOMPARE(eventItem1->eventList.at(0).type, QEvent::TouchBegin);
p1 += QPoint(10, 0);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QTest::touchEvent(&window, device).move(0, p1, &window);
QQuickTouchUtils::flush(&window);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
QCOMPARE(eventItem1->eventList.size(), 2);
QCOMPARE(eventItem1->eventList.at(1).type, QEvent::TouchUpdate);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QTest::touchEvent(&window, device).release(0, p1, &window);
QQuickTouchUtils::flush(&window);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
QCOMPARE(eventItem1->eventList.size(), 3);
QCOMPARE(eventItem1->eventList.at(2).type, QEvent::TouchEnd);
eventItem1->eventList.clear();
}
Fix warnings about overloaded virtual functions in tests (CLANG). Change-Id: I1f4bda77d0520766813201726f53b439b6094a24 Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@digia.com>
2013-03-07 11:08:48 +00:00
void tst_TouchMouse::testEventFilter()
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
{
// // install event filter on item and see that it can grab events
tst_touchmouse: Have a go at some stabilisation & improvements * Use QScopedPointer to own views, preventing leakage (was a problem in a few of these tests, e.g. pinchOnFlickable/flickableOnPinch/mouseOnFlickableOnPinch) * Only qWaitForWindowActive, as the tests aren't doing anything graphical, they don't need an expose event, which means less waiting * Use the test utilities to center the windows on screen to make sure they are not under desktop chrome & have a non-null position. If position is 0,0 that means window->position().isNull() is true, so qWaitForWindowActive will wait for its entire timeout: 5 seconds. This means no "manual" tweaking of geometry anymore: the position is now taken care of by the test utilities, and we let the root QML item size determine the window size. * Move the mouse away from the window using the test utilities. Done-with: Shawn Rutledge Change-Id: I4ac6a0d56067c57ef51f186fe3cd118cab056ff2 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2017-01-11 15:40:28 +00:00
// QScopedPointer<QQuickView> window(createView());
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
// window.setSource(testFileUrl("singleitem.qml"));
// window.show();
Consolidate test helpers into private libraries Previously each test would include and build sources from the shared folder. Now we make those sources a library, build it once, then have each test link to it instead. We also take the opportunity to move some helpers that qtquickcontrols2 had added into the quicktestutils library where it makes sense, and for the helpers that don't make sense to be there, move them into quickcontrolstestutils. We add the libraries to src/ so that they are internal modules built as part of Qt, rather than tests. That way we can use them in a standalone test outside of qtdeclarative. Task-number: QTBUG-95621 Pick-to: 6.2 Change-Id: I0a2ab3976fdbff2e4414df7bdc0808f16453b80a Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
2021-08-06 10:27:35 +00:00
// QQuickVisualTestUtils::centerOnScreen(&window);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
// QVERIFY(QTest::qWaitForWindowActive(&window));
QQuickCanvas renames QQuickCanvas is now called QQuickWindow QQuickCanvas::rootItem is now QQuickWindow::contentItem QQuickItem::canvas is now QQuickItem::window QQuickItem::ItemChangeData::canvas is also renamed window QQuickCanvas::grabFrameBuffer is now QQuickWindow::grabWindow The functions related to the color property have dropped the clear from their names. The first three changes have interim compatibility measures in place to ease the transition. Change-Id: Id34e29546a22a74a7ae2ad90ee3a8def6fc541d2 Reviewed-by: Martin Jones <martin.jones@nokia.com>
2012-07-11 07:32:16 +00:00
// QVERIFY(window->rootObject() != 0);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
// EventItem *eventItem1 = window.rootObject()->findChild<EventItem*>("eventItem1");
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
// QVERIFY(eventItem1);
// eventItem1->acceptTouch = true;
// EventItem *filter = new EventItem;
// filter->filterTouch = true;
// eventItem1->installEventFilter(filter);
// QPoint p1 = QPoint(20, 20);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
// QTest::touchEvent(&window, device).press(0, p1, &window);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
// // QEXPECT_FAIL("", "We do not implement event filters correctly", Abort);
// QCOMPARE(eventItem1->eventList.size(), 0);
// QCOMPARE(filter->eventList.size(), 1);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
// QTest::touchEvent(&window, device).release(0, p1, &window);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
// QCOMPARE(eventItem1->eventList.size(), 0);
// QCOMPARE(filter->eventList.size(), 2);
// delete filter;
}
void tst_TouchMouse::mouse()
{
// eventItem1
// - eventItem2
QTest::qWait(qApp->styleHints()->mouseDoubleClickInterval() + 10);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QQuickView window;
QVERIFY(QQuickTest::showView(window, testFileUrl("twoitems.qml")));
EventItem *eventItem1 = window.rootObject()->findChild<EventItem*>("eventItem1");
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
QVERIFY(eventItem1);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
EventItem *eventItem2 = window.rootObject()->findChild<EventItem*>("eventItem2");
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
QVERIFY(eventItem2);
// bottom item likes mouse, top likes touch
eventItem1->setAcceptedMouseButtons(Qt::LeftButton);
Don't synthesize mouse from touch for items that accept touch 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>
2020-09-30 17:36:09 +00:00
eventItem1->setAcceptTouchEvents(false);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
eventItem1->acceptMouse = true;
// item 2 doesn't accept anything, thus it sees a touch pass by
Don't synthesize mouse from touch for items that accept touch 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>
2020-09-30 17:36:09 +00:00
eventItem2->setAcceptTouchEvents(false);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
QPoint p1 = QPoint(30, 30);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QTest::touchEvent(&window, device).press(0, p1, &window);
QQuickTouchUtils::flush(&window);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
Don't synthesize mouse from touch for items that accept touch 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>
2020-09-30 17:36:09 +00:00
QCOMPARE(eventItem1->eventList.size(), 1);
QCOMPARE(eventItem1->eventList.at(0).type, QEvent::MouseButtonPress);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
}
void tst_TouchMouse::touchOverMouse()
{
// eventItem1
// - eventItem2
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QQuickView window;
QVERIFY(QQuickTest::showView(window, testFileUrl("twoitems.qml")));
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
EventItem *eventItem1 = window.rootObject()->findChild<EventItem*>("eventItem1");
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
QVERIFY(eventItem1);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
EventItem *eventItem2 = window.rootObject()->findChild<EventItem*>("eventItem2");
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
QVERIFY(eventItem2);
// bottom item likes mouse, top likes touch
eventItem1->setAcceptedMouseButtons(Qt::LeftButton);
Don't synthesize mouse from touch for items that accept touch 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>
2020-09-30 17:36:09 +00:00
eventItem1->acceptMouse = true;
eventItem2->acceptTouch = false; // let it fall through
eventItem2->setAcceptTouchEvents(true);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
QCOMPARE(eventItem1->eventList.size(), 0);
QPoint p1 = QPoint(20, 20);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QTest::touchEvent(&window, device).press(0, p1, &window);
QQuickTouchUtils::flush(&window);
Don't synthesize mouse from touch for items that accept touch 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>
2020-09-30 17:36:09 +00:00
qCDebug(lcTests) << "expected delivered events: press(mouse)" << eventItem1->eventList;
QCOMPARE(eventItem1->eventList.size(), 1);
qCDebug(lcTests) << "expected delivered events: press(touch)" << eventItem2->eventList;
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
QCOMPARE(eventItem2->eventList.size(), 1);
QCOMPARE(eventItem2->eventList.at(0).type, QEvent::TouchBegin);
p1 += QPoint(10, 0);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QTest::touchEvent(&window, device).move(0, p1, &window);
QQuickTouchUtils::flush(&window);
Don't synthesize mouse from touch for items that accept touch 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>
2020-09-30 17:36:09 +00:00
qCDebug(lcTests) << "expected delivered events: press(mouse) move(mouse)" << eventItem1->eventList;
QCOMPARE(eventItem1->eventList.size(), 2);
QCOMPARE(eventItem1->eventList.at(1).type, QEvent::MouseMove);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QTest::touchEvent(&window, device).release(0, p1, &window);
QQuickTouchUtils::flush(&window);
Don't synthesize mouse from touch for items that accept touch 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>
2020-09-30 17:36:09 +00:00
qCDebug(lcTests) << "expected delivered events: press(mouse) move(mouse) release(mouse) ungrab(mouse)" << eventItem1->eventList;
QCOMPARE(eventItem1->eventList.size(), 4);
QCOMPARE(eventItem1->eventList.at(2).type, QEvent::MouseButtonRelease);
QCOMPARE(eventItem1->eventList.at(3).type, QEvent::UngrabMouse);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
}
void tst_TouchMouse::mouseOverTouch()
{
// eventItem1
// - eventItem2
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QQuickView window;
QVERIFY(QQuickTest::showView(window, testFileUrl("twoitems.qml")));
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
EventItem *eventItem1 = window.rootObject()->findChild<EventItem*>("eventItem1");
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
QVERIFY(eventItem1);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
EventItem *eventItem2 = window.rootObject()->findChild<EventItem*>("eventItem2");
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
QVERIFY(eventItem2);
// bottom item likes mouse, top likes touch
eventItem1->acceptTouch = true;
eventItem2->setAcceptedMouseButtons(Qt::LeftButton);
eventItem2->acceptMouse = true;
Don't synthesize mouse from touch for items that accept touch 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>
2020-09-30 17:36:09 +00:00
eventItem2->setAcceptTouchEvents(false);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
QPoint p1 = QPoint(20, 20);
QTest::qWait(qApp->styleHints()->mouseDoubleClickInterval() + 10);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QTest::touchEvent(&window, device).press(0, p1, &window);
QQuickTouchUtils::flush(&window);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
QCOMPARE(eventItem1->eventList.size(), 0);
Don't synthesize mouse from touch for items that accept touch 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>
2020-09-30 17:36:09 +00:00
QCOMPARE(eventItem2->eventList.size(), 1);
QCOMPARE(eventItem2->eventList.at(0).type, QEvent::MouseButtonPress);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
p1 += QPoint(10, 0);
QTest::touchEvent(&window, device).move(0, p1, &window);
QCOMPARE(eventItem2->eventList.size(), 1);
QTest::touchEvent(&window, device).release(0, p1, &window);
qCDebug(lcTests) << "expected delivered events: press(mouse) move(mouse) release(mouse) ungrab(mouse)" << eventItem2->eventList;
QCOMPARE(eventItem2->eventList.size(), 4);
eventItem2->eventList.clear();
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
}
void tst_TouchMouse::buttonOnFlickable()
{
// flickable - height 500 / 1000
// - eventItem1 y: 100, height 100
// - eventItem2 y: 300, height 100
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QQuickView window;
QVERIFY(QQuickTest::showView(window, testFileUrl("buttononflickable.qml")));
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QQuickFlickable *flickable = window.rootObject()->findChild<QQuickFlickable*>("flickable");
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
QVERIFY(flickable);
// should a mouse area button be clickable on top of flickable? yes :)
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
EventItem *eventItem1 = window.rootObject()->findChild<EventItem*>("eventItem1");
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
QVERIFY(eventItem1);
eventItem1->setAcceptedMouseButtons(Qt::LeftButton);
eventItem1->acceptMouse = true;
Don't synthesize mouse from touch for items that accept touch 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>
2020-09-30 17:36:09 +00:00
eventItem1->setAcceptTouchEvents(false);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
// should a touch button be touchable on top of flickable? yes :)
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
EventItem *eventItem2 = window.rootObject()->findChild<EventItem*>("eventItem2");
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
QVERIFY(eventItem2);
QCOMPARE(eventItem2->eventList.size(), 0);
eventItem2->acceptTouch = true;
Don't synthesize mouse from touch for items that accept touch 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>
2020-09-30 17:36:09 +00:00
eventItem2->setAcceptTouchEvents(true);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
// wait to avoid getting a double click event
QTest::qWait(qApp->styleHints()->mouseDoubleClickInterval() + 10);
// check that buttons are clickable
// mouse button
QCOMPARE(eventItem1->eventList.size(), 0);
QPoint p1 = QPoint(20, 130);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QTest::touchEvent(&window, device).press(0, p1, &window);
QQuickTouchUtils::flush(&window);
Don't synthesize mouse from touch for items that accept touch 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>
2020-09-30 17:36:09 +00:00
QTRY_COMPARE(eventItem1->eventList.size(), 1);
QCOMPARE(eventItem1->eventList.at(0).type, QEvent::MouseButtonPress);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QTest::touchEvent(&window, device).release(0, p1, &window);
QQuickTouchUtils::flush(&window);
Don't synthesize mouse from touch for items that accept touch 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>
2020-09-30 17:36:09 +00:00
QCOMPARE(eventItem1->eventList.size(), 3);
QCOMPARE(eventItem1->eventList.at(1).type, QEvent::MouseButtonRelease);
QCOMPARE(eventItem1->eventList.at(2).type, QEvent::UngrabMouse);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
eventItem1->eventList.clear();
// touch button
p1 = QPoint(10, 310);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QTest::touchEvent(&window, device).press(0, p1, &window);
QQuickTouchUtils::flush(&window);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
QCOMPARE(eventItem2->eventList.size(), 1);
QCOMPARE(eventItem2->eventList.at(0).type, QEvent::TouchBegin);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QTest::touchEvent(&window, device).release(0, p1, &window);
QQuickTouchUtils::flush(&window);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
QCOMPARE(eventItem2->eventList.size(), 2);
QCOMPARE(eventItem2->eventList.at(1).type, QEvent::TouchEnd);
QCOMPARE(eventItem1->eventList.size(), 0);
eventItem2->eventList.clear();
// wait to avoid getting a double click event
QTest::qWait(qApp->styleHints()->mouseDoubleClickInterval() + 10);
// click above button, no events please
p1 = QPoint(10, 90);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QTest::touchEvent(&window, device).press(0, p1, &window);
QQuickTouchUtils::flush(&window);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
QCOMPARE(eventItem1->eventList.size(), 0);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QTest::touchEvent(&window, device).release(0, p1, &window);
QQuickTouchUtils::flush(&window);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
QCOMPARE(eventItem1->eventList.size(), 0);
eventItem1->eventList.clear();
// wait to avoid getting a double click event
QTest::qWait(qApp->styleHints()->mouseDoubleClickInterval() + 10);
// check that flickable moves - mouse button
QCOMPARE(eventItem1->eventList.size(), 0);
p1 = QPoint(10, 110);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QTest::touchEvent(&window, device).press(0, p1, &window);
QQuickTouchUtils::flush(&window);
Don't synthesize mouse from touch for items that accept touch 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>
2020-09-30 17:36:09 +00:00
QCOMPARE(eventItem1->eventList.size(), 1);
QCOMPARE(eventItem1->eventList.at(0).type, QEvent::MouseButtonPress);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QQuickWindowPrivate *windowPriv = QQuickWindowPrivate::get(&window);
Move event delivery from QQWindow to QQuickDeliveryAgent QQuickWindow owns QQuickRootItem which owns QQuickDeliveryAgent, so for every window there's an object responsible for event delivery, while the window itself is mainly responsible for rendering (separation of concerns). However, QQuickRootItem and QQuickDeliveryAgent can now be used in cases where the scene doesn't directly belong to a window, such as when a Qt Quick sub-scene is mapped somewhere into a Qt Quick 3D scene. In that case, we must remember which delivery agent was in use at the time when a QEventPoint is grabbed and deliver subsequent updates via the same DA. There's also a QQuickDeliveryAgent::Transform abstraction which subscene-management code (such as QQuick3DViewport) can implement, to provide a formula to map the window's scene coordinates to subscene coordinates; if defined, it will be used during delivery of subsequent updates to existing grabbers. Task-number: QTBUG-84870 Change-Id: I70b433f7ebb05d2e60214ff3192e05da0aa84a42 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
2020-07-14 18:09:57 +00:00
QVERIFY(windowPriv->deliveryAgentPrivate()->touchMouseId != -1);
Remove QQuickPointerEvent etc.; deliver QPointerEvents directly QEventPoint does not have an accessor to get the QPointerEvent that it came from, because that's inconsistent with the idea that QPointerEvent instances are temporary, stack-allocated and movable (the pointer would often be wrong or null, therefore could not be relied upon). So most functions that worked directly with QQuickEventPoint before (which fortunately are still private API) now need to receive the QPointerEvent too, which we choose to pass by pointer. QEventPoint is always passed by reference (const where possible) to be consistent with functions in QPointerEvent that take QEventPoint by reference. QEventPoint::velocity() should be always in scene coordinates now, which saves us the trouble of transforming it to each item's coordinate system during delivery, but means that it will need to be done in handlers or applications sometimes. If we were going to transform it, it would be important to also store the sceneVelocity separately in QEventPoint so that the transformation could be done repeatedly for different items. Task-number: QTBUG-72173 Change-Id: I7ee164d2e6893c4e407fb7d579c75aa32843933a Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
2020-07-23 11:56:26 +00:00
auto devPriv = QPointingDevicePrivate::get(device);
QCOMPARE(devPriv->pointById(0)->exclusiveGrabber, eventItem1);
QCOMPARE(grabMonitor.exclusiveGrabber, eventItem1);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
When stealing a touchpoint as synth. mouse, ungrab touch If you use MultiPointTouchArea to make a button component, or if you do something similar by subclassing QQuickItem and handling touch events, and you place such a component inside a Flickable, when the user presses on the button and then drags far enough that the Flickable steals the grab, the MPTA or custom item did not receive the touchUngrabEvent() callback. Now it does, so now the button will go back to released state as a result of having the grab stolen. The situation here is special in that it's the only place where a touch event is transformed to be treated as mouse in the future, usually it's either treated as touch or mouse from the start. When this happens, it's not enough to call setMouseGrabber because that doesn't send touch cancel to the previous grabber. Instead we need to explicitly call touchUngrabEvent to notify the touch handling item. The explicit setting of the grabber which was there previously is not needed, since grabMouse will update the grab based on touchMouseId. tst_QQuickMultiPointTouchArea::inFlickable2 was already testing the pressed state of the touchpoint when the grab is stolen, but it was changed in 468626e99a90d6ac21cb311cde05c658ccb3b781; now that can be restored, and we can also un-blacklist inFlickable, which was deemed unstable in 6d163779711d4601931ae0f82910794fb2498136 [ChangeLog][QtQuick] MultiPointTouchArea, and any custom Item, will now properly receive touchUngrabEvent() when the touch grab is stolen by a filtering parent Item, such as a Flickable. Task-number: QTBUG-57910 Change-Id: I4e1b23ed099f01e7eca2e8a0e7ab4c652ef00cfa Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2017-01-05 15:16:43 +00:00
int dragDelta = -qApp->styleHints()->startDragDistance();
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
Don't synthesize mouse from touch for items that accept touch 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>
2020-09-30 17:36:09 +00:00
// Start dragging; eventually, Flickable steals the grab
int i = 0;
for (; i < 10 && !flickable->isMovingVertically(); ++i) {
p1 += QPoint(0, dragDelta);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QTest::touchEvent(&window, device).move(0, p1, &window);
QQuickTouchUtils::flush(&window);
Don't synthesize mouse from touch for items that accept touch 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>
2020-09-30 17:36:09 +00:00
}
QVERIFY(flickable->isMovingVertically());
qCDebug(lcTests) << "flickable started moving after" << i << "moves, when we got to" << p1;
QCOMPARE(eventItem1->eventList.size(), 4);
QCOMPARE(eventItem1->eventList.at(2).type, QEvent::MouseMove);
QCOMPARE(eventItem1->eventList.at(3).type, QEvent::UngrabMouse);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
Remove QQuickPointerEvent etc.; deliver QPointerEvents directly QEventPoint does not have an accessor to get the QPointerEvent that it came from, because that's inconsistent with the idea that QPointerEvent instances are temporary, stack-allocated and movable (the pointer would often be wrong or null, therefore could not be relied upon). So most functions that worked directly with QQuickEventPoint before (which fortunately are still private API) now need to receive the QPointerEvent too, which we choose to pass by pointer. QEventPoint is always passed by reference (const where possible) to be consistent with functions in QPointerEvent that take QEventPoint by reference. QEventPoint::velocity() should be always in scene coordinates now, which saves us the trouble of transforming it to each item's coordinate system during delivery, but means that it will need to be done in handlers or applications sometimes. If we were going to transform it, it would be important to also store the sceneVelocity separately in QEventPoint so that the transformation could be done repeatedly for different items. Task-number: QTBUG-72173 Change-Id: I7ee164d2e6893c4e407fb7d579c75aa32843933a Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
2020-07-23 11:56:26 +00:00
QCOMPARE(grabMonitor.exclusiveGrabber, flickable);
Move event delivery from QQWindow to QQuickDeliveryAgent QQuickWindow owns QQuickRootItem which owns QQuickDeliveryAgent, so for every window there's an object responsible for event delivery, while the window itself is mainly responsible for rendering (separation of concerns). However, QQuickRootItem and QQuickDeliveryAgent can now be used in cases where the scene doesn't directly belong to a window, such as when a Qt Quick sub-scene is mapped somewhere into a Qt Quick 3D scene. In that case, we must remember which delivery agent was in use at the time when a QEventPoint is grabbed and deliver subsequent updates via the same DA. There's also a QQuickDeliveryAgent::Transform abstraction which subscene-management code (such as QQuick3DViewport) can implement, to provide a formula to map the window's scene coordinates to subscene coordinates; if defined, it will be used during delivery of subsequent updates to existing grabbers. Task-number: QTBUG-84870 Change-Id: I70b433f7ebb05d2e60214ff3192e05da0aa84a42 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
2020-07-14 18:09:57 +00:00
QVERIFY(windowPriv->deliveryAgentPrivate()->touchMouseId != -1);
Remove QQuickPointerEvent etc.; deliver QPointerEvents directly QEventPoint does not have an accessor to get the QPointerEvent that it came from, because that's inconsistent with the idea that QPointerEvent instances are temporary, stack-allocated and movable (the pointer would often be wrong or null, therefore could not be relied upon). So most functions that worked directly with QQuickEventPoint before (which fortunately are still private API) now need to receive the QPointerEvent too, which we choose to pass by pointer. QEventPoint is always passed by reference (const where possible) to be consistent with functions in QPointerEvent that take QEventPoint by reference. QEventPoint::velocity() should be always in scene coordinates now, which saves us the trouble of transforming it to each item's coordinate system during delivery, but means that it will need to be done in handlers or applications sometimes. If we were going to transform it, it would be important to also store the sceneVelocity separately in QEventPoint so that the transformation could be done repeatedly for different items. Task-number: QTBUG-72173 Change-Id: I7ee164d2e6893c4e407fb7d579c75aa32843933a Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
2020-07-23 11:56:26 +00:00
QCOMPARE(devPriv->pointById(0)->exclusiveGrabber, flickable);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QTest::touchEvent(&window, device).release(0, p1, &window);
QQuickTouchUtils::flush(&window);
When stealing a touchpoint as synth. mouse, ungrab touch If you use MultiPointTouchArea to make a button component, or if you do something similar by subclassing QQuickItem and handling touch events, and you place such a component inside a Flickable, when the user presses on the button and then drags far enough that the Flickable steals the grab, the MPTA or custom item did not receive the touchUngrabEvent() callback. Now it does, so now the button will go back to released state as a result of having the grab stolen. The situation here is special in that it's the only place where a touch event is transformed to be treated as mouse in the future, usually it's either treated as touch or mouse from the start. When this happens, it's not enough to call setMouseGrabber because that doesn't send touch cancel to the previous grabber. Instead we need to explicitly call touchUngrabEvent to notify the touch handling item. The explicit setting of the grabber which was there previously is not needed, since grabMouse will update the grab based on touchMouseId. tst_QQuickMultiPointTouchArea::inFlickable2 was already testing the pressed state of the touchpoint when the grab is stolen, but it was changed in 468626e99a90d6ac21cb311cde05c658ccb3b781; now that can be restored, and we can also un-blacklist inFlickable, which was deemed unstable in 6d163779711d4601931ae0f82910794fb2498136 [ChangeLog][QtQuick] MultiPointTouchArea, and any custom Item, will now properly receive touchUngrabEvent() when the touch grab is stolen by a filtering parent Item, such as a Flickable. Task-number: QTBUG-57910 Change-Id: I4e1b23ed099f01e7eca2e8a0e7ab4c652ef00cfa Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2017-01-05 15:16:43 +00:00
}
void tst_TouchMouse::touchButtonOnFlickable()
{
// flickable - height 500 / 1000
// - eventItem1 y: 100, height 100
// - eventItem2 y: 300, height 100
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QQuickView window;
QVERIFY(QQuickTest::showView(window, testFileUrl("buttononflickable.qml")));
When stealing a touchpoint as synth. mouse, ungrab touch If you use MultiPointTouchArea to make a button component, or if you do something similar by subclassing QQuickItem and handling touch events, and you place such a component inside a Flickable, when the user presses on the button and then drags far enough that the Flickable steals the grab, the MPTA or custom item did not receive the touchUngrabEvent() callback. Now it does, so now the button will go back to released state as a result of having the grab stolen. The situation here is special in that it's the only place where a touch event is transformed to be treated as mouse in the future, usually it's either treated as touch or mouse from the start. When this happens, it's not enough to call setMouseGrabber because that doesn't send touch cancel to the previous grabber. Instead we need to explicitly call touchUngrabEvent to notify the touch handling item. The explicit setting of the grabber which was there previously is not needed, since grabMouse will update the grab based on touchMouseId. tst_QQuickMultiPointTouchArea::inFlickable2 was already testing the pressed state of the touchpoint when the grab is stolen, but it was changed in 468626e99a90d6ac21cb311cde05c658ccb3b781; now that can be restored, and we can also un-blacklist inFlickable, which was deemed unstable in 6d163779711d4601931ae0f82910794fb2498136 [ChangeLog][QtQuick] MultiPointTouchArea, and any custom Item, will now properly receive touchUngrabEvent() when the touch grab is stolen by a filtering parent Item, such as a Flickable. Task-number: QTBUG-57910 Change-Id: I4e1b23ed099f01e7eca2e8a0e7ab4c652ef00cfa Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2017-01-05 15:16:43 +00:00
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QQuickFlickable *flickable = window.rootObject()->findChild<QQuickFlickable*>("flickable");
When stealing a touchpoint as synth. mouse, ungrab touch If you use MultiPointTouchArea to make a button component, or if you do something similar by subclassing QQuickItem and handling touch events, and you place such a component inside a Flickable, when the user presses on the button and then drags far enough that the Flickable steals the grab, the MPTA or custom item did not receive the touchUngrabEvent() callback. Now it does, so now the button will go back to released state as a result of having the grab stolen. The situation here is special in that it's the only place where a touch event is transformed to be treated as mouse in the future, usually it's either treated as touch or mouse from the start. When this happens, it's not enough to call setMouseGrabber because that doesn't send touch cancel to the previous grabber. Instead we need to explicitly call touchUngrabEvent to notify the touch handling item. The explicit setting of the grabber which was there previously is not needed, since grabMouse will update the grab based on touchMouseId. tst_QQuickMultiPointTouchArea::inFlickable2 was already testing the pressed state of the touchpoint when the grab is stolen, but it was changed in 468626e99a90d6ac21cb311cde05c658ccb3b781; now that can be restored, and we can also un-blacklist inFlickable, which was deemed unstable in 6d163779711d4601931ae0f82910794fb2498136 [ChangeLog][QtQuick] MultiPointTouchArea, and any custom Item, will now properly receive touchUngrabEvent() when the touch grab is stolen by a filtering parent Item, such as a Flickable. Task-number: QTBUG-57910 Change-Id: I4e1b23ed099f01e7eca2e8a0e7ab4c652ef00cfa Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2017-01-05 15:16:43 +00:00
QVERIFY(flickable);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
EventItem *eventItem2 = window.rootObject()->findChild<EventItem*>("eventItem2");
When stealing a touchpoint as synth. mouse, ungrab touch If you use MultiPointTouchArea to make a button component, or if you do something similar by subclassing QQuickItem and handling touch events, and you place such a component inside a Flickable, when the user presses on the button and then drags far enough that the Flickable steals the grab, the MPTA or custom item did not receive the touchUngrabEvent() callback. Now it does, so now the button will go back to released state as a result of having the grab stolen. The situation here is special in that it's the only place where a touch event is transformed to be treated as mouse in the future, usually it's either treated as touch or mouse from the start. When this happens, it's not enough to call setMouseGrabber because that doesn't send touch cancel to the previous grabber. Instead we need to explicitly call touchUngrabEvent to notify the touch handling item. The explicit setting of the grabber which was there previously is not needed, since grabMouse will update the grab based on touchMouseId. tst_QQuickMultiPointTouchArea::inFlickable2 was already testing the pressed state of the touchpoint when the grab is stolen, but it was changed in 468626e99a90d6ac21cb311cde05c658ccb3b781; now that can be restored, and we can also un-blacklist inFlickable, which was deemed unstable in 6d163779711d4601931ae0f82910794fb2498136 [ChangeLog][QtQuick] MultiPointTouchArea, and any custom Item, will now properly receive touchUngrabEvent() when the touch grab is stolen by a filtering parent Item, such as a Flickable. Task-number: QTBUG-57910 Change-Id: I4e1b23ed099f01e7eca2e8a0e7ab4c652ef00cfa Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2017-01-05 15:16:43 +00:00
QVERIFY(eventItem2);
QCOMPARE(eventItem2->eventList.size(), 0);
eventItem2->acceptTouch = true;
Don't synthesize mouse from touch for items that accept touch 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>
2020-09-30 17:36:09 +00:00
eventItem2->setAcceptTouchEvents(true);
When stealing a touchpoint as synth. mouse, ungrab touch If you use MultiPointTouchArea to make a button component, or if you do something similar by subclassing QQuickItem and handling touch events, and you place such a component inside a Flickable, when the user presses on the button and then drags far enough that the Flickable steals the grab, the MPTA or custom item did not receive the touchUngrabEvent() callback. Now it does, so now the button will go back to released state as a result of having the grab stolen. The situation here is special in that it's the only place where a touch event is transformed to be treated as mouse in the future, usually it's either treated as touch or mouse from the start. When this happens, it's not enough to call setMouseGrabber because that doesn't send touch cancel to the previous grabber. Instead we need to explicitly call touchUngrabEvent to notify the touch handling item. The explicit setting of the grabber which was there previously is not needed, since grabMouse will update the grab based on touchMouseId. tst_QQuickMultiPointTouchArea::inFlickable2 was already testing the pressed state of the touchpoint when the grab is stolen, but it was changed in 468626e99a90d6ac21cb311cde05c658ccb3b781; now that can be restored, and we can also un-blacklist inFlickable, which was deemed unstable in 6d163779711d4601931ae0f82910794fb2498136 [ChangeLog][QtQuick] MultiPointTouchArea, and any custom Item, will now properly receive touchUngrabEvent() when the touch grab is stolen by a filtering parent Item, such as a Flickable. Task-number: QTBUG-57910 Change-Id: I4e1b23ed099f01e7eca2e8a0e7ab4c652ef00cfa Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2017-01-05 15:16:43 +00:00
// press via touch, then drag: check that flickable moves and that the button gets ungrabbed
QCOMPARE(eventItem2->eventList.size(), 0);
QPoint p1 = QPoint(10, 310);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QTest::touchEvent(&window, device).press(0, p1, &window);
QQuickTouchUtils::flush(&window);
When stealing a touchpoint as synth. mouse, ungrab touch If you use MultiPointTouchArea to make a button component, or if you do something similar by subclassing QQuickItem and handling touch events, and you place such a component inside a Flickable, when the user presses on the button and then drags far enough that the Flickable steals the grab, the MPTA or custom item did not receive the touchUngrabEvent() callback. Now it does, so now the button will go back to released state as a result of having the grab stolen. The situation here is special in that it's the only place where a touch event is transformed to be treated as mouse in the future, usually it's either treated as touch or mouse from the start. When this happens, it's not enough to call setMouseGrabber because that doesn't send touch cancel to the previous grabber. Instead we need to explicitly call touchUngrabEvent to notify the touch handling item. The explicit setting of the grabber which was there previously is not needed, since grabMouse will update the grab based on touchMouseId. tst_QQuickMultiPointTouchArea::inFlickable2 was already testing the pressed state of the touchpoint when the grab is stolen, but it was changed in 468626e99a90d6ac21cb311cde05c658ccb3b781; now that can be restored, and we can also un-blacklist inFlickable, which was deemed unstable in 6d163779711d4601931ae0f82910794fb2498136 [ChangeLog][QtQuick] MultiPointTouchArea, and any custom Item, will now properly receive touchUngrabEvent() when the touch grab is stolen by a filtering parent Item, such as a Flickable. Task-number: QTBUG-57910 Change-Id: I4e1b23ed099f01e7eca2e8a0e7ab4c652ef00cfa Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2017-01-05 15:16:43 +00:00
QCOMPARE(eventItem2->eventList.size(), 1);
QCOMPARE(eventItem2->eventList.at(0).type, QEvent::TouchBegin);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QQuickWindowPrivate *windowPriv = QQuickWindowPrivate::get(&window);
Move event delivery from QQWindow to QQuickDeliveryAgent QQuickWindow owns QQuickRootItem which owns QQuickDeliveryAgent, so for every window there's an object responsible for event delivery, while the window itself is mainly responsible for rendering (separation of concerns). However, QQuickRootItem and QQuickDeliveryAgent can now be used in cases where the scene doesn't directly belong to a window, such as when a Qt Quick sub-scene is mapped somewhere into a Qt Quick 3D scene. In that case, we must remember which delivery agent was in use at the time when a QEventPoint is grabbed and deliver subsequent updates via the same DA. There's also a QQuickDeliveryAgent::Transform abstraction which subscene-management code (such as QQuick3DViewport) can implement, to provide a formula to map the window's scene coordinates to subscene coordinates; if defined, it will be used during delivery of subsequent updates to existing grabbers. Task-number: QTBUG-84870 Change-Id: I70b433f7ebb05d2e60214ff3192e05da0aa84a42 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
2020-07-14 18:09:57 +00:00
QVERIFY(windowPriv->deliveryAgentPrivate()->touchMouseId == -1);
Remove QQuickPointerEvent etc.; deliver QPointerEvents directly QEventPoint does not have an accessor to get the QPointerEvent that it came from, because that's inconsistent with the idea that QPointerEvent instances are temporary, stack-allocated and movable (the pointer would often be wrong or null, therefore could not be relied upon). So most functions that worked directly with QQuickEventPoint before (which fortunately are still private API) now need to receive the QPointerEvent too, which we choose to pass by pointer. QEventPoint is always passed by reference (const where possible) to be consistent with functions in QPointerEvent that take QEventPoint by reference. QEventPoint::velocity() should be always in scene coordinates now, which saves us the trouble of transforming it to each item's coordinate system during delivery, but means that it will need to be done in handlers or applications sometimes. If we were going to transform it, it would be important to also store the sceneVelocity separately in QEventPoint so that the transformation could be done repeatedly for different items. Task-number: QTBUG-72173 Change-Id: I7ee164d2e6893c4e407fb7d579c75aa32843933a Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
2020-07-23 11:56:26 +00:00
auto devPriv = QPointingDevicePrivate::get(device);
QCOMPARE(devPriv->pointById(0)->exclusiveGrabber, eventItem2);
QCOMPARE(grabMonitor.exclusiveGrabber, eventItem2);
When stealing a touchpoint as synth. mouse, ungrab touch If you use MultiPointTouchArea to make a button component, or if you do something similar by subclassing QQuickItem and handling touch events, and you place such a component inside a Flickable, when the user presses on the button and then drags far enough that the Flickable steals the grab, the MPTA or custom item did not receive the touchUngrabEvent() callback. Now it does, so now the button will go back to released state as a result of having the grab stolen. The situation here is special in that it's the only place where a touch event is transformed to be treated as mouse in the future, usually it's either treated as touch or mouse from the start. When this happens, it's not enough to call setMouseGrabber because that doesn't send touch cancel to the previous grabber. Instead we need to explicitly call touchUngrabEvent to notify the touch handling item. The explicit setting of the grabber which was there previously is not needed, since grabMouse will update the grab based on touchMouseId. tst_QQuickMultiPointTouchArea::inFlickable2 was already testing the pressed state of the touchpoint when the grab is stolen, but it was changed in 468626e99a90d6ac21cb311cde05c658ccb3b781; now that can be restored, and we can also un-blacklist inFlickable, which was deemed unstable in 6d163779711d4601931ae0f82910794fb2498136 [ChangeLog][QtQuick] MultiPointTouchArea, and any custom Item, will now properly receive touchUngrabEvent() when the touch grab is stolen by a filtering parent Item, such as a Flickable. Task-number: QTBUG-57910 Change-Id: I4e1b23ed099f01e7eca2e8a0e7ab4c652ef00cfa Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2017-01-05 15:16:43 +00:00
int dragDelta = qApp->styleHints()->startDragDistance() * -0.7;
p1 += QPoint(0, dragDelta);
QPoint p2 = p1 + QPoint(0, dragDelta);
QPoint p3 = p2 + QPoint(0, dragDelta);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QQuickTouchUtils::flush(&window);
QTest::touchEvent(&window, device).move(0, p1, &window);
QQuickTouchUtils::flush(&window);
QTest::touchEvent(&window, device).move(0, p2, &window);
QQuickTouchUtils::flush(&window);
QTest::touchEvent(&window, device).move(0, p3, &window);
QQuickTouchUtils::flush(&window);
When stealing a touchpoint as synth. mouse, ungrab touch If you use MultiPointTouchArea to make a button component, or if you do something similar by subclassing QQuickItem and handling touch events, and you place such a component inside a Flickable, when the user presses on the button and then drags far enough that the Flickable steals the grab, the MPTA or custom item did not receive the touchUngrabEvent() callback. Now it does, so now the button will go back to released state as a result of having the grab stolen. The situation here is special in that it's the only place where a touch event is transformed to be treated as mouse in the future, usually it's either treated as touch or mouse from the start. When this happens, it's not enough to call setMouseGrabber because that doesn't send touch cancel to the previous grabber. Instead we need to explicitly call touchUngrabEvent to notify the touch handling item. The explicit setting of the grabber which was there previously is not needed, since grabMouse will update the grab based on touchMouseId. tst_QQuickMultiPointTouchArea::inFlickable2 was already testing the pressed state of the touchpoint when the grab is stolen, but it was changed in 468626e99a90d6ac21cb311cde05c658ccb3b781; now that can be restored, and we can also un-blacklist inFlickable, which was deemed unstable in 6d163779711d4601931ae0f82910794fb2498136 [ChangeLog][QtQuick] MultiPointTouchArea, and any custom Item, will now properly receive touchUngrabEvent() when the touch grab is stolen by a filtering parent Item, such as a Flickable. Task-number: QTBUG-57910 Change-Id: I4e1b23ed099f01e7eca2e8a0e7ab4c652ef00cfa Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2017-01-05 15:16:43 +00:00
stabilize tst_TouchMouse::touchButtonOnFlickable FAIL! : tst_TouchMouse::touchButtonOnFlickable() Compared values are not the same Actual (eventItem2->touchUngrabCount): 0 Expected (1) : 1 tst_touchmouse.cpp(673) : failure location Task-number: QTBUG-66278 Change-Id: I20ed910091b7c894aeaf6639d738105022730940 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io> Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
2018-03-02 12:56:03 +00:00
QTRY_COMPARE(eventItem2->touchUngrabCount, 1);
Don't synthesize mouse from touch for items that accept touch 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>
2020-09-30 17:36:09 +00:00
qCDebug(lcTests) << "expected delivered events: press(touch) move(touch)" << eventItem2->eventList;
QCOMPARE(eventItem2->eventList.size(), 2);
When stealing a touchpoint as synth. mouse, ungrab touch If you use MultiPointTouchArea to make a button component, or if you do something similar by subclassing QQuickItem and handling touch events, and you place such a component inside a Flickable, when the user presses on the button and then drags far enough that the Flickable steals the grab, the MPTA or custom item did not receive the touchUngrabEvent() callback. Now it does, so now the button will go back to released state as a result of having the grab stolen. The situation here is special in that it's the only place where a touch event is transformed to be treated as mouse in the future, usually it's either treated as touch or mouse from the start. When this happens, it's not enough to call setMouseGrabber because that doesn't send touch cancel to the previous grabber. Instead we need to explicitly call touchUngrabEvent to notify the touch handling item. The explicit setting of the grabber which was there previously is not needed, since grabMouse will update the grab based on touchMouseId. tst_QQuickMultiPointTouchArea::inFlickable2 was already testing the pressed state of the touchpoint when the grab is stolen, but it was changed in 468626e99a90d6ac21cb311cde05c658ccb3b781; now that can be restored, and we can also un-blacklist inFlickable, which was deemed unstable in 6d163779711d4601931ae0f82910794fb2498136 [ChangeLog][QtQuick] MultiPointTouchArea, and any custom Item, will now properly receive touchUngrabEvent() when the touch grab is stolen by a filtering parent Item, such as a Flickable. Task-number: QTBUG-57910 Change-Id: I4e1b23ed099f01e7eca2e8a0e7ab4c652ef00cfa Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2017-01-05 15:16:43 +00:00
QCOMPARE(eventItem2->eventList.at(1).type, QEvent::TouchUpdate);
Remove QQuickPointerEvent etc.; deliver QPointerEvents directly QEventPoint does not have an accessor to get the QPointerEvent that it came from, because that's inconsistent with the idea that QPointerEvent instances are temporary, stack-allocated and movable (the pointer would often be wrong or null, therefore could not be relied upon). So most functions that worked directly with QQuickEventPoint before (which fortunately are still private API) now need to receive the QPointerEvent too, which we choose to pass by pointer. QEventPoint is always passed by reference (const where possible) to be consistent with functions in QPointerEvent that take QEventPoint by reference. QEventPoint::velocity() should be always in scene coordinates now, which saves us the trouble of transforming it to each item's coordinate system during delivery, but means that it will need to be done in handlers or applications sometimes. If we were going to transform it, it would be important to also store the sceneVelocity separately in QEventPoint so that the transformation could be done repeatedly for different items. Task-number: QTBUG-72173 Change-Id: I7ee164d2e6893c4e407fb7d579c75aa32843933a Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
2020-07-23 11:56:26 +00:00
QCOMPARE(grabMonitor.exclusiveGrabber, flickable);
Don't synthesize mouse from touch for items that accept touch 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>
2020-09-30 17:36:09 +00:00
// both EventItem and Flickable handled the actual touch, so synth-mouse doesn't happen
Move event delivery from QQWindow to QQuickDeliveryAgent QQuickWindow owns QQuickRootItem which owns QQuickDeliveryAgent, so for every window there's an object responsible for event delivery, while the window itself is mainly responsible for rendering (separation of concerns). However, QQuickRootItem and QQuickDeliveryAgent can now be used in cases where the scene doesn't directly belong to a window, such as when a Qt Quick sub-scene is mapped somewhere into a Qt Quick 3D scene. In that case, we must remember which delivery agent was in use at the time when a QEventPoint is grabbed and deliver subsequent updates via the same DA. There's also a QQuickDeliveryAgent::Transform abstraction which subscene-management code (such as QQuick3DViewport) can implement, to provide a formula to map the window's scene coordinates to subscene coordinates; if defined, it will be used during delivery of subsequent updates to existing grabbers. Task-number: QTBUG-84870 Change-Id: I70b433f7ebb05d2e60214ff3192e05da0aa84a42 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
2020-07-14 18:09:57 +00:00
QCOMPARE(windowPriv->deliveryAgentPrivate()->touchMouseId, -1);
Remove QQuickPointerEvent etc.; deliver QPointerEvents directly QEventPoint does not have an accessor to get the QPointerEvent that it came from, because that's inconsistent with the idea that QPointerEvent instances are temporary, stack-allocated and movable (the pointer would often be wrong or null, therefore could not be relied upon). So most functions that worked directly with QQuickEventPoint before (which fortunately are still private API) now need to receive the QPointerEvent too, which we choose to pass by pointer. QEventPoint is always passed by reference (const where possible) to be consistent with functions in QPointerEvent that take QEventPoint by reference. QEventPoint::velocity() should be always in scene coordinates now, which saves us the trouble of transforming it to each item's coordinate system during delivery, but means that it will need to be done in handlers or applications sometimes. If we were going to transform it, it would be important to also store the sceneVelocity separately in QEventPoint so that the transformation could be done repeatedly for different items. Task-number: QTBUG-72173 Change-Id: I7ee164d2e6893c4e407fb7d579c75aa32843933a Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
2020-07-23 11:56:26 +00:00
QCOMPARE(devPriv->pointById(0)->exclusiveGrabber, flickable);
When stealing a touchpoint as synth. mouse, ungrab touch If you use MultiPointTouchArea to make a button component, or if you do something similar by subclassing QQuickItem and handling touch events, and you place such a component inside a Flickable, when the user presses on the button and then drags far enough that the Flickable steals the grab, the MPTA or custom item did not receive the touchUngrabEvent() callback. Now it does, so now the button will go back to released state as a result of having the grab stolen. The situation here is special in that it's the only place where a touch event is transformed to be treated as mouse in the future, usually it's either treated as touch or mouse from the start. When this happens, it's not enough to call setMouseGrabber because that doesn't send touch cancel to the previous grabber. Instead we need to explicitly call touchUngrabEvent to notify the touch handling item. The explicit setting of the grabber which was there previously is not needed, since grabMouse will update the grab based on touchMouseId. tst_QQuickMultiPointTouchArea::inFlickable2 was already testing the pressed state of the touchpoint when the grab is stolen, but it was changed in 468626e99a90d6ac21cb311cde05c658ccb3b781; now that can be restored, and we can also un-blacklist inFlickable, which was deemed unstable in 6d163779711d4601931ae0f82910794fb2498136 [ChangeLog][QtQuick] MultiPointTouchArea, and any custom Item, will now properly receive touchUngrabEvent() when the touch grab is stolen by a filtering parent Item, such as a Flickable. Task-number: QTBUG-57910 Change-Id: I4e1b23ed099f01e7eca2e8a0e7ab4c652ef00cfa Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2017-01-05 15:16:43 +00:00
QVERIFY(flickable->isMovingVertically());
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QTest::touchEvent(&window, device).release(0, p3, &window);
QQuickTouchUtils::flush(&window);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
}
Fix behavior of Flickable::setPressDelay This expands the test and fixes the code. Before this patch, items would see the press event, but get the press stolen again immediately. Change-Id: Iece1d5ffbc09a98fb4bec8d810c7ad78b0f50afe Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2016-10-03 15:04:00 +00:00
void tst_TouchMouse::buttonOnDelayedPressFlickable_data()
{
QTest::addColumn<bool>("scrollBeforeDelayIsOver");
Amend TouchMouse::buttonOnDelayedPressFlickable to test delayed tap This test is for Flickable with pressDelay set to a testable timeout value. For some reason it only checked trying to flick before the press delay is over, or holding and waiting for the press delay to expire. But if the user taps a child MouseArea before the press delay expires (neither moving nor waiting), at the moment of release it's supposed to send the delayed press and then the release, so that the MouseArea gets "clicked" almost as if there was no delay. Lack of test coverage allowed a regression in this functionality for 2 minor versions: 5.10 and 5.11. Task-number: QTBUG-61144 Task-number: QTBUG-69059 Change-Id: I0d8867587e6877359c41ec5fc3a5cdd17447d0b8 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2018-10-02 07:34:05 +00:00
QTest::addColumn<bool>("releaseBeforeDelayIsOver");
Fix behavior of Flickable::setPressDelay This expands the test and fixes the code. Before this patch, items would see the press event, but get the press stolen again immediately. Change-Id: Iece1d5ffbc09a98fb4bec8d810c7ad78b0f50afe Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2016-10-03 15:04:00 +00:00
// the item should never see the event,
// due to the pressDelay which never delivers if we start moving
Amend TouchMouse::buttonOnDelayedPressFlickable to test delayed tap This test is for Flickable with pressDelay set to a testable timeout value. For some reason it only checked trying to flick before the press delay is over, or holding and waiting for the press delay to expire. But if the user taps a child MouseArea before the press delay expires (neither moving nor waiting), at the moment of release it's supposed to send the delayed press and then the release, so that the MouseArea gets "clicked" almost as if there was no delay. Lack of test coverage allowed a regression in this functionality for 2 minor versions: 5.10 and 5.11. Task-number: QTBUG-61144 Task-number: QTBUG-69059 Change-Id: I0d8867587e6877359c41ec5fc3a5cdd17447d0b8 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2018-10-02 07:34:05 +00:00
QTest::newRow("scroll before press delay is over") << true << false;
// after release, the item should see the press and release via event replay (QTBUG-61144)
QTest::newRow("release before press delay is over") << false << true;
Fix behavior of Flickable::setPressDelay This expands the test and fixes the code. Before this patch, items would see the press event, but get the press stolen again immediately. Change-Id: Iece1d5ffbc09a98fb4bec8d810c7ad78b0f50afe Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2016-10-03 15:04:00 +00:00
// wait until the "button" sees the press but then
// start moving: the button gets a press and cancel event
Amend TouchMouse::buttonOnDelayedPressFlickable to test delayed tap This test is for Flickable with pressDelay set to a testable timeout value. For some reason it only checked trying to flick before the press delay is over, or holding and waiting for the press delay to expire. But if the user taps a child MouseArea before the press delay expires (neither moving nor waiting), at the moment of release it's supposed to send the delayed press and then the release, so that the MouseArea gets "clicked" almost as if there was no delay. Lack of test coverage allowed a regression in this functionality for 2 minor versions: 5.10 and 5.11. Task-number: QTBUG-61144 Task-number: QTBUG-69059 Change-Id: I0d8867587e6877359c41ec5fc3a5cdd17447d0b8 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2018-10-02 07:34:05 +00:00
QTest::newRow("scroll after press delay is over") << false << false;
Fix behavior of Flickable::setPressDelay This expands the test and fixes the code. Before this patch, items would see the press event, but get the press stolen again immediately. Change-Id: Iece1d5ffbc09a98fb4bec8d810c7ad78b0f50afe Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2016-10-03 15:04:00 +00:00
}
Fix touch to mouse synthesis/propagation. Having mouse events synthesised from both QtGui and internally in QtQuick is not a great way togo about things, especially when QtGui doesn't have the same degree of knowledge as QtQuick about the items in the scene. Thus, we now accept all events inside QtQuick to block QtGui synthesis, which should fix a significant amount of edge-case touch breakage/bad behavior. Change-Id: I14e1c87761c8f43160049b5e6f9da15b4e5edbb7 Done-with: Martin Jones <martin.jones@jollamobile.com> Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
2013-11-13 11:41:19 +00:00
void tst_TouchMouse::buttonOnDelayedPressFlickable()
{
// flickable - height 500 / 1000
// - eventItem1 y: 100, height 100
// - eventItem2 y: 300, height 100
Fix behavior of Flickable::setPressDelay This expands the test and fixes the code. Before this patch, items would see the press event, but get the press stolen again immediately. Change-Id: Iece1d5ffbc09a98fb4bec8d810c7ad78b0f50afe Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2016-10-03 15:04:00 +00:00
QFETCH(bool, scrollBeforeDelayIsOver);
Amend TouchMouse::buttonOnDelayedPressFlickable to test delayed tap This test is for Flickable with pressDelay set to a testable timeout value. For some reason it only checked trying to flick before the press delay is over, or holding and waiting for the press delay to expire. But if the user taps a child MouseArea before the press delay expires (neither moving nor waiting), at the moment of release it's supposed to send the delayed press and then the release, so that the MouseArea gets "clicked" almost as if there was no delay. Lack of test coverage allowed a regression in this functionality for 2 minor versions: 5.10 and 5.11. Task-number: QTBUG-61144 Task-number: QTBUG-69059 Change-Id: I0d8867587e6877359c41ec5fc3a5cdd17447d0b8 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2018-10-02 07:34:05 +00:00
QFETCH(bool, releaseBeforeDelayIsOver);
Teach flickable to handle and replay touch as it does mouse QQuickWindowPrivate::cloneMouseEvent() renamed to clonePointerEvent() and generalized to be able to clone any of the kinds of QPointerEvent that we're interested in replaying. Now it is used only in QQuickFlickablePrivate::captureDelayedPress(). Reverts f278bb7c66bb00c9f81b7a3aceeb94cb9b3a1b66 and 012a4528a515af8d7ec7dbc05a38d8fd0d6d4d1b (don't skip tst_TouchMouse::buttonOnDelayedPressFlickable). Some test changes from f128b5dee8a2a03ebc55ed0cd1e749a6599282c3 also get reverted. QEventPoint should always have valid velocity now, so Flickable no longer has to calculate it for itself. Removing that became necessary to fix the movingAndFlicking test. Adds logging categories qt.quick.flickable.filter and .replay. Fixes: QTBUG-85607 Task-number: QTBUG-83437 Task-number: QTBUG-78818 Task-number: QTBUG-61144 Task-number: QTBUG-88038 Task-number: QTBUG-88138 Change-Id: I0ed6802dff5e5d1595adddc389642925f1f2c93d Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
2020-09-30 17:35:26 +00:00
const int threshold = qApp->styleHints()->startDragDistance();
Skip tst_TouchMouse::buttonOnDelayedPressFlickable on macOS Change-Id: I1b1b5d00ae8bef77ad63f8df5ec893b045e21923 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2020-09-15 10:55:05 +00:00
Fix touch to mouse synthesis/propagation. Having mouse events synthesised from both QtGui and internally in QtQuick is not a great way togo about things, especially when QtGui doesn't have the same degree of knowledge as QtQuick about the items in the scene. Thus, we now accept all events inside QtQuick to block QtGui synthesis, which should fix a significant amount of edge-case touch breakage/bad behavior. Change-Id: I14e1c87761c8f43160049b5e6f9da15b4e5edbb7 Done-with: Martin Jones <martin.jones@jollamobile.com> Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
2013-11-13 11:41:19 +00:00
qApp->setAttribute(Qt::AA_SynthesizeMouseForUnhandledTouchEvents, true);
filteredEventList.clear();
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QQuickView window;
QVERIFY(QQuickTest::showView(window, testFileUrl("buttononflickable.qml")));
Fix touch to mouse synthesis/propagation. Having mouse events synthesised from both QtGui and internally in QtQuick is not a great way togo about things, especially when QtGui doesn't have the same degree of knowledge as QtQuick about the items in the scene. Thus, we now accept all events inside QtQuick to block QtGui synthesis, which should fix a significant amount of edge-case touch breakage/bad behavior. Change-Id: I14e1c87761c8f43160049b5e6f9da15b4e5edbb7 Done-with: Martin Jones <martin.jones@jollamobile.com> Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
2013-11-13 11:41:19 +00:00
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QQuickFlickable *flickable = window.rootObject()->findChild<QQuickFlickable*>("flickable");
Fix touch to mouse synthesis/propagation. Having mouse events synthesised from both QtGui and internally in QtQuick is not a great way togo about things, especially when QtGui doesn't have the same degree of knowledge as QtQuick about the items in the scene. Thus, we now accept all events inside QtQuick to block QtGui synthesis, which should fix a significant amount of edge-case touch breakage/bad behavior. Change-Id: I14e1c87761c8f43160049b5e6f9da15b4e5edbb7 Done-with: Martin Jones <martin.jones@jollamobile.com> Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
2013-11-13 11:41:19 +00:00
QVERIFY(flickable);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
window.installEventFilter(this);
Fix touch to mouse synthesis/propagation. Having mouse events synthesised from both QtGui and internally in QtQuick is not a great way togo about things, especially when QtGui doesn't have the same degree of knowledge as QtQuick about the items in the scene. Thus, we now accept all events inside QtQuick to block QtGui synthesis, which should fix a significant amount of edge-case touch breakage/bad behavior. Change-Id: I14e1c87761c8f43160049b5e6f9da15b4e5edbb7 Done-with: Martin Jones <martin.jones@jollamobile.com> Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
2013-11-13 11:41:19 +00:00
Fix behavior of Flickable::setPressDelay This expands the test and fixes the code. Before this patch, items would see the press event, but get the press stolen again immediately. Change-Id: Iece1d5ffbc09a98fb4bec8d810c7ad78b0f50afe Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2016-10-03 15:04:00 +00:00
// wait 600 ms before letting the child see the press event
flickable->setPressDelay(600);
Fix touch to mouse synthesis/propagation. Having mouse events synthesised from both QtGui and internally in QtQuick is not a great way togo about things, especially when QtGui doesn't have the same degree of knowledge as QtQuick about the items in the scene. Thus, we now accept all events inside QtQuick to block QtGui synthesis, which should fix a significant amount of edge-case touch breakage/bad behavior. Change-Id: I14e1c87761c8f43160049b5e6f9da15b4e5edbb7 Done-with: Martin Jones <martin.jones@jollamobile.com> Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
2013-11-13 11:41:19 +00:00
// should a mouse area button be clickable on top of flickable? yes :)
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
EventItem *eventItem1 = window.rootObject()->findChild<EventItem*>("eventItem1");
Fix touch to mouse synthesis/propagation. Having mouse events synthesised from both QtGui and internally in QtQuick is not a great way togo about things, especially when QtGui doesn't have the same degree of knowledge as QtQuick about the items in the scene. Thus, we now accept all events inside QtQuick to block QtGui synthesis, which should fix a significant amount of edge-case touch breakage/bad behavior. Change-Id: I14e1c87761c8f43160049b5e6f9da15b4e5edbb7 Done-with: Martin Jones <martin.jones@jollamobile.com> Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
2013-11-13 11:41:19 +00:00
QVERIFY(eventItem1);
eventItem1->setAcceptedMouseButtons(Qt::LeftButton);
eventItem1->acceptMouse = true;
// should a touch button be touchable on top of flickable? yes :)
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
EventItem *eventItem2 = window.rootObject()->findChild<EventItem*>("eventItem2");
Fix touch to mouse synthesis/propagation. Having mouse events synthesised from both QtGui and internally in QtQuick is not a great way togo about things, especially when QtGui doesn't have the same degree of knowledge as QtQuick about the items in the scene. Thus, we now accept all events inside QtQuick to block QtGui synthesis, which should fix a significant amount of edge-case touch breakage/bad behavior. Change-Id: I14e1c87761c8f43160049b5e6f9da15b4e5edbb7 Done-with: Martin Jones <martin.jones@jollamobile.com> Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
2013-11-13 11:41:19 +00:00
QVERIFY(eventItem2);
QCOMPARE(eventItem2->eventList.size(), 0);
eventItem2->acceptTouch = true;
// wait to avoid getting a double click event
QTest::qWait(qApp->styleHints()->mouseDoubleClickInterval() + 10);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QQuickWindowPrivate *windowPriv = QQuickWindowPrivate::get(&window);
Move event delivery from QQWindow to QQuickDeliveryAgent QQuickWindow owns QQuickRootItem which owns QQuickDeliveryAgent, so for every window there's an object responsible for event delivery, while the window itself is mainly responsible for rendering (separation of concerns). However, QQuickRootItem and QQuickDeliveryAgent can now be used in cases where the scene doesn't directly belong to a window, such as when a Qt Quick sub-scene is mapped somewhere into a Qt Quick 3D scene. In that case, we must remember which delivery agent was in use at the time when a QEventPoint is grabbed and deliver subsequent updates via the same DA. There's also a QQuickDeliveryAgent::Transform abstraction which subscene-management code (such as QQuick3DViewport) can implement, to provide a formula to map the window's scene coordinates to subscene coordinates; if defined, it will be used during delivery of subsequent updates to existing grabbers. Task-number: QTBUG-84870 Change-Id: I70b433f7ebb05d2e60214ff3192e05da0aa84a42 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
2020-07-14 18:09:57 +00:00
QCOMPARE(windowPriv->deliveryAgentPrivate()->touchMouseId, -1); // no grabber
Fix touch to mouse synthesis/propagation. Having mouse events synthesised from both QtGui and internally in QtQuick is not a great way togo about things, especially when QtGui doesn't have the same degree of knowledge as QtQuick about the items in the scene. Thus, we now accept all events inside QtQuick to block QtGui synthesis, which should fix a significant amount of edge-case touch breakage/bad behavior. Change-Id: I14e1c87761c8f43160049b5e6f9da15b4e5edbb7 Done-with: Martin Jones <martin.jones@jollamobile.com> Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
2013-11-13 11:41:19 +00:00
Fix behavior of Flickable::setPressDelay This expands the test and fixes the code. Before this patch, items would see the press event, but get the press stolen again immediately. Change-Id: Iece1d5ffbc09a98fb4bec8d810c7ad78b0f50afe Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2016-10-03 15:04:00 +00:00
// touch press
Fix touch to mouse synthesis/propagation. Having mouse events synthesised from both QtGui and internally in QtQuick is not a great way togo about things, especially when QtGui doesn't have the same degree of knowledge as QtQuick about the items in the scene. Thus, we now accept all events inside QtQuick to block QtGui synthesis, which should fix a significant amount of edge-case touch breakage/bad behavior. Change-Id: I14e1c87761c8f43160049b5e6f9da15b4e5edbb7 Done-with: Martin Jones <martin.jones@jollamobile.com> Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
2013-11-13 11:41:19 +00:00
QPoint p1 = QPoint(10, 110);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QTest::touchEvent(&window, device).press(0, p1, &window);
QQuickTouchUtils::flush(&window);
Fix touch to mouse synthesis/propagation. Having mouse events synthesised from both QtGui and internally in QtQuick is not a great way togo about things, especially when QtGui doesn't have the same degree of knowledge as QtQuick about the items in the scene. Thus, we now accept all events inside QtQuick to block QtGui synthesis, which should fix a significant amount of edge-case touch breakage/bad behavior. Change-Id: I14e1c87761c8f43160049b5e6f9da15b4e5edbb7 Done-with: Martin Jones <martin.jones@jollamobile.com> Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
2013-11-13 11:41:19 +00:00
Amend TouchMouse::buttonOnDelayedPressFlickable to test delayed tap This test is for Flickable with pressDelay set to a testable timeout value. For some reason it only checked trying to flick before the press delay is over, or holding and waiting for the press delay to expire. But if the user taps a child MouseArea before the press delay expires (neither moving nor waiting), at the moment of release it's supposed to send the delayed press and then the release, so that the MouseArea gets "clicked" almost as if there was no delay. Lack of test coverage allowed a regression in this functionality for 2 minor versions: 5.10 and 5.11. Task-number: QTBUG-61144 Task-number: QTBUG-69059 Change-Id: I0d8867587e6877359c41ec5fc3a5cdd17447d0b8 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2018-10-02 07:34:05 +00:00
if (scrollBeforeDelayIsOver || releaseBeforeDelayIsOver) {
// no events yet: press is delayed
Fix behavior of Flickable::setPressDelay This expands the test and fixes the code. Before this patch, items would see the press event, but get the press stolen again immediately. Change-Id: Iece1d5ffbc09a98fb4bec8d810c7ad78b0f50afe Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2016-10-03 15:04:00 +00:00
QCOMPARE(eventItem1->eventList.size(), 0);
} else {
// wait until the button sees the press
Don't synthesize mouse from touch for items that accept touch 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>
2020-09-30 17:36:09 +00:00
qCDebug(lcTests) << "expected delivered events: press(mouse)" << eventItem1->eventList;
qCDebug(lcTests) << "expected filtered events: actual TouchBegin and replayed TouchBegin" << filteredEventList;
QTRY_COMPARE(eventItem1->eventList.size(), 1);
QCOMPARE(eventItem1->eventList.at(0).type, QEvent::MouseButtonPress);
Port from container::count() and length() to size() This is a semantic patch using ClangTidyTransformator as in qtbase/df9d882d41b741fef7c5beeddb0abe9d904443d8: auto QtContainerClass = anyOf( expr(hasType(cxxRecordDecl(isSameOrDerivedFrom(hasAnyName(classes))))).bind(o), expr(hasType(namedDecl(hasAnyName(<classes>)))).bind(o)); makeRule(cxxMemberCallExpr(on(QtContainerClass), callee(cxxMethodDecl(hasAnyName({"count", "length"), parameterCountIs(0))))), changeTo(cat(access(o, cat("size"), "()"))), cat("use 'size()' instead of 'count()/length()'")) a.k.a qt-port-to-std-compatible-api with config Scope: 'Container', with the extended set of container classes recognized. Change-Id: Idb1f75dfe2323bd1d9e8b4d58d54f1b4b80c7ed7 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
2022-10-05 05:29:16 +00:00
QCOMPARE(filteredEventList.size(), 2); // actual touch begin and replayed touch begin
Fix behavior of Flickable::setPressDelay This expands the test and fixes the code. Before this patch, items would see the press event, but get the press stolen again immediately. Change-Id: Iece1d5ffbc09a98fb4bec8d810c7ad78b0f50afe Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2016-10-03 15:04:00 +00:00
}
Fix touch to mouse synthesis/propagation. Having mouse events synthesised from both QtGui and internally in QtQuick is not a great way togo about things, especially when QtGui doesn't have the same degree of knowledge as QtQuick about the items in the scene. Thus, we now accept all events inside QtQuick to block QtGui synthesis, which should fix a significant amount of edge-case touch breakage/bad behavior. Change-Id: I14e1c87761c8f43160049b5e6f9da15b4e5edbb7 Done-with: Martin Jones <martin.jones@jollamobile.com> Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
2013-11-13 11:41:19 +00:00
Amend TouchMouse::buttonOnDelayedPressFlickable to test delayed tap This test is for Flickable with pressDelay set to a testable timeout value. For some reason it only checked trying to flick before the press delay is over, or holding and waiting for the press delay to expire. But if the user taps a child MouseArea before the press delay expires (neither moving nor waiting), at the moment of release it's supposed to send the delayed press and then the release, so that the MouseArea gets "clicked" almost as if there was no delay. Lack of test coverage allowed a regression in this functionality for 2 minor versions: 5.10 and 5.11. Task-number: QTBUG-61144 Task-number: QTBUG-69059 Change-Id: I0d8867587e6877359c41ec5fc3a5cdd17447d0b8 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2018-10-02 07:34:05 +00:00
if (!releaseBeforeDelayIsOver) {
// move the touchpoint: try to flick
Teach flickable to handle and replay touch as it does mouse QQuickWindowPrivate::cloneMouseEvent() renamed to clonePointerEvent() and generalized to be able to clone any of the kinds of QPointerEvent that we're interested in replaying. Now it is used only in QQuickFlickablePrivate::captureDelayedPress(). Reverts f278bb7c66bb00c9f81b7a3aceeb94cb9b3a1b66 and 012a4528a515af8d7ec7dbc05a38d8fd0d6d4d1b (don't skip tst_TouchMouse::buttonOnDelayedPressFlickable). Some test changes from f128b5dee8a2a03ebc55ed0cd1e749a6599282c3 also get reverted. QEventPoint should always have valid velocity now, so Flickable no longer has to calculate it for itself. Removing that became necessary to fix the movingAndFlicking test. Adds logging categories qt.quick.flickable.filter and .replay. Fixes: QTBUG-85607 Task-number: QTBUG-83437 Task-number: QTBUG-78818 Task-number: QTBUG-61144 Task-number: QTBUG-88038 Task-number: QTBUG-88138 Change-Id: I0ed6802dff5e5d1595adddc389642925f1f2c93d Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
2020-09-30 17:35:26 +00:00
for (int i = 0; i < 3; ++i) {
p1 += QPoint(0, -threshold);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QTest::touchEvent(&window, device).move(0, p1, &window);
QQuickTouchUtils::flush(&window);
Teach flickable to handle and replay touch as it does mouse QQuickWindowPrivate::cloneMouseEvent() renamed to clonePointerEvent() and generalized to be able to clone any of the kinds of QPointerEvent that we're interested in replaying. Now it is used only in QQuickFlickablePrivate::captureDelayedPress(). Reverts f278bb7c66bb00c9f81b7a3aceeb94cb9b3a1b66 and 012a4528a515af8d7ec7dbc05a38d8fd0d6d4d1b (don't skip tst_TouchMouse::buttonOnDelayedPressFlickable). Some test changes from f128b5dee8a2a03ebc55ed0cd1e749a6599282c3 also get reverted. QEventPoint should always have valid velocity now, so Flickable no longer has to calculate it for itself. Removing that became necessary to fix the movingAndFlicking test. Adds logging categories qt.quick.flickable.filter and .replay. Fixes: QTBUG-85607 Task-number: QTBUG-83437 Task-number: QTBUG-78818 Task-number: QTBUG-61144 Task-number: QTBUG-88038 Task-number: QTBUG-88138 Change-Id: I0ed6802dff5e5d1595adddc389642925f1f2c93d Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
2020-09-30 17:35:26 +00:00
}
Amend TouchMouse::buttonOnDelayedPressFlickable to test delayed tap This test is for Flickable with pressDelay set to a testable timeout value. For some reason it only checked trying to flick before the press delay is over, or holding and waiting for the press delay to expire. But if the user taps a child MouseArea before the press delay expires (neither moving nor waiting), at the moment of release it's supposed to send the delayed press and then the release, so that the MouseArea gets "clicked" almost as if there was no delay. Lack of test coverage allowed a regression in this functionality for 2 minor versions: 5.10 and 5.11. Task-number: QTBUG-61144 Task-number: QTBUG-69059 Change-Id: I0d8867587e6877359c41ec5fc3a5cdd17447d0b8 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2018-10-02 07:34:05 +00:00
QTRY_VERIFY(flickable->isMovingVertically());
if (scrollBeforeDelayIsOver) {
QCOMPARE(eventItem1->eventList.size(), 0);
Teach flickable to handle and replay touch as it does mouse QQuickWindowPrivate::cloneMouseEvent() renamed to clonePointerEvent() and generalized to be able to clone any of the kinds of QPointerEvent that we're interested in replaying. Now it is used only in QQuickFlickablePrivate::captureDelayedPress(). Reverts f278bb7c66bb00c9f81b7a3aceeb94cb9b3a1b66 and 012a4528a515af8d7ec7dbc05a38d8fd0d6d4d1b (don't skip tst_TouchMouse::buttonOnDelayedPressFlickable). Some test changes from f128b5dee8a2a03ebc55ed0cd1e749a6599282c3 also get reverted. QEventPoint should always have valid velocity now, so Flickable no longer has to calculate it for itself. Removing that became necessary to fix the movingAndFlicking test. Adds logging categories qt.quick.flickable.filter and .replay. Fixes: QTBUG-85607 Task-number: QTBUG-83437 Task-number: QTBUG-78818 Task-number: QTBUG-61144 Task-number: QTBUG-88038 Task-number: QTBUG-88138 Change-Id: I0ed6802dff5e5d1595adddc389642925f1f2c93d Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
2020-09-30 17:35:26 +00:00
qCDebug(lcTests) << "expected filtered events: 1 TouchBegin and 3 TouchUpdate" << filteredEventList;
Port from container::count() and length() to size() This is a semantic patch using ClangTidyTransformator as in qtbase/df9d882d41b741fef7c5beeddb0abe9d904443d8: auto QtContainerClass = anyOf( expr(hasType(cxxRecordDecl(isSameOrDerivedFrom(hasAnyName(classes))))).bind(o), expr(hasType(namedDecl(hasAnyName(<classes>)))).bind(o)); makeRule(cxxMemberCallExpr(on(QtContainerClass), callee(cxxMethodDecl(hasAnyName({"count", "length"), parameterCountIs(0))))), changeTo(cat(access(o, cat("size"), "()"))), cat("use 'size()' instead of 'count()/length()'")) a.k.a qt-port-to-std-compatible-api with config Scope: 'Container', with the extended set of container classes recognized. Change-Id: Idb1f75dfe2323bd1d9e8b4d58d54f1b4b80c7ed7 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
2022-10-05 05:29:16 +00:00
QCOMPARE(filteredEventList.size(), 4);
Amend TouchMouse::buttonOnDelayedPressFlickable to test delayed tap This test is for Flickable with pressDelay set to a testable timeout value. For some reason it only checked trying to flick before the press delay is over, or holding and waiting for the press delay to expire. But if the user taps a child MouseArea before the press delay expires (neither moving nor waiting), at the moment of release it's supposed to send the delayed press and then the release, so that the MouseArea gets "clicked" almost as if there was no delay. Lack of test coverage allowed a regression in this functionality for 2 minor versions: 5.10 and 5.11. Task-number: QTBUG-61144 Task-number: QTBUG-69059 Change-Id: I0d8867587e6877359c41ec5fc3a5cdd17447d0b8 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2018-10-02 07:34:05 +00:00
} else {
Don't synthesize mouse from touch for items that accept touch 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>
2020-09-30 17:36:09 +00:00
qCDebug(lcTests) << "expected delivered events: press(mouse), move(mouse), move(mouse), ungrab(mouse)" << eventItem1->eventList;
QCOMPARE(eventItem1->eventList.size(), 4);
QCOMPARE(eventItem1->eventList.at(0).type, QEvent::MouseButtonPress);
QCOMPARE(eventItem1->eventList.at(1).type, QEvent::MouseMove);
Amend TouchMouse::buttonOnDelayedPressFlickable to test delayed tap This test is for Flickable with pressDelay set to a testable timeout value. For some reason it only checked trying to flick before the press delay is over, or holding and waiting for the press delay to expire. But if the user taps a child MouseArea before the press delay expires (neither moving nor waiting), at the moment of release it's supposed to send the delayed press and then the release, so that the MouseArea gets "clicked" almost as if there was no delay. Lack of test coverage allowed a regression in this functionality for 2 minor versions: 5.10 and 5.11. Task-number: QTBUG-61144 Task-number: QTBUG-69059 Change-Id: I0d8867587e6877359c41ec5fc3a5cdd17447d0b8 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2018-10-02 07:34:05 +00:00
QCOMPARE(eventItem1->eventList.last().type, QEvent::UngrabMouse);
Teach flickable to handle and replay touch as it does mouse QQuickWindowPrivate::cloneMouseEvent() renamed to clonePointerEvent() and generalized to be able to clone any of the kinds of QPointerEvent that we're interested in replaying. Now it is used only in QQuickFlickablePrivate::captureDelayedPress(). Reverts f278bb7c66bb00c9f81b7a3aceeb94cb9b3a1b66 and 012a4528a515af8d7ec7dbc05a38d8fd0d6d4d1b (don't skip tst_TouchMouse::buttonOnDelayedPressFlickable). Some test changes from f128b5dee8a2a03ebc55ed0cd1e749a6599282c3 also get reverted. QEventPoint should always have valid velocity now, so Flickable no longer has to calculate it for itself. Removing that became necessary to fix the movingAndFlicking test. Adds logging categories qt.quick.flickable.filter and .replay. Fixes: QTBUG-85607 Task-number: QTBUG-83437 Task-number: QTBUG-78818 Task-number: QTBUG-61144 Task-number: QTBUG-88038 Task-number: QTBUG-88138 Change-Id: I0ed6802dff5e5d1595adddc389642925f1f2c93d Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
2020-09-30 17:35:26 +00:00
qCDebug(lcTests) << "expected filtered events: 2 TouchBegin and 3 TouchUpdate" << filteredEventList;
Port from container::count() and length() to size() This is a semantic patch using ClangTidyTransformator as in qtbase/df9d882d41b741fef7c5beeddb0abe9d904443d8: auto QtContainerClass = anyOf( expr(hasType(cxxRecordDecl(isSameOrDerivedFrom(hasAnyName(classes))))).bind(o), expr(hasType(namedDecl(hasAnyName(<classes>)))).bind(o)); makeRule(cxxMemberCallExpr(on(QtContainerClass), callee(cxxMethodDecl(hasAnyName({"count", "length"), parameterCountIs(0))))), changeTo(cat(access(o, cat("size"), "()"))), cat("use 'size()' instead of 'count()/length()'")) a.k.a qt-port-to-std-compatible-api with config Scope: 'Container', with the extended set of container classes recognized. Change-Id: Idb1f75dfe2323bd1d9e8b4d58d54f1b4b80c7ed7 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
2022-10-05 05:29:16 +00:00
QCOMPARE(filteredEventList.size(), 5);
Amend TouchMouse::buttonOnDelayedPressFlickable to test delayed tap This test is for Flickable with pressDelay set to a testable timeout value. For some reason it only checked trying to flick before the press delay is over, or holding and waiting for the press delay to expire. But if the user taps a child MouseArea before the press delay expires (neither moving nor waiting), at the moment of release it's supposed to send the delayed press and then the release, so that the MouseArea gets "clicked" almost as if there was no delay. Lack of test coverage allowed a regression in this functionality for 2 minor versions: 5.10 and 5.11. Task-number: QTBUG-61144 Task-number: QTBUG-69059 Change-Id: I0d8867587e6877359c41ec5fc3a5cdd17447d0b8 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2018-10-02 07:34:05 +00:00
}
Fix behavior of Flickable::setPressDelay This expands the test and fixes the code. Before this patch, items would see the press event, but get the press stolen again immediately. Change-Id: Iece1d5ffbc09a98fb4bec8d810c7ad78b0f50afe Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2016-10-03 15:04:00 +00:00
Teach flickable to handle and replay touch as it does mouse QQuickWindowPrivate::cloneMouseEvent() renamed to clonePointerEvent() and generalized to be able to clone any of the kinds of QPointerEvent that we're interested in replaying. Now it is used only in QQuickFlickablePrivate::captureDelayedPress(). Reverts f278bb7c66bb00c9f81b7a3aceeb94cb9b3a1b66 and 012a4528a515af8d7ec7dbc05a38d8fd0d6d4d1b (don't skip tst_TouchMouse::buttonOnDelayedPressFlickable). Some test changes from f128b5dee8a2a03ebc55ed0cd1e749a6599282c3 also get reverted. QEventPoint should always have valid velocity now, so Flickable no longer has to calculate it for itself. Removing that became necessary to fix the movingAndFlicking test. Adds logging categories qt.quick.flickable.filter and .replay. Fixes: QTBUG-85607 Task-number: QTBUG-83437 Task-number: QTBUG-78818 Task-number: QTBUG-61144 Task-number: QTBUG-88038 Task-number: QTBUG-88138 Change-Id: I0ed6802dff5e5d1595adddc389642925f1f2c93d Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
2020-09-30 17:35:26 +00:00
// flickable should have the touchpoint grab: it no longer relies on synth-mouse
Remove QQuickPointerEvent etc.; deliver QPointerEvents directly QEventPoint does not have an accessor to get the QPointerEvent that it came from, because that's inconsistent with the idea that QPointerEvent instances are temporary, stack-allocated and movable (the pointer would often be wrong or null, therefore could not be relied upon). So most functions that worked directly with QQuickEventPoint before (which fortunately are still private API) now need to receive the QPointerEvent too, which we choose to pass by pointer. QEventPoint is always passed by reference (const where possible) to be consistent with functions in QPointerEvent that take QEventPoint by reference. QEventPoint::velocity() should be always in scene coordinates now, which saves us the trouble of transforming it to each item's coordinate system during delivery, but means that it will need to be done in handlers or applications sometimes. If we were going to transform it, it would be important to also store the sceneVelocity separately in QEventPoint so that the transformation could be done repeatedly for different items. Task-number: QTBUG-72173 Change-Id: I7ee164d2e6893c4e407fb7d579c75aa32843933a Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
2020-07-23 11:56:26 +00:00
QCOMPARE(grabMonitor.exclusiveGrabber, flickable);
auto devPriv = QPointingDevicePrivate::get(device);
QCOMPARE(devPriv->pointById(0)->exclusiveGrabber, flickable);
Fix behavior of Flickable::setPressDelay This expands the test and fixes the code. Before this patch, items would see the press event, but get the press stolen again immediately. Change-Id: Iece1d5ffbc09a98fb4bec8d810c7ad78b0f50afe Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2016-10-03 15:04:00 +00:00
}
Fix touch to mouse synthesis/propagation. Having mouse events synthesised from both QtGui and internally in QtQuick is not a great way togo about things, especially when QtGui doesn't have the same degree of knowledge as QtQuick about the items in the scene. Thus, we now accept all events inside QtQuick to block QtGui synthesis, which should fix a significant amount of edge-case touch breakage/bad behavior. Change-Id: I14e1c87761c8f43160049b5e6f9da15b4e5edbb7 Done-with: Martin Jones <martin.jones@jollamobile.com> Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
2013-11-13 11:41:19 +00:00
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QTest::touchEvent(&window, device).release(0, p1, &window);
QQuickTouchUtils::flush(&window);
Fix touch to mouse synthesis/propagation. Having mouse events synthesised from both QtGui and internally in QtQuick is not a great way togo about things, especially when QtGui doesn't have the same degree of knowledge as QtQuick about the items in the scene. Thus, we now accept all events inside QtQuick to block QtGui synthesis, which should fix a significant amount of edge-case touch breakage/bad behavior. Change-Id: I14e1c87761c8f43160049b5e6f9da15b4e5edbb7 Done-with: Martin Jones <martin.jones@jollamobile.com> Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
2013-11-13 11:41:19 +00:00
Amend TouchMouse::buttonOnDelayedPressFlickable to test delayed tap This test is for Flickable with pressDelay set to a testable timeout value. For some reason it only checked trying to flick before the press delay is over, or holding and waiting for the press delay to expire. But if the user taps a child MouseArea before the press delay expires (neither moving nor waiting), at the moment of release it's supposed to send the delayed press and then the release, so that the MouseArea gets "clicked" almost as if there was no delay. Lack of test coverage allowed a regression in this functionality for 2 minor versions: 5.10 and 5.11. Task-number: QTBUG-61144 Task-number: QTBUG-69059 Change-Id: I0d8867587e6877359c41ec5fc3a5cdd17447d0b8 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2018-10-02 07:34:05 +00:00
if (releaseBeforeDelayIsOver) {
// when the touchpoint was released, the child saw the delayed press and the release in sequence
Don't synthesize mouse from touch for items that accept touch 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>
2020-09-30 17:36:09 +00:00
qCDebug(lcTests) << "expected delivered events: press(mouse), release(mouse), ungrab" << eventItem1->eventList;
qCDebug(lcTests) << "expected filtered events: press(touch), release(touch), delayed press(touch), release (touch)" << filteredEventList;
QTRY_COMPARE(eventItem1->eventList.size(), 3);
QCOMPARE(eventItem1->eventList.at(0).type, QEvent::MouseButtonPress);
QCOMPARE(eventItem1->eventList.at(1).type, QEvent::MouseButtonRelease);
Amend TouchMouse::buttonOnDelayedPressFlickable to test delayed tap This test is for Flickable with pressDelay set to a testable timeout value. For some reason it only checked trying to flick before the press delay is over, or holding and waiting for the press delay to expire. But if the user taps a child MouseArea before the press delay expires (neither moving nor waiting), at the moment of release it's supposed to send the delayed press and then the release, so that the MouseArea gets "clicked" almost as if there was no delay. Lack of test coverage allowed a regression in this functionality for 2 minor versions: 5.10 and 5.11. Task-number: QTBUG-61144 Task-number: QTBUG-69059 Change-Id: I0d8867587e6877359c41ec5fc3a5cdd17447d0b8 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2018-10-02 07:34:05 +00:00
QCOMPARE(eventItem1->eventList.last().type, QEvent::UngrabMouse);
// QQuickWindow filters the delayed press and release
Port from container::count() and length() to size() This is a semantic patch using ClangTidyTransformator as in qtbase/df9d882d41b741fef7c5beeddb0abe9d904443d8: auto QtContainerClass = anyOf( expr(hasType(cxxRecordDecl(isSameOrDerivedFrom(hasAnyName(classes))))).bind(o), expr(hasType(namedDecl(hasAnyName(<classes>)))).bind(o)); makeRule(cxxMemberCallExpr(on(QtContainerClass), callee(cxxMethodDecl(hasAnyName({"count", "length"), parameterCountIs(0))))), changeTo(cat(access(o, cat("size"), "()"))), cat("use 'size()' instead of 'count()/length()'")) a.k.a qt-port-to-std-compatible-api with config Scope: 'Container', with the extended set of container classes recognized. Change-Id: Idb1f75dfe2323bd1d9e8b4d58d54f1b4b80c7ed7 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
2022-10-05 05:29:16 +00:00
QCOMPARE(filteredEventList.size(), 4);
QCOMPARE(filteredEventList.at(filteredEventList.size() - 2).type, QEvent::TouchBegin);
Teach flickable to handle and replay touch as it does mouse QQuickWindowPrivate::cloneMouseEvent() renamed to clonePointerEvent() and generalized to be able to clone any of the kinds of QPointerEvent that we're interested in replaying. Now it is used only in QQuickFlickablePrivate::captureDelayedPress(). Reverts f278bb7c66bb00c9f81b7a3aceeb94cb9b3a1b66 and 012a4528a515af8d7ec7dbc05a38d8fd0d6d4d1b (don't skip tst_TouchMouse::buttonOnDelayedPressFlickable). Some test changes from f128b5dee8a2a03ebc55ed0cd1e749a6599282c3 also get reverted. QEventPoint should always have valid velocity now, so Flickable no longer has to calculate it for itself. Removing that became necessary to fix the movingAndFlicking test. Adds logging categories qt.quick.flickable.filter and .replay. Fixes: QTBUG-85607 Task-number: QTBUG-83437 Task-number: QTBUG-78818 Task-number: QTBUG-61144 Task-number: QTBUG-88038 Task-number: QTBUG-88138 Change-Id: I0ed6802dff5e5d1595adddc389642925f1f2c93d Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
2020-09-30 17:35:26 +00:00
QCOMPARE(filteredEventList.last().type, QEvent::TouchEnd);
Amend TouchMouse::buttonOnDelayedPressFlickable to test delayed tap This test is for Flickable with pressDelay set to a testable timeout value. For some reason it only checked trying to flick before the press delay is over, or holding and waiting for the press delay to expire. But if the user taps a child MouseArea before the press delay expires (neither moving nor waiting), at the moment of release it's supposed to send the delayed press and then the release, so that the MouseArea gets "clicked" almost as if there was no delay. Lack of test coverage allowed a regression in this functionality for 2 minor versions: 5.10 and 5.11. Task-number: QTBUG-61144 Task-number: QTBUG-69059 Change-Id: I0d8867587e6877359c41ec5fc3a5cdd17447d0b8 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2018-10-02 07:34:05 +00:00
} else {
Teach flickable to handle and replay touch as it does mouse QQuickWindowPrivate::cloneMouseEvent() renamed to clonePointerEvent() and generalized to be able to clone any of the kinds of QPointerEvent that we're interested in replaying. Now it is used only in QQuickFlickablePrivate::captureDelayedPress(). Reverts f278bb7c66bb00c9f81b7a3aceeb94cb9b3a1b66 and 012a4528a515af8d7ec7dbc05a38d8fd0d6d4d1b (don't skip tst_TouchMouse::buttonOnDelayedPressFlickable). Some test changes from f128b5dee8a2a03ebc55ed0cd1e749a6599282c3 also get reverted. QEventPoint should always have valid velocity now, so Flickable no longer has to calculate it for itself. Removing that became necessary to fix the movingAndFlicking test. Adds logging categories qt.quick.flickable.filter and .replay. Fixes: QTBUG-85607 Task-number: QTBUG-83437 Task-number: QTBUG-78818 Task-number: QTBUG-61144 Task-number: QTBUG-88038 Task-number: QTBUG-88138 Change-Id: I0ed6802dff5e5d1595adddc389642925f1f2c93d Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
2020-09-30 17:35:26 +00:00
// QQuickWindow filters the delayed press if there was one
Amend TouchMouse::buttonOnDelayedPressFlickable to test delayed tap This test is for Flickable with pressDelay set to a testable timeout value. For some reason it only checked trying to flick before the press delay is over, or holding and waiting for the press delay to expire. But if the user taps a child MouseArea before the press delay expires (neither moving nor waiting), at the moment of release it's supposed to send the delayed press and then the release, so that the MouseArea gets "clicked" almost as if there was no delay. Lack of test coverage allowed a regression in this functionality for 2 minor versions: 5.10 and 5.11. Task-number: QTBUG-61144 Task-number: QTBUG-69059 Change-Id: I0d8867587e6877359c41ec5fc3a5cdd17447d0b8 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2018-10-02 07:34:05 +00:00
if (scrollBeforeDelayIsOver) {
Teach flickable to handle and replay touch as it does mouse QQuickWindowPrivate::cloneMouseEvent() renamed to clonePointerEvent() and generalized to be able to clone any of the kinds of QPointerEvent that we're interested in replaying. Now it is used only in QQuickFlickablePrivate::captureDelayedPress(). Reverts f278bb7c66bb00c9f81b7a3aceeb94cb9b3a1b66 and 012a4528a515af8d7ec7dbc05a38d8fd0d6d4d1b (don't skip tst_TouchMouse::buttonOnDelayedPressFlickable). Some test changes from f128b5dee8a2a03ebc55ed0cd1e749a6599282c3 also get reverted. QEventPoint should always have valid velocity now, so Flickable no longer has to calculate it for itself. Removing that became necessary to fix the movingAndFlicking test. Adds logging categories qt.quick.flickable.filter and .replay. Fixes: QTBUG-85607 Task-number: QTBUG-83437 Task-number: QTBUG-78818 Task-number: QTBUG-61144 Task-number: QTBUG-88038 Task-number: QTBUG-88138 Change-Id: I0ed6802dff5e5d1595adddc389642925f1f2c93d Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
2020-09-30 17:35:26 +00:00
qCDebug(lcTests) << "expected filtered events: 1 TouchBegin, 3 TouchUpdate, 1 TouchEnd" << filteredEventList;
Port from container::count() and length() to size() This is a semantic patch using ClangTidyTransformator as in qtbase/df9d882d41b741fef7c5beeddb0abe9d904443d8: auto QtContainerClass = anyOf( expr(hasType(cxxRecordDecl(isSameOrDerivedFrom(hasAnyName(classes))))).bind(o), expr(hasType(namedDecl(hasAnyName(<classes>)))).bind(o)); makeRule(cxxMemberCallExpr(on(QtContainerClass), callee(cxxMethodDecl(hasAnyName({"count", "length"), parameterCountIs(0))))), changeTo(cat(access(o, cat("size"), "()"))), cat("use 'size()' instead of 'count()/length()'")) a.k.a qt-port-to-std-compatible-api with config Scope: 'Container', with the extended set of container classes recognized. Change-Id: Idb1f75dfe2323bd1d9e8b4d58d54f1b4b80c7ed7 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
2022-10-05 05:29:16 +00:00
QCOMPARE(filteredEventList.size(), 5);
Amend TouchMouse::buttonOnDelayedPressFlickable to test delayed tap This test is for Flickable with pressDelay set to a testable timeout value. For some reason it only checked trying to flick before the press delay is over, or holding and waiting for the press delay to expire. But if the user taps a child MouseArea before the press delay expires (neither moving nor waiting), at the moment of release it's supposed to send the delayed press and then the release, so that the MouseArea gets "clicked" almost as if there was no delay. Lack of test coverage allowed a regression in this functionality for 2 minor versions: 5.10 and 5.11. Task-number: QTBUG-61144 Task-number: QTBUG-69059 Change-Id: I0d8867587e6877359c41ec5fc3a5cdd17447d0b8 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2018-10-02 07:34:05 +00:00
} else {
Teach flickable to handle and replay touch as it does mouse QQuickWindowPrivate::cloneMouseEvent() renamed to clonePointerEvent() and generalized to be able to clone any of the kinds of QPointerEvent that we're interested in replaying. Now it is used only in QQuickFlickablePrivate::captureDelayedPress(). Reverts f278bb7c66bb00c9f81b7a3aceeb94cb9b3a1b66 and 012a4528a515af8d7ec7dbc05a38d8fd0d6d4d1b (don't skip tst_TouchMouse::buttonOnDelayedPressFlickable). Some test changes from f128b5dee8a2a03ebc55ed0cd1e749a6599282c3 also get reverted. QEventPoint should always have valid velocity now, so Flickable no longer has to calculate it for itself. Removing that became necessary to fix the movingAndFlicking test. Adds logging categories qt.quick.flickable.filter and .replay. Fixes: QTBUG-85607 Task-number: QTBUG-83437 Task-number: QTBUG-78818 Task-number: QTBUG-61144 Task-number: QTBUG-88038 Task-number: QTBUG-88138 Change-Id: I0ed6802dff5e5d1595adddc389642925f1f2c93d Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
2020-09-30 17:35:26 +00:00
qCDebug(lcTests) << "expected filtered events: 2 TouchBegin, 3 TouchUpdate, 1 TouchEnd" << filteredEventList;
Port from container::count() and length() to size() This is a semantic patch using ClangTidyTransformator as in qtbase/df9d882d41b741fef7c5beeddb0abe9d904443d8: auto QtContainerClass = anyOf( expr(hasType(cxxRecordDecl(isSameOrDerivedFrom(hasAnyName(classes))))).bind(o), expr(hasType(namedDecl(hasAnyName(<classes>)))).bind(o)); makeRule(cxxMemberCallExpr(on(QtContainerClass), callee(cxxMethodDecl(hasAnyName({"count", "length"), parameterCountIs(0))))), changeTo(cat(access(o, cat("size"), "()"))), cat("use 'size()' instead of 'count()/length()'")) a.k.a qt-port-to-std-compatible-api with config Scope: 'Container', with the extended set of container classes recognized. Change-Id: Idb1f75dfe2323bd1d9e8b4d58d54f1b4b80c7ed7 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
2022-10-05 05:29:16 +00:00
QCOMPARE(filteredEventList.size(), 6);
Teach flickable to handle and replay touch as it does mouse QQuickWindowPrivate::cloneMouseEvent() renamed to clonePointerEvent() and generalized to be able to clone any of the kinds of QPointerEvent that we're interested in replaying. Now it is used only in QQuickFlickablePrivate::captureDelayedPress(). Reverts f278bb7c66bb00c9f81b7a3aceeb94cb9b3a1b66 and 012a4528a515af8d7ec7dbc05a38d8fd0d6d4d1b (don't skip tst_TouchMouse::buttonOnDelayedPressFlickable). Some test changes from f128b5dee8a2a03ebc55ed0cd1e749a6599282c3 also get reverted. QEventPoint should always have valid velocity now, so Flickable no longer has to calculate it for itself. Removing that became necessary to fix the movingAndFlicking test. Adds logging categories qt.quick.flickable.filter and .replay. Fixes: QTBUG-85607 Task-number: QTBUG-83437 Task-number: QTBUG-78818 Task-number: QTBUG-61144 Task-number: QTBUG-88038 Task-number: QTBUG-88138 Change-Id: I0ed6802dff5e5d1595adddc389642925f1f2c93d Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
2020-09-30 17:35:26 +00:00
QCOMPARE(filteredEventList.at(0).type, QEvent::TouchBegin);
QCOMPARE(filteredEventList.last().type, QEvent::TouchEnd);
Amend TouchMouse::buttonOnDelayedPressFlickable to test delayed tap This test is for Flickable with pressDelay set to a testable timeout value. For some reason it only checked trying to flick before the press delay is over, or holding and waiting for the press delay to expire. But if the user taps a child MouseArea before the press delay expires (neither moving nor waiting), at the moment of release it's supposed to send the delayed press and then the release, so that the MouseArea gets "clicked" almost as if there was no delay. Lack of test coverage allowed a regression in this functionality for 2 minor versions: 5.10 and 5.11. Task-number: QTBUG-61144 Task-number: QTBUG-69059 Change-Id: I0d8867587e6877359c41ec5fc3a5cdd17447d0b8 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2018-10-02 07:34:05 +00:00
}
}
Fix touch to mouse synthesis/propagation. Having mouse events synthesised from both QtGui and internally in QtQuick is not a great way togo about things, especially when QtGui doesn't have the same degree of knowledge as QtQuick about the items in the scene. Thus, we now accept all events inside QtQuick to block QtGui synthesis, which should fix a significant amount of edge-case touch breakage/bad behavior. Change-Id: I14e1c87761c8f43160049b5e6f9da15b4e5edbb7 Done-with: Martin Jones <martin.jones@jollamobile.com> Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
2013-11-13 11:41:19 +00:00
}
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
void tst_TouchMouse::buttonOnTouch()
{
// 400x800
// PinchArea - height 400
// - eventItem1 y: 100, height 100
// - eventItem2 y: 300, height 100
// MultiPointTouchArea - height 400
// - eventItem1 y: 100, height 100
// - eventItem2 y: 300, height 100
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QQuickView window;
QVERIFY(QQuickTest::showView(window, testFileUrl("buttonontouch.qml")));
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QQuickPinchArea *pinchArea = window.rootObject()->findChild<QQuickPinchArea*>("pincharea");
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
QVERIFY(pinchArea);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QQuickItem *button1 = window.rootObject()->findChild<QQuickItem*>("button1");
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
QVERIFY(button1);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
EventItem *eventItem1 = window.rootObject()->findChild<EventItem*>("eventItem1");
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
QVERIFY(eventItem1);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
EventItem *eventItem2 = window.rootObject()->findChild<EventItem*>("eventItem2");
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
QVERIFY(eventItem2);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QQuickMultiPointTouchArea *touchArea = window.rootObject()->findChild<QQuickMultiPointTouchArea*>("toucharea");
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
QVERIFY(touchArea);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
EventItem *eventItem3 = window.rootObject()->findChild<EventItem*>("eventItem3");
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
QVERIFY(eventItem3);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
EventItem *eventItem4 = window.rootObject()->findChild<EventItem*>("eventItem4");
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
QVERIFY(eventItem4);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QTest::QTouchEventSequence touchSeq = QTest::touchEvent(&window, device, false);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
// Test the common case of a mouse area on top of pinch
eventItem1->setAcceptedMouseButtons(Qt::LeftButton);
Don't synthesize mouse from touch for items that accept touch 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>
2020-09-30 17:36:09 +00:00
eventItem1->setAcceptTouchEvents(false);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
eventItem1->acceptMouse = true;
// wait to avoid getting a double click event
QTest::qWait(qApp->styleHints()->mouseDoubleClickInterval() + 10);
// Normal touch click
QPoint p1 = QPoint(10, 110);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
touchSeq.press(0, p1, &window).commit();
QQuickTouchUtils::flush(&window);
touchSeq.release(0, p1, &window).commit();
QQuickTouchUtils::flush(&window);
Don't synthesize mouse from touch for items that accept touch 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>
2020-09-30 17:36:09 +00:00
QCOMPARE(eventItem1->eventList.size(), 3);
QCOMPARE(eventItem1->eventList.at(0).type, QEvent::MouseButtonPress);
QCOMPARE(eventItem1->eventList.at(1).type, QEvent::MouseButtonRelease);
QCOMPARE(eventItem1->eventList.at(2).type, QEvent::UngrabMouse);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
eventItem1->eventList.clear();
// Normal mouse click
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QTest::mouseClick(&window, Qt::LeftButton, Qt::NoModifier, p1);
Remove mouse grabber if touch used for mouse emulation has been grabbed If an item grabs a touch that is currently being used for mouse pointer emulation, the current mouse grabber should lose the mouse as mouse events will no longer be generated from that touch point. Example of what happens without this patch: -User touches a MouseArea. It gets pressed. -Some other item grabs that touch. -This touch eventually ends. -The MouseArea would still be pressed. And what will happens instead after this patch: -User touches a MouseArea. It gets pressed. -Some other item grabs that touch. -The MouseArea gets canceled and released -This touch eventually ends. Change-Id: I24114f18be564553a4a768243bb20379affe7a8f Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
2014-10-10 19:54:39 +00:00
QCOMPARE(eventItem1->eventList.size(), 3);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
QCOMPARE(eventItem1->eventList.at(0).type, QEvent::MouseButtonPress);
QCOMPARE(eventItem1->eventList.at(1).type, QEvent::MouseButtonRelease);
Remove mouse grabber if touch used for mouse emulation has been grabbed If an item grabs a touch that is currently being used for mouse pointer emulation, the current mouse grabber should lose the mouse as mouse events will no longer be generated from that touch point. Example of what happens without this patch: -User touches a MouseArea. It gets pressed. -Some other item grabs that touch. -This touch eventually ends. -The MouseArea would still be pressed. And what will happens instead after this patch: -User touches a MouseArea. It gets pressed. -Some other item grabs that touch. -The MouseArea gets canceled and released -This touch eventually ends. Change-Id: I24114f18be564553a4a768243bb20379affe7a8f Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
2014-10-10 19:54:39 +00:00
QCOMPARE(eventItem1->eventList.at(2).type, QEvent::UngrabMouse);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
eventItem1->eventList.clear();
// Pinch starting on the PinchArea should work
p1 = QPoint(40, 10);
QPoint p2 = QPoint(60, 10);
// Start the events after each other
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
touchSeq.press(0, p1, &window).commit();
QQuickTouchUtils::flush(&window);
touchSeq.stationary(0).press(1, p2, &window).commit();
QQuickTouchUtils::flush(&window);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QCOMPARE(button1->scale(), 1);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
p1 -= QPoint(10, 0);
p2 += QPoint(10, 0);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
touchSeq.move(0, p1, &window).move(1, p2, &window).commit();
QQuickTouchUtils::flush(&window);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
p1 -= QPoint(10, 0);
p2 += QPoint(10, 0);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
touchSeq.move(0, p1, &window).move(1, p2, &window).commit();
QQuickTouchUtils::flush(&window);
QCOMPARE(button1->scale(), 1.5);
qCDebug(lcTests) << "Button scale: " << button1->scale();
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
p1 -= QPoint(10, 0);
p2 += QPoint(10, 0);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
touchSeq.move(0, p1, &window).move(1, p2, &window).commit();
QQuickTouchUtils::flush(&window);
QCOMPARE(button1->scale(), 2);
qCDebug(lcTests) << "Button scale: " << button1->scale();
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
touchSeq.release(0, p1, &window).release(1, p2, &window).commit();
QQuickTouchUtils::flush(&window);
QVERIFY(eventItem1->eventList.isEmpty());
QCOMPARE(button1->scale(), 2);
qCDebug(lcTests) << "Button scale: " << button1->scale();
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
// wait to avoid getting a double click event
QTest::qWait(qApp->styleHints()->mouseDoubleClickInterval() + 10);
// Start pinching while on the button
button1->setScale(1.0);
p1 = QPoint(40, 110);
p2 = QPoint(60, 110);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
touchSeq.press(0, p1, &window).press(1, p2, &window).commit();
QQuickTouchUtils::flush(&window);
QCOMPARE(button1->scale(), 1);
Port from container::count() and length() to size() This is a semantic patch using ClangTidyTransformator as in qtbase/df9d882d41b741fef7c5beeddb0abe9d904443d8: auto QtContainerClass = anyOf( expr(hasType(cxxRecordDecl(isSameOrDerivedFrom(hasAnyName(classes))))).bind(o), expr(hasType(namedDecl(hasAnyName(<classes>)))).bind(o)); makeRule(cxxMemberCallExpr(on(QtContainerClass), callee(cxxMethodDecl(hasAnyName({"count", "length"), parameterCountIs(0))))), changeTo(cat(access(o, cat("size"), "()"))), cat("use 'size()' instead of 'count()/length()'")) a.k.a qt-port-to-std-compatible-api with config Scope: 'Container', with the extended set of container classes recognized. Change-Id: Idb1f75dfe2323bd1d9e8b4d58d54f1b4b80c7ed7 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
2022-10-05 05:29:16 +00:00
QCOMPARE(eventItem1->eventList.size(), 1);
Don't synthesize mouse from touch for items that accept touch 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>
2020-09-30 17:36:09 +00:00
QCOMPARE(eventItem1->eventList.at(0).type, QEvent::MouseButtonPress);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
p1 -= QPoint(10, 0);
p2 += QPoint(10, 0);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
touchSeq.move(0, p1, &window).move(1, p2, &window).commit();
QQuickTouchUtils::flush(&window);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
p1 -= QPoint(10, 0);
p2 += QPoint(10, 0);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
touchSeq.move(0, p1, &window).move(1, p2, &window).commit();
QQuickTouchUtils::flush(&window);
qCDebug(lcTests) << "Button scale: " << button1->scale();
QEXPECT_FAIL("", "No pinch: eventItem1 grabbed both touchpoints", Continue);
QCOMPARE(button1->scale(), 1.5);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
p1 -= QPoint(10, 0);
p2 += QPoint(10, 0);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
touchSeq.move(0, p1, &window).move(1, p2, &window).commit();
QQuickTouchUtils::flush(&window);
qCDebug(lcTests) << "Button scale: " << button1->scale();
QEXPECT_FAIL("", "No pinch: eventItem1 grabbed both touchpoints", Continue);
QCOMPARE(button1->scale(), 2);
touchSeq.release(0, p1, &window).release(1, p2, &window).commit();
QQuickTouchUtils::flush(&window);
QCOMPARE(eventItem1->eventList.size(), 6);
qCDebug(lcTests) << "Button scale: " << button1->scale();
QEXPECT_FAIL("", "No pinch: eventItem1 grabbed both touchpoints", Continue);
QCOMPARE(button1->scale(), 2);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
}
void tst_TouchMouse::pinchOnFlickable()
{
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QQuickView window;
QVERIFY(QQuickTest::showView(window, testFileUrl("pinchonflickable.qml")));
Improve tst_TouchMouse::pinchOnFlickable - use for loops instead of tedious repetition - compare instead of verify to check negative bools - QTRY_COMPARE instead of qWait - move touchpoints by drag threshold to ensure repeatability: both flickable and pincharea wait for the threshold to start reacting Change-Id: I071fc05280e2156223af57d97079516987a744ab Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2020-10-28 08:36:33 +00:00
const int threshold = qApp->styleHints()->startDragDistance();
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QQuickPinchArea *pinchArea = window.rootObject()->findChild<QQuickPinchArea*>("pincharea");
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
QVERIFY(pinchArea);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QQuickFlickable *flickable = window.rootObject()->findChild<QQuickFlickable*>("flickable");
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
QVERIFY(flickable);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QQuickItem *rect = window.rootObject()->findChild<QQuickItem*>("rect");
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
QVERIFY(rect);
Improve tst_TouchMouse::pinchOnFlickable - use for loops instead of tedious repetition - compare instead of verify to check negative bools - QTRY_COMPARE instead of qWait - move touchpoints by drag threshold to ensure repeatability: both flickable and pincharea wait for the threshold to start reacting Change-Id: I071fc05280e2156223af57d97079516987a744ab Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2020-10-28 08:36:33 +00:00
// flick the flickable with one touchpoint
QCOMPARE(flickable->contentX(), 0);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
QPoint p = QPoint(100, 100);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QTest::touchEvent(&window, device).press(0, p, &window);
QQuickTouchUtils::flush(&window);
Improve tst_TouchMouse::pinchOnFlickable - use for loops instead of tedious repetition - compare instead of verify to check negative bools - QTRY_COMPARE instead of qWait - move touchpoints by drag threshold to ensure repeatability: both flickable and pincharea wait for the threshold to start reacting Change-Id: I071fc05280e2156223af57d97079516987a744ab Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2020-10-28 08:36:33 +00:00
QCOMPARE(rect->position(), QPointF(200, 200));
for (int i = 0; i < 4; ++i) {
p -= QPoint(threshold, 0);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QTest::touchEvent(&window, device).move(0, p, &window);
QQuickTouchUtils::flush(&window);
Improve tst_TouchMouse::pinchOnFlickable - use for loops instead of tedious repetition - compare instead of verify to check negative bools - QTRY_COMPARE instead of qWait - move touchpoints by drag threshold to ensure repeatability: both flickable and pincharea wait for the threshold to start reacting Change-Id: I071fc05280e2156223af57d97079516987a744ab Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2020-10-28 08:36:33 +00:00
if (!flickable->isAtXBeginning()) // currently happens when i == 3
qCDebug(lcTests, "flicking after %d moves: %lf", i + 1, flickable->contentX());
}
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QTest::touchEvent(&window, device).release(0, p, &window);
Improve tst_TouchMouse::pinchOnFlickable - use for loops instead of tedious repetition - compare instead of verify to check negative bools - QTRY_COMPARE instead of qWait - move touchpoints by drag threshold to ensure repeatability: both flickable and pincharea wait for the threshold to start reacting Change-Id: I071fc05280e2156223af57d97079516987a744ab Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2020-10-28 08:36:33 +00:00
QTRY_COMPARE(flickable->isAtXBeginning(), false);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
// wait until flicking is done
Improve tst_TouchMouse::pinchOnFlickable - use for loops instead of tedious repetition - compare instead of verify to check negative bools - QTRY_COMPARE instead of qWait - move touchpoints by drag threshold to ensure repeatability: both flickable and pincharea wait for the threshold to start reacting Change-Id: I071fc05280e2156223af57d97079516987a744ab Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2020-10-28 08:36:33 +00:00
QTRY_COMPARE(flickable->isFlicking(), false);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
Improve tst_TouchMouse::pinchOnFlickable - use for loops instead of tedious repetition - compare instead of verify to check negative bools - QTRY_COMPARE instead of qWait - move touchpoints by drag threshold to ensure repeatability: both flickable and pincharea wait for the threshold to start reacting Change-Id: I071fc05280e2156223af57d97079516987a744ab Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2020-10-28 08:36:33 +00:00
// pinch with two touchpoints
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
QPoint p1 = QPoint(40, 20);
QPoint p2 = QPoint(60, 20);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QTest::QTouchEventSequence pinchSequence = QTest::touchEvent(&window, device);
QQuickTouchUtils::flush(&window);
pinchSequence.press(0, p1, &window).commit();
QQuickTouchUtils::flush(&window);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
// In order for the stationary point to remember its previous position,
// we have to reuse the same pinchSequence object. Otherwise if we let it
// be destroyed and then start a new sequence, point 0 will default to being
// stationary at 0, 0, and PinchArea will filter out that touchpoint because
// it is outside its bounds.
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
pinchSequence.stationary(0).press(1, p2, &window).commit();
QQuickTouchUtils::flush(&window);
Improve tst_TouchMouse::pinchOnFlickable - use for loops instead of tedious repetition - compare instead of verify to check negative bools - QTRY_COMPARE instead of qWait - move touchpoints by drag threshold to ensure repeatability: both flickable and pincharea wait for the threshold to start reacting Change-Id: I071fc05280e2156223af57d97079516987a744ab Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2020-10-28 08:36:33 +00:00
QCOMPARE(rect->scale(), 1);
for (int i = 0; i < 3; ++i) {
p1 -= QPoint(threshold, 0);
p2 += QPoint(threshold, 0);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
pinchSequence.move(0, p1, &window).move(1, p2, &window).commit();
QQuickTouchUtils::flush(&window);
Improve tst_TouchMouse::pinchOnFlickable - use for loops instead of tedious repetition - compare instead of verify to check negative bools - QTRY_COMPARE instead of qWait - move touchpoints by drag threshold to ensure repeatability: both flickable and pincharea wait for the threshold to start reacting Change-Id: I071fc05280e2156223af57d97079516987a744ab Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2020-10-28 08:36:33 +00:00
qCDebug(lcTests, "pinch scale after %d moves: %lf", i + 1, rect->scale());
}
Fix touch/mouse propagation bugs Filtered mouse release was not delivered if another touch started after a touchMouseId was activated. This meant that any filters expecting a release event would not receive it if another touch was made before release of the touchMouseId. We prevented a touch becoming the touchMouseId in the child mouse filters if there were any existing touches. The normal event delivery, however, does not require a single touch. Further to the previous, a touch could become the touchMouseId, even if the initial press happened when there was an existing touchMouseId. This meant that a touch could turn into a mouse when the existing mouse event was released, resulting in a new touchMouseId which hadn't been through child mouse filters. Flickable delayed press should be sent via normal event processing, as other touch/mouse events are now delivered in this way. We often called childMouseEventFilter() multiple times for each event. This is bad because the gesture handling relies on claiming a gesture in one event, then stealing it in the next. Instead of sending touch to mouse candidate points already determined to be within the item bounds and already transformed, we sent all of the points to the mouse recipient. PinchArea did not store the starting position at the original touch points, so other items could pass the dragThreshold before PinchArea and steal a gesture meant for PinchArea. Task-number: QTBUG-40330 Change-Id: Ic0009c176d3d1cb7cff0b5eda076a2c3ca864136 Reviewed-by: Robin Burchell <robin+qt@viroteck.net>
2014-07-22 01:31:04 +00:00
QVERIFY(!flickable->isDragging());
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QQuickTouchUtils::flush(&window);
pinchSequence.release(0, p1, &window).release(1, p2, &window).commit();
QQuickTouchUtils::flush(&window);
Improve tst_TouchMouse::pinchOnFlickable - use for loops instead of tedious repetition - compare instead of verify to check negative bools - QTRY_COMPARE instead of qWait - move touchpoints by drag threshold to ensure repeatability: both flickable and pincharea wait for the threshold to start reacting Change-Id: I071fc05280e2156223af57d97079516987a744ab Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2020-10-28 08:36:33 +00:00
QVERIFY(rect->scale() > 1); // depends on threshold
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
}
void tst_TouchMouse::flickableOnPinch()
{
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QQuickView window;
QVERIFY(QQuickTest::showView(window, testFileUrl("flickableonpinch.qml")));
QQuickPinchArea *pinchArea = window.rootObject()->findChild<QQuickPinchArea*>("pincharea");
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
QVERIFY(pinchArea);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QQuickFlickable *flickable = window.rootObject()->findChild<QQuickFlickable*>("flickable");
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
QVERIFY(flickable);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QQuickItem *rect = window.rootObject()->findChild<QQuickItem*>("rect");
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
QVERIFY(rect);
// flickable - single touch point
tests/quick: Replace Q[TRY]_VERIFY(a == b) by Q[TRY]_COMPARE(a, b). - Replace Q[TRY]_VERIFY(pointer == 0) by Q[TRY]_VERIFY(!pointer). - Replace Q[TRY]_VERIFY(smartPointer == 0) by Q[TRY]_VERIFY(smartPointer.isNull()). - Replace Q[TRY]_VERIFY(a == b) by Q[TRY]_COMPARE(a, b) and add casts where necessary. The values will then be logged should a test fail. Change-Id: Ib9f4c2486af23c47990be4b9e004b965de226dcc Reviewed-by: Mitch Curtis <mitch.curtis@theqtcompany.com>
2015-07-24 13:32:22 +00:00
QCOMPARE(flickable->contentX(), 0.0);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
QPoint p = QPoint(100, 100);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QTest::touchEvent(&window, device).press(0, p, &window);
QQuickTouchUtils::flush(&window);
Renamed QQuickItem::pos property to position Abbreviated property names are less descriptive so we don't have many of them. Might as well be consistent. QWindow::pos was already renamed. Change-Id: Ib52673e68e7dc902b2f8942dba6b899074b2538b Reviewed-by: Samuel Rødal <samuel.rodal@digia.com>
2012-10-22 14:59:25 +00:00
QCOMPARE(rect->position(), QPointF(200.0, 200.0));
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
p -= QPoint(10, 0);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QTest::touchEvent(&window, device).move(0, p, &window);
QQuickTouchUtils::flush(&window);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
p -= QPoint(10, 0);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QTest::touchEvent(&window, device).move(0, p, &window);
QQuickTouchUtils::flush(&window);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
QTest::qWait(1000);
p -= QPoint(10, 0);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QTest::touchEvent(&window, device).move(0, p, &window);
QQuickTouchUtils::flush(&window);
QTest::touchEvent(&window, device).release(0, p, &window);
QQuickTouchUtils::flush(&window);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
QTest::qWait(1000);
//QVERIFY(flickable->isMovingHorizontally());
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
qCDebug(lcTests) << "Pos: " << rect->position();
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
// wait until flicking is done
QTRY_VERIFY(!flickable->isFlicking());
// pinch
QPoint p1 = QPoint(40, 20);
QPoint p2 = QPoint(60, 20);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QTest::QTouchEventSequence pinchSequence = QTest::touchEvent(&window, device);
pinchSequence.press(0, p1, &window).commit();
QQuickTouchUtils::flush(&window);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
// In order for the stationary point to remember its previous position,
// we have to reuse the same pinchSequence object. Otherwise if we let it
// be destroyed and then start a new sequence, point 0 will default to being
// stationary at 0, 0, and PinchArea will filter out that touchpoint because
// it is outside its bounds.
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
pinchSequence.stationary(0).press(1, p2, &window).commit();
QQuickTouchUtils::flush(&window);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
p1 -= QPoint(10,10);
p2 += QPoint(10,10);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
pinchSequence.move(0, p1, &window).move(1, p2, &window).commit();
QQuickTouchUtils::flush(&window);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
QCOMPARE(rect->scale(), 1.0);
p1 -= QPoint(10, 0);
p2 += QPoint(10, 0);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
pinchSequence.move(0, p1, &window).move(1, p2, &window).commit();
QQuickTouchUtils::flush(&window);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
p1 -= QPoint(10, 0);
p2 += QPoint(10, 0);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
pinchSequence.move(0, p1, &window).move(1, p2, &window).commit();
QQuickTouchUtils::flush(&window);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
p1 -= QPoint(10, 0);
p2 += QPoint(10, 0);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
pinchSequence.move(0, p1, &window).move(1, p2, &window).commit();
QQuickTouchUtils::flush(&window);
pinchSequence.release(0, p1, &window).release(1, p2, &window).commit();
QQuickTouchUtils::flush(&window);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
QVERIFY(rect->scale() > 1.0);
}
void tst_TouchMouse::mouseOnFlickableOnPinch()
{
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QQuickView window;
QVERIFY(QQuickTest::showView(window, testFileUrl("mouseonflickableonpinch.qml")));
tst_touchmouse: Have a go at some stabilisation & improvements * Use QScopedPointer to own views, preventing leakage (was a problem in a few of these tests, e.g. pinchOnFlickable/flickableOnPinch/mouseOnFlickableOnPinch) * Only qWaitForWindowActive, as the tests aren't doing anything graphical, they don't need an expose event, which means less waiting * Use the test utilities to center the windows on screen to make sure they are not under desktop chrome & have a non-null position. If position is 0,0 that means window->position().isNull() is true, so qWaitForWindowActive will wait for its entire timeout: 5 seconds. This means no "manual" tweaking of geometry anymore: the position is now taken care of by the test utilities, and we let the root QML item size determine the window size. * Move the mouse away from the window using the test utilities. Done-with: Shawn Rutledge Change-Id: I4ac6a0d56067c57ef51f186fe3cd118cab056ff2 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2017-01-11 15:40:28 +00:00
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QQuickPinchArea *pinchArea = window.rootObject()->findChild<QQuickPinchArea*>("pincharea");
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
QVERIFY(pinchArea);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QQuickFlickable *flickable = window.rootObject()->findChild<QQuickFlickable*>("flickable");
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
QVERIFY(flickable);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QQuickItem *rect = window.rootObject()->findChild<QQuickItem*>("rect");
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
QVERIFY(rect);
// flickable - single touch point
tests/quick: Replace Q[TRY]_VERIFY(a == b) by Q[TRY]_COMPARE(a, b). - Replace Q[TRY]_VERIFY(pointer == 0) by Q[TRY]_VERIFY(!pointer). - Replace Q[TRY]_VERIFY(smartPointer == 0) by Q[TRY]_VERIFY(smartPointer.isNull()). - Replace Q[TRY]_VERIFY(a == b) by Q[TRY]_COMPARE(a, b) and add casts where necessary. The values will then be logged should a test fail. Change-Id: Ib9f4c2486af23c47990be4b9e004b965de226dcc Reviewed-by: Mitch Curtis <mitch.curtis@theqtcompany.com>
2015-07-24 13:32:22 +00:00
QCOMPARE(flickable->contentX(), 0.0);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
QPoint p = QPoint(100, 100);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QTest::touchEvent(&window, device).press(0, p, &window);
QQuickTouchUtils::flush(&window);
Renamed QQuickItem::pos property to position Abbreviated property names are less descriptive so we don't have many of them. Might as well be consistent. QWindow::pos was already renamed. Change-Id: Ib52673e68e7dc902b2f8942dba6b899074b2538b Reviewed-by: Samuel Rødal <samuel.rodal@digia.com>
2012-10-22 14:59:25 +00:00
QCOMPARE(rect->position(), QPointF(200.0, 200.0));
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
p -= QPoint(10, 0);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QTest::touchEvent(&window, device).move(0, p, &window);
QQuickTouchUtils::flush(&window);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
p -= QPoint(10, 0);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QTest::touchEvent(&window, device).move(0, p, &window);
QQuickTouchUtils::flush(&window);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
p -= QPoint(10, 0);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QTest::touchEvent(&window, device).move(0, p, &window);
QQuickTouchUtils::flush(&window);
QTest::touchEvent(&window, device).release(0, p, &window);
QQuickTouchUtils::flush(&window);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QVERIFY(flickable->isMovingHorizontally());
Dragging MouseArea nested in Flickable does not work with touch to mouse A MouseArea with a drag target nested in a Flickable does not work. This is due to QQuickWindow calling childMouseEventFilter() twice - once in sendFilteredTouchEvent() and later in sendEvent(). Since childMouseEventFilter() has already been called, deliver the mouse event directly in sendFilteredTouchEvent(). Task-number: QTBUG-32920 Change-Id: I22acee3c66ee6c06e71c9c876fb02dbcb6119a8d Reviewed-by: Andrew den Exter <andrew.den.exter@qinetic.com.au>
2013-08-12 03:28:17 +00:00
// Wait for flick to end
QTRY_VERIFY(!flickable->isMoving());
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
qCDebug(lcTests) << "Pos: " << rect->position();
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
// pinch
QPoint p1 = QPoint(40, 20);
QPoint p2 = QPoint(60, 20);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QTest::QTouchEventSequence pinchSequence = QTest::touchEvent(&window, device);
pinchSequence.press(0, p1, &window).commit();
QQuickTouchUtils::flush(&window);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
// In order for the stationary point to remember its previous position,
// we have to reuse the same pinchSequence object. Otherwise if we let it
// be destroyed and then start a new sequence, point 0 will default to being
// stationary at 0, 0, and PinchArea will filter out that touchpoint because
// it is outside its bounds.
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
pinchSequence.stationary(0).press(1, p2, &window).commit();
QQuickTouchUtils::flush(&window);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
p1 -= QPoint(10,10);
p2 += QPoint(10,10);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
pinchSequence.move(0, p1, &window).move(1, p2, &window).commit();
QQuickTouchUtils::flush(&window);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
QCOMPARE(rect->scale(), 1.0);
p1 -= QPoint(10, 0);
p2 += QPoint(10, 0);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
pinchSequence.move(0, p1, &window).move(1, p2, &window).commit();
QQuickTouchUtils::flush(&window);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
p1 -= QPoint(10, 0);
p2 += QPoint(10, 0);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
pinchSequence.move(0, p1, &window).move(1, p2, &window).commit();
QQuickTouchUtils::flush(&window);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
p1 -= QPoint(10, 0);
p2 += QPoint(10, 0);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
pinchSequence.move(0, p1, &window).move(1, p2, &window).commit();
QQuickTouchUtils::flush(&window);
pinchSequence.release(0, p1, &window).release(1, p2, &window).commit();
QQuickTouchUtils::flush(&window);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
QVERIFY(rect->scale() > 1.0);
Don't synthesize mouse from touch for items that accept touch 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>
2020-09-30 17:36:09 +00:00
// first pinch is done
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
Don't synthesize mouse from touch for items that accept touch 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>
2020-09-30 17:36:09 +00:00
// Press one point and drag left: Flickable flicks
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
rect->setScale(1.0);
flickable->setContentX(0.0);
p = QPoint(100, 100);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
pinchSequence.press(0, p, &window).commit();
QQuickTouchUtils::flush(&window);
Renamed QQuickItem::pos property to position Abbreviated property names are less descriptive so we don't have many of them. Might as well be consistent. QWindow::pos was already renamed. Change-Id: Ib52673e68e7dc902b2f8942dba6b899074b2538b Reviewed-by: Samuel Rødal <samuel.rodal@digia.com>
2012-10-22 14:59:25 +00:00
QCOMPARE(rect->position(), QPointF(200.0, 200.0));
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
p -= QPoint(10, 0);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
pinchSequence.move(0, p, &window).commit();
QQuickTouchUtils::flush(&window);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
p -= QPoint(10, 0);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
pinchSequence.move(0, p, &window).commit();
QQuickTouchUtils::flush(&window);
Ungrab mouse upon leave event. The event signals that the mouse has left the window. This happens also when a popup is shown (overlapping the original window). Before a mouse area would still think it was in pressed state when the popup (QWindow/QMenu) was shown and even after the popup was closed. Change-Id: I6d32571f5a473610f60e9476850989ff665edb93 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
2012-11-08 16:43:46 +00:00
QGuiApplication::processEvents();
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
p -= QPoint(10, 0);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
pinchSequence.move(0, p, &window).commit();
QQuickTouchUtils::flush(&window);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
Don't synthesize mouse from touch for items that accept touch 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>
2020-09-30 17:36:09 +00:00
// Add a second finger: PinchArea should grab one touchpoint and steal the other, even though flicking is ongoing
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
p1 = QPoint(40, 100);
p2 = QPoint(60, 100);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
pinchSequence.stationary(0).press(1, p2, &window).commit();
QQuickTouchUtils::flush(&window);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
QCOMPARE(rect->scale(), 1.0);
p1 -= QPoint(5, 0);
p2 += QPoint(5, 0);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
pinchSequence.move(0, p1, &window).move(1, p2, &window).commit();
QQuickTouchUtils::flush(&window);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
p1 -= QPoint(5, 0);
p2 += QPoint(5, 0);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
pinchSequence.move(0, p1, &window).move(1, p2, &window).commit();
QQuickTouchUtils::flush(&window);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
p1 -= QPoint(5, 0);
p2 += QPoint(5, 0);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
pinchSequence.move(0, p1, &window).move(1, p2, &window).commit();
QQuickTouchUtils::flush(&window);
pinchSequence.release(0, p1, &window).release(1, p2, &window).commit();
QQuickTouchUtils::flush(&window);
Don't synthesize mouse from touch for items that accept touch 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>
2020-09-30 17:36:09 +00:00
qCDebug(lcTests) << "pinch scaled to" << rect->scale();
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
QVERIFY(rect->scale() > 1.0);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
pinchSequence.release(0, p, &window).commit();
QQuickTouchUtils::flush(&window);
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
}
Test case for tapping on stacked mouse areas Shows bug where the bottom mouse area could get a double click event out of a single tap. Change-Id: I4907a1506db2b4ccc5299d698c6e05fd02db963c Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
2012-12-19 17:29:49 +00:00
/*
Regression test for the following use case:
You have two mouse areas, on on top of the other.
1 - You tap the top one.
2 - That top mouse area receives a mouse press event but doesn't accept it
Expected outcome:
3 - the bottom mouse area gets clicked (besides press and release mouse events)
Bogus outcome:
3 - the bottom mouse area gets double clicked.
*/
void tst_TouchMouse::tapOnDismissiveTopMouseAreaClicksBottomOne()
{
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QQuickView window;
QVERIFY(QQuickTest::showView(window, testFileUrl("twoMouseAreas.qml")));
Test case for tapping on stacked mouse areas Shows bug where the bottom mouse area could get a double click event out of a single tap. Change-Id: I4907a1506db2b4ccc5299d698c6e05fd02db963c Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
2012-12-19 17:29:49 +00:00
QQuickMouseArea *bottomMouseArea =
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
window.rootObject()->findChild<QQuickMouseArea*>("rear mouseArea");
Test case for tapping on stacked mouse areas Shows bug where the bottom mouse area could get a double click event out of a single tap. Change-Id: I4907a1506db2b4ccc5299d698c6e05fd02db963c Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
2012-12-19 17:29:49 +00:00
QSignalSpy bottomClickedSpy(bottomMouseArea, SIGNAL(clicked(QQuickMouseEvent*)));
QSignalSpy bottomDoubleClickedSpy(bottomMouseArea,
SIGNAL(doubleClicked(QQuickMouseEvent*)));
// tap the front mouse area (see qml file)
QPoint p1(20, 20);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QTest::touchEvent(&window, device).press(0, p1, &window);
QQuickTouchUtils::flush(&window);
QTest::touchEvent(&window, device).release(0, p1, &window);
QQuickTouchUtils::flush(&window);
Test case for tapping on stacked mouse areas Shows bug where the bottom mouse area could get a double click event out of a single tap. Change-Id: I4907a1506db2b4ccc5299d698c6e05fd02db963c Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
2012-12-19 17:29:49 +00:00
Port from container::count() and length() to size() This is a semantic patch using ClangTidyTransformator as in qtbase/df9d882d41b741fef7c5beeddb0abe9d904443d8: auto QtContainerClass = anyOf( expr(hasType(cxxRecordDecl(isSameOrDerivedFrom(hasAnyName(classes))))).bind(o), expr(hasType(namedDecl(hasAnyName(<classes>)))).bind(o)); makeRule(cxxMemberCallExpr(on(QtContainerClass), callee(cxxMethodDecl(hasAnyName({"count", "length"), parameterCountIs(0))))), changeTo(cat(access(o, cat("size"), "()"))), cat("use 'size()' instead of 'count()/length()'")) a.k.a qt-port-to-std-compatible-api with config Scope: 'Container', with the extended set of container classes recognized. Change-Id: Idb1f75dfe2323bd1d9e8b4d58d54f1b4b80c7ed7 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
2022-10-05 05:29:16 +00:00
QCOMPARE(bottomClickedSpy.size(), 1);
QCOMPARE(bottomDoubleClickedSpy.size(), 0);
Test case for tapping on stacked mouse areas Shows bug where the bottom mouse area could get a double click event out of a single tap. Change-Id: I4907a1506db2b4ccc5299d698c6e05fd02db963c Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
2012-12-19 17:29:49 +00:00
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QTest::touchEvent(&window, device).press(0, p1, &window);
QQuickTouchUtils::flush(&window);
QTest::touchEvent(&window, device).release(0, p1, &window);
QQuickTouchUtils::flush(&window);
Test case for tapping on stacked mouse areas Shows bug where the bottom mouse area could get a double click event out of a single tap. Change-Id: I4907a1506db2b4ccc5299d698c6e05fd02db963c Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
2012-12-19 17:29:49 +00:00
Port from container::count() and length() to size() This is a semantic patch using ClangTidyTransformator as in qtbase/df9d882d41b741fef7c5beeddb0abe9d904443d8: auto QtContainerClass = anyOf( expr(hasType(cxxRecordDecl(isSameOrDerivedFrom(hasAnyName(classes))))).bind(o), expr(hasType(namedDecl(hasAnyName(<classes>)))).bind(o)); makeRule(cxxMemberCallExpr(on(QtContainerClass), callee(cxxMethodDecl(hasAnyName({"count", "length"), parameterCountIs(0))))), changeTo(cat(access(o, cat("size"), "()"))), cat("use 'size()' instead of 'count()/length()'")) a.k.a qt-port-to-std-compatible-api with config Scope: 'Container', with the extended set of container classes recognized. Change-Id: Idb1f75dfe2323bd1d9e8b4d58d54f1b4b80c7ed7 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
2022-10-05 05:29:16 +00:00
QCOMPARE(bottomClickedSpy.size(), 1);
QCOMPARE(bottomDoubleClickedSpy.size(), 1);
Test case for tapping on stacked mouse areas Shows bug where the bottom mouse area could get a double click event out of a single tap. Change-Id: I4907a1506db2b4ccc5299d698c6e05fd02db963c Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
2012-12-19 17:29:49 +00:00
}
Remove mouse grabber if touch used for mouse emulation has been grabbed If an item grabs a touch that is currently being used for mouse pointer emulation, the current mouse grabber should lose the mouse as mouse events will no longer be generated from that touch point. Example of what happens without this patch: -User touches a MouseArea. It gets pressed. -Some other item grabs that touch. -This touch eventually ends. -The MouseArea would still be pressed. And what will happens instead after this patch: -User touches a MouseArea. It gets pressed. -Some other item grabs that touch. -The MouseArea gets canceled and released -This touch eventually ends. Change-Id: I24114f18be564553a4a768243bb20379affe7a8f Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
2014-10-10 19:54:39 +00:00
/*
If an item grabs a touch that is currently being used for mouse pointer emulation,
the current mouse grabber should lose the mouse as mouse events will no longer
be generated from that touch point.
*/
void tst_TouchMouse::touchGrabCausesMouseUngrab()
{
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QQuickView window;
QVERIFY(QQuickTest::showView(window, testFileUrl("twosiblingitems.qml")));
EventItem *leftItem = window.rootObject()->findChild<EventItem*>("leftItem");
Remove mouse grabber if touch used for mouse emulation has been grabbed If an item grabs a touch that is currently being used for mouse pointer emulation, the current mouse grabber should lose the mouse as mouse events will no longer be generated from that touch point. Example of what happens without this patch: -User touches a MouseArea. It gets pressed. -Some other item grabs that touch. -This touch eventually ends. -The MouseArea would still be pressed. And what will happens instead after this patch: -User touches a MouseArea. It gets pressed. -Some other item grabs that touch. -The MouseArea gets canceled and released -This touch eventually ends. Change-Id: I24114f18be564553a4a768243bb20379affe7a8f Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
2014-10-10 19:54:39 +00:00
QVERIFY(leftItem);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
EventItem *rightItem = window.rootObject()->findChild<EventItem*>("rightItem");
Remove mouse grabber if touch used for mouse emulation has been grabbed If an item grabs a touch that is currently being used for mouse pointer emulation, the current mouse grabber should lose the mouse as mouse events will no longer be generated from that touch point. Example of what happens without this patch: -User touches a MouseArea. It gets pressed. -Some other item grabs that touch. -This touch eventually ends. -The MouseArea would still be pressed. And what will happens instead after this patch: -User touches a MouseArea. It gets pressed. -Some other item grabs that touch. -The MouseArea gets canceled and released -This touch eventually ends. Change-Id: I24114f18be564553a4a768243bb20379affe7a8f Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
2014-10-10 19:54:39 +00:00
QVERIFY(leftItem);
// Send a touch to the leftItem. But leftItem accepts only mouse events, thus
// a mouse event will be synthesized out of this touch and will get accepted by
// leftItem.
leftItem->acceptMouse = true;
leftItem->setAcceptedMouseButtons(Qt::LeftButton);
QPoint p1;
p1 = QPoint(leftItem->width() / 2, leftItem->height() / 2);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QTest::touchEvent(&window, device).press(0, p1, &window);
QQuickTouchUtils::flush(&window);
Don't synthesize mouse from touch for items that accept touch 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>
2020-09-30 17:36:09 +00:00
qCDebug(lcTests) << "expected delivered events: press(mouse)" << leftItem->eventList;
QCOMPARE(leftItem->eventList.size(), 1);
QCOMPARE(leftItem->eventList.at(0).type, QEvent::MouseButtonPress);
Remove QQuickPointerEvent etc.; deliver QPointerEvents directly QEventPoint does not have an accessor to get the QPointerEvent that it came from, because that's inconsistent with the idea that QPointerEvent instances are temporary, stack-allocated and movable (the pointer would often be wrong or null, therefore could not be relied upon). So most functions that worked directly with QQuickEventPoint before (which fortunately are still private API) now need to receive the QPointerEvent too, which we choose to pass by pointer. QEventPoint is always passed by reference (const where possible) to be consistent with functions in QPointerEvent that take QEventPoint by reference. QEventPoint::velocity() should be always in scene coordinates now, which saves us the trouble of transforming it to each item's coordinate system during delivery, but means that it will need to be done in handlers or applications sometimes. If we were going to transform it, it would be important to also store the sceneVelocity separately in QEventPoint so that the transformation could be done repeatedly for different items. Task-number: QTBUG-72173 Change-Id: I7ee164d2e6893c4e407fb7d579c75aa32843933a Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
2020-07-23 11:56:26 +00:00
QCOMPARE(grabMonitor.exclusiveGrabber, leftItem);
Remove mouse grabber if touch used for mouse emulation has been grabbed If an item grabs a touch that is currently being used for mouse pointer emulation, the current mouse grabber should lose the mouse as mouse events will no longer be generated from that touch point. Example of what happens without this patch: -User touches a MouseArea. It gets pressed. -Some other item grabs that touch. -This touch eventually ends. -The MouseArea would still be pressed. And what will happens instead after this patch: -User touches a MouseArea. It gets pressed. -Some other item grabs that touch. -The MouseArea gets canceled and released -This touch eventually ends. Change-Id: I24114f18be564553a4a768243bb20379affe7a8f Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
2014-10-10 19:54:39 +00:00
leftItem->eventList.clear();
rightItem->acceptTouch = true;
Remove QQuickPointerEvent etc.; deliver QPointerEvents directly QEventPoint does not have an accessor to get the QPointerEvent that it came from, because that's inconsistent with the idea that QPointerEvent instances are temporary, stack-allocated and movable (the pointer would often be wrong or null, therefore could not be relied upon). So most functions that worked directly with QQuickEventPoint before (which fortunately are still private API) now need to receive the QPointerEvent too, which we choose to pass by pointer. QEventPoint is always passed by reference (const where possible) to be consistent with functions in QPointerEvent that take QEventPoint by reference. QEventPoint::velocity() should be always in scene coordinates now, which saves us the trouble of transforming it to each item's coordinate system during delivery, but means that it will need to be done in handlers or applications sometimes. If we were going to transform it, it would be important to also store the sceneVelocity separately in QEventPoint so that the transformation could be done repeatedly for different items. Task-number: QTBUG-72173 Change-Id: I7ee164d2e6893c4e407fb7d579c75aa32843933a Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
2020-07-23 11:56:26 +00:00
auto devPriv = QPointingDevicePrivate::get(device);
auto epd = devPriv->queryPointById(0);
QVERIFY(epd);
devPriv->setExclusiveGrabber(nullptr, epd->eventPoint, rightItem);
Remove mouse grabber if touch used for mouse emulation has been grabbed If an item grabs a touch that is currently being used for mouse pointer emulation, the current mouse grabber should lose the mouse as mouse events will no longer be generated from that touch point. Example of what happens without this patch: -User touches a MouseArea. It gets pressed. -Some other item grabs that touch. -This touch eventually ends. -The MouseArea would still be pressed. And what will happens instead after this patch: -User touches a MouseArea. It gets pressed. -Some other item grabs that touch. -The MouseArea gets canceled and released -This touch eventually ends. Change-Id: I24114f18be564553a4a768243bb20379affe7a8f Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
2014-10-10 19:54:39 +00:00
// leftItem should have lost the mouse as the touch point that was being used to emulate it
// has been grabbed by another item.
QCOMPARE(leftItem->eventList.size(), 1);
QCOMPARE(leftItem->eventList.at(0).type, QEvent::UngrabMouse);
Remove QQuickPointerEvent etc.; deliver QPointerEvents directly QEventPoint does not have an accessor to get the QPointerEvent that it came from, because that's inconsistent with the idea that QPointerEvent instances are temporary, stack-allocated and movable (the pointer would often be wrong or null, therefore could not be relied upon). So most functions that worked directly with QQuickEventPoint before (which fortunately are still private API) now need to receive the QPointerEvent too, which we choose to pass by pointer. QEventPoint is always passed by reference (const where possible) to be consistent with functions in QPointerEvent that take QEventPoint by reference. QEventPoint::velocity() should be always in scene coordinates now, which saves us the trouble of transforming it to each item's coordinate system during delivery, but means that it will need to be done in handlers or applications sometimes. If we were going to transform it, it would be important to also store the sceneVelocity separately in QEventPoint so that the transformation could be done repeatedly for different items. Task-number: QTBUG-72173 Change-Id: I7ee164d2e6893c4e407fb7d579c75aa32843933a Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
2020-07-23 11:56:26 +00:00
QCOMPARE(grabMonitor.exclusiveGrabber, rightItem);
Remove mouse grabber if touch used for mouse emulation has been grabbed If an item grabs a touch that is currently being used for mouse pointer emulation, the current mouse grabber should lose the mouse as mouse events will no longer be generated from that touch point. Example of what happens without this patch: -User touches a MouseArea. It gets pressed. -Some other item grabs that touch. -This touch eventually ends. -The MouseArea would still be pressed. And what will happens instead after this patch: -User touches a MouseArea. It gets pressed. -Some other item grabs that touch. -The MouseArea gets canceled and released -This touch eventually ends. Change-Id: I24114f18be564553a4a768243bb20379affe7a8f Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
2014-10-10 19:54:39 +00:00
}
Test touch point delivery order Change-Id: I9b93eda0378e10bbcc274998d58f5f5ec62bb1b1 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2016-08-01 12:13:20 +00:00
void tst_TouchMouse::touchPointDeliveryOrder()
{
// Touch points should be first delivered to the item under the primary finger
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QQuickView window;
QVERIFY(QQuickTest::showView(window, testFileUrl("touchpointdeliveryorder.qml")));
tst_touchmouse: Have a go at some stabilisation & improvements * Use QScopedPointer to own views, preventing leakage (was a problem in a few of these tests, e.g. pinchOnFlickable/flickableOnPinch/mouseOnFlickableOnPinch) * Only qWaitForWindowActive, as the tests aren't doing anything graphical, they don't need an expose event, which means less waiting * Use the test utilities to center the windows on screen to make sure they are not under desktop chrome & have a non-null position. If position is 0,0 that means window->position().isNull() is true, so qWaitForWindowActive will wait for its entire timeout: 5 seconds. This means no "manual" tweaking of geometry anymore: the position is now taken care of by the test utilities, and we let the root QML item size determine the window size. * Move the mouse away from the window using the test utilities. Done-with: Shawn Rutledge Change-Id: I4ac6a0d56067c57ef51f186fe3cd118cab056ff2 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2017-01-11 15:40:28 +00:00
Test touch point delivery order Change-Id: I9b93eda0378e10bbcc274998d58f5f5ec62bb1b1 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2016-08-01 12:13:20 +00:00
/*
The items are positioned from left to right:
| background |
| left |
| | right |
| middle |
0 150 300 450 600
*/
QPoint pLeft = QPoint(100, 100);
QPoint pRight = QPoint(500, 100);
QPoint pLeftMiddle = QPoint(200, 100);
QPoint pRightMiddle = QPoint(350, 100);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QTest::QTouchEventSequence touchSeq = QTest::touchEvent(&window, device, false);
Test touch point delivery order Change-Id: I9b93eda0378e10bbcc274998d58f5f5ec62bb1b1 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2016-08-01 12:13:20 +00:00
QVector<QQuickItem*> events;
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
EventItem *background = window.rootObject()->findChild<EventItem*>("background");
EventItem *left = window.rootObject()->findChild<EventItem*>("left");
EventItem *middle = window.rootObject()->findChild<EventItem*>("middle");
EventItem *right = window.rootObject()->findChild<EventItem*>("right");
Test touch point delivery order Change-Id: I9b93eda0378e10bbcc274998d58f5f5ec62bb1b1 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2016-08-01 12:13:20 +00:00
QVERIFY(background);
QVERIFY(left);
QVERIFY(middle);
QVERIFY(right);
Don't synthesize mouse from touch for items that accept touch 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>
2020-09-30 17:36:09 +00:00
background->setAcceptTouchEvents(true);
left->setAcceptTouchEvents(true);
middle->setAcceptTouchEvents(true);
right->setAcceptTouchEvents(true);
Test touch point delivery order Change-Id: I9b93eda0378e10bbcc274998d58f5f5ec62bb1b1 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2016-08-01 12:13:20 +00:00
connect(background, &EventItem::onTouchEvent, [&events](QQuickItem* receiver){ events.append(receiver); });
connect(left, &EventItem::onTouchEvent, [&events](QQuickItem* receiver){ events.append(receiver); });
connect(middle, &EventItem::onTouchEvent, [&events](QQuickItem* receiver){ events.append(receiver); });
connect(right, &EventItem::onTouchEvent, [&events](QQuickItem* receiver){ events.append(receiver); });
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
touchSeq.press(0, pLeft, &window).commit();
QQuickTouchUtils::flush(&window);
Test touch point delivery order Change-Id: I9b93eda0378e10bbcc274998d58f5f5ec62bb1b1 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2016-08-01 12:13:20 +00:00
// Touch on left, then background
QCOMPARE(events.size(), 2);
QCOMPARE(events.at(0), left);
QCOMPARE(events.at(1), background);
events.clear();
// New press events are deliverd first, the stationary point was not accepted, thus it doesn't get delivered
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
touchSeq.stationary(0).press(1, pRightMiddle, &window).commit();
QQuickTouchUtils::flush(&window);
Test touch point delivery order Change-Id: I9b93eda0378e10bbcc274998d58f5f5ec62bb1b1 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2016-08-01 12:13:20 +00:00
QCOMPARE(events.size(), 3);
QCOMPARE(events.at(0), middle);
QCOMPARE(events.at(1), right);
QCOMPARE(events.at(2), background);
events.clear();
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
touchSeq.release(0, pLeft, &window).release(1, pRightMiddle, &window).commit();
QQuickTouchUtils::flush(&window);
Test touch point delivery order Change-Id: I9b93eda0378e10bbcc274998d58f5f5ec62bb1b1 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2016-08-01 12:13:20 +00:00
QCOMPARE(events.size(), 0); // no accepted events
// Two presses, the first point should come first
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
touchSeq.press(0, pLeft, &window).press(1, pRight, &window).commit();
QQuickTouchUtils::flush(&window);
Test touch point delivery order Change-Id: I9b93eda0378e10bbcc274998d58f5f5ec62bb1b1 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2016-08-01 12:13:20 +00:00
QCOMPARE(events.size(), 3);
QCOMPARE(events.at(0), left);
QCOMPARE(events.at(1), right);
QCOMPARE(events.at(2), background);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
touchSeq.release(0, pLeft, &window).release(1, pRight, &window).commit();
Test touch point delivery order Change-Id: I9b93eda0378e10bbcc274998d58f5f5ec62bb1b1 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2016-08-01 12:13:20 +00:00
events.clear();
// Again, pressing right first
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
touchSeq.press(0, pRight, &window).press(1, pLeft, &window).commit();
QQuickTouchUtils::flush(&window);
Test touch point delivery order Change-Id: I9b93eda0378e10bbcc274998d58f5f5ec62bb1b1 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2016-08-01 12:13:20 +00:00
QCOMPARE(events.size(), 3);
QCOMPARE(events.at(0), right);
QCOMPARE(events.at(1), left);
QCOMPARE(events.at(2), background);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
touchSeq.release(0, pRight, &window).release(1, pLeft, &window).commit();
Test touch point delivery order Change-Id: I9b93eda0378e10bbcc274998d58f5f5ec62bb1b1 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2016-08-01 12:13:20 +00:00
events.clear();
// Two presses, both hitting the middle item on top, then branching left and right, then bottom
// Each target should be offered the events exactly once, middle first, left must come before right (id 0)
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
touchSeq.press(0, pLeftMiddle, &window).press(1, pRightMiddle, &window).commit();
Test touch point delivery order Change-Id: I9b93eda0378e10bbcc274998d58f5f5ec62bb1b1 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2016-08-01 12:13:20 +00:00
QCOMPARE(events.size(), 4);
QCOMPARE(events.at(0), middle);
QCOMPARE(events.at(1), left);
QCOMPARE(events.at(2), right);
QCOMPARE(events.at(3), background);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
touchSeq.release(0, pLeftMiddle, &window).release(1, pRightMiddle, &window).commit();
Test touch point delivery order Change-Id: I9b93eda0378e10bbcc274998d58f5f5ec62bb1b1 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2016-08-01 12:13:20 +00:00
events.clear();
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
touchSeq.press(0, pRightMiddle, &window).press(1, pLeftMiddle, &window).commit();
qCDebug(lcTests) << events;
Test touch point delivery order Change-Id: I9b93eda0378e10bbcc274998d58f5f5ec62bb1b1 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2016-08-01 12:13:20 +00:00
QCOMPARE(events.size(), 4);
QCOMPARE(events.at(0), middle);
QCOMPARE(events.at(1), right);
QCOMPARE(events.at(2), left);
QCOMPARE(events.at(3), background);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
touchSeq.release(0, pRightMiddle, &window).release(1, pLeftMiddle, &window).commit();
Test touch point delivery order Change-Id: I9b93eda0378e10bbcc274998d58f5f5ec62bb1b1 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2016-08-01 12:13:20 +00:00
}
Don't synthesize mouse from touch for items that accept touch 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>
2020-09-30 17:36:09 +00:00
void tst_TouchMouse::hoverEnabled() // QTBUG-40856
Fix containsMouse with touch and hoverEnabled When we synthesize a press/release from touch, the item believes that the mouse never leaves, so if we have several mouse areas, they may all claim that they contain the mouse at the same time. The solution is to synthesize a move back to the actual mouse position. Task-number: QTBUG-40856 Change-Id: I43610d95aa383f847db18b387405b0c4e91cea0f Reviewed-by: Shawn Rutledge <shawn.rutledge@theqtcompany.com>
2015-11-30 15:39:15 +00:00
{
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QQuickView window;
QVERIFY(QQuickTest::showView(window, testFileUrl("hoverMouseAreas.qml")));
QQuickItem *root = window.rootObject();
Fix containsMouse with touch and hoverEnabled When we synthesize a press/release from touch, the item believes that the mouse never leaves, so if we have several mouse areas, they may all claim that they contain the mouse at the same time. The solution is to synthesize a move back to the actual mouse position. Task-number: QTBUG-40856 Change-Id: I43610d95aa383f847db18b387405b0c4e91cea0f Reviewed-by: Shawn Rutledge <shawn.rutledge@theqtcompany.com>
2015-11-30 15:39:15 +00:00
QQuickMouseArea *mouseArea1 = root->findChild<QQuickMouseArea*>("mouseArea1");
use nullptr consistently (clang-tidy) From now on we prefer nullptr instead of 0 to clarify cases where we are assigning or testing a pointer rather than a numeric zero. Also, replaced cases where 0 was passed as Qt::KeyboardModifiers with Qt::NoModifier (clang-tidy replaced them with nullptr, which waas wrong, so it was just as well to make the tests more readable rather than to revert those lines). Change-Id: I4735d35e4d9f42db5216862ce091429eadc6e65d Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2018-02-21 09:41:54 +00:00
QVERIFY(mouseArea1 != nullptr);
Fix containsMouse with touch and hoverEnabled When we synthesize a press/release from touch, the item believes that the mouse never leaves, so if we have several mouse areas, they may all claim that they contain the mouse at the same time. The solution is to synthesize a move back to the actual mouse position. Task-number: QTBUG-40856 Change-Id: I43610d95aa383f847db18b387405b0c4e91cea0f Reviewed-by: Shawn Rutledge <shawn.rutledge@theqtcompany.com>
2015-11-30 15:39:15 +00:00
QQuickMouseArea *mouseArea2 = root->findChild<QQuickMouseArea*>("mouseArea2");
use nullptr consistently (clang-tidy) From now on we prefer nullptr instead of 0 to clarify cases where we are assigning or testing a pointer rather than a numeric zero. Also, replaced cases where 0 was passed as Qt::KeyboardModifiers with Qt::NoModifier (clang-tidy replaced them with nullptr, which waas wrong, so it was just as well to make the tests more readable rather than to revert those lines). Change-Id: I4735d35e4d9f42db5216862ce091429eadc6e65d Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2018-02-21 09:41:54 +00:00
QVERIFY(mouseArea2 != nullptr);
Fix containsMouse with touch and hoverEnabled When we synthesize a press/release from touch, the item believes that the mouse never leaves, so if we have several mouse areas, they may all claim that they contain the mouse at the same time. The solution is to synthesize a move back to the actual mouse position. Task-number: QTBUG-40856 Change-Id: I43610d95aa383f847db18b387405b0c4e91cea0f Reviewed-by: Shawn Rutledge <shawn.rutledge@theqtcompany.com>
2015-11-30 15:39:15 +00:00
QSignalSpy enterSpy1(mouseArea1, SIGNAL(entered()));
QSignalSpy exitSpy1(mouseArea1, SIGNAL(exited()));
QSignalSpy clickSpy1(mouseArea1, SIGNAL(clicked(QQuickMouseEvent *)));
QSignalSpy enterSpy2(mouseArea2, SIGNAL(entered()));
QSignalSpy exitSpy2(mouseArea2, SIGNAL(exited()));
QSignalSpy clickSpy2(mouseArea2, SIGNAL(clicked(QQuickMouseEvent *)));
QPoint p1(150, 150);
QPoint p2(150, 250);
// ------------------------- Mouse move to mouseArea1
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QTest::mouseMove(&window, p1);
Fix containsMouse with touch and hoverEnabled When we synthesize a press/release from touch, the item believes that the mouse never leaves, so if we have several mouse areas, they may all claim that they contain the mouse at the same time. The solution is to synthesize a move back to the actual mouse position. Task-number: QTBUG-40856 Change-Id: I43610d95aa383f847db18b387405b0c4e91cea0f Reviewed-by: Shawn Rutledge <shawn.rutledge@theqtcompany.com>
2015-11-30 15:39:15 +00:00
Port from container::count() and length() to size() This is a semantic patch using ClangTidyTransformator as in qtbase/df9d882d41b741fef7c5beeddb0abe9d904443d8: auto QtContainerClass = anyOf( expr(hasType(cxxRecordDecl(isSameOrDerivedFrom(hasAnyName(classes))))).bind(o), expr(hasType(namedDecl(hasAnyName(<classes>)))).bind(o)); makeRule(cxxMemberCallExpr(on(QtContainerClass), callee(cxxMethodDecl(hasAnyName({"count", "length"), parameterCountIs(0))))), changeTo(cat(access(o, cat("size"), "()"))), cat("use 'size()' instead of 'count()/length()'")) a.k.a qt-port-to-std-compatible-api with config Scope: 'Container', with the extended set of container classes recognized. Change-Id: Idb1f75dfe2323bd1d9e8b4d58d54f1b4b80c7ed7 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
2022-10-05 05:29:16 +00:00
QVERIFY(enterSpy1.size() == 1);
Fix containsMouse with touch and hoverEnabled When we synthesize a press/release from touch, the item believes that the mouse never leaves, so if we have several mouse areas, they may all claim that they contain the mouse at the same time. The solution is to synthesize a move back to the actual mouse position. Task-number: QTBUG-40856 Change-Id: I43610d95aa383f847db18b387405b0c4e91cea0f Reviewed-by: Shawn Rutledge <shawn.rutledge@theqtcompany.com>
2015-11-30 15:39:15 +00:00
QVERIFY(mouseArea1->hovered());
QVERIFY(!mouseArea2->hovered());
// ------------------------- Touch click on mouseArea1
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QTest::touchEvent(&window, device).press(0, p1, &window);
Fix containsMouse with touch and hoverEnabled When we synthesize a press/release from touch, the item believes that the mouse never leaves, so if we have several mouse areas, they may all claim that they contain the mouse at the same time. The solution is to synthesize a move back to the actual mouse position. Task-number: QTBUG-40856 Change-Id: I43610d95aa383f847db18b387405b0c4e91cea0f Reviewed-by: Shawn Rutledge <shawn.rutledge@theqtcompany.com>
2015-11-30 15:39:15 +00:00
Port from container::count() and length() to size() This is a semantic patch using ClangTidyTransformator as in qtbase/df9d882d41b741fef7c5beeddb0abe9d904443d8: auto QtContainerClass = anyOf( expr(hasType(cxxRecordDecl(isSameOrDerivedFrom(hasAnyName(classes))))).bind(o), expr(hasType(namedDecl(hasAnyName(<classes>)))).bind(o)); makeRule(cxxMemberCallExpr(on(QtContainerClass), callee(cxxMethodDecl(hasAnyName({"count", "length"), parameterCountIs(0))))), changeTo(cat(access(o, cat("size"), "()"))), cat("use 'size()' instead of 'count()/length()'")) a.k.a qt-port-to-std-compatible-api with config Scope: 'Container', with the extended set of container classes recognized. Change-Id: Idb1f75dfe2323bd1d9e8b4d58d54f1b4b80c7ed7 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
2022-10-05 05:29:16 +00:00
QCOMPARE(enterSpy1.size(), 1);
QCOMPARE(enterSpy2.size(), 0);
QQuickMouseArea: do not overload pressed-signal Renames the pressed() getter of the pressed property in QQuickMouseArea to isPressed() to avoid overloading the pressed()-signal. Signals should not be overloaded. Also, it makes code generation in qmltc more complicated. Task-number: QTBUG-110029 Change-Id: I2373f4fe97b1e955b815825003bc746f2eaf43be Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2023-01-11 09:37:21 +00:00
QVERIFY(mouseArea1->isPressed());
Fix containsMouse with touch and hoverEnabled When we synthesize a press/release from touch, the item believes that the mouse never leaves, so if we have several mouse areas, they may all claim that they contain the mouse at the same time. The solution is to synthesize a move back to the actual mouse position. Task-number: QTBUG-40856 Change-Id: I43610d95aa383f847db18b387405b0c4e91cea0f Reviewed-by: Shawn Rutledge <shawn.rutledge@theqtcompany.com>
2015-11-30 15:39:15 +00:00
QVERIFY(mouseArea1->hovered());
QVERIFY(!mouseArea2->hovered());
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QTest::touchEvent(&window, device).release(0, p1, &window);
Port from container::count() and length() to size() This is a semantic patch using ClangTidyTransformator as in qtbase/df9d882d41b741fef7c5beeddb0abe9d904443d8: auto QtContainerClass = anyOf( expr(hasType(cxxRecordDecl(isSameOrDerivedFrom(hasAnyName(classes))))).bind(o), expr(hasType(namedDecl(hasAnyName(<classes>)))).bind(o)); makeRule(cxxMemberCallExpr(on(QtContainerClass), callee(cxxMethodDecl(hasAnyName({"count", "length"), parameterCountIs(0))))), changeTo(cat(access(o, cat("size"), "()"))), cat("use 'size()' instead of 'count()/length()'")) a.k.a qt-port-to-std-compatible-api with config Scope: 'Container', with the extended set of container classes recognized. Change-Id: Idb1f75dfe2323bd1d9e8b4d58d54f1b4b80c7ed7 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
2022-10-05 05:29:16 +00:00
QVERIFY(clickSpy1.size() == 1);
Fix containsMouse with touch and hoverEnabled When we synthesize a press/release from touch, the item believes that the mouse never leaves, so if we have several mouse areas, they may all claim that they contain the mouse at the same time. The solution is to synthesize a move back to the actual mouse position. Task-number: QTBUG-40856 Change-Id: I43610d95aa383f847db18b387405b0c4e91cea0f Reviewed-by: Shawn Rutledge <shawn.rutledge@theqtcompany.com>
2015-11-30 15:39:15 +00:00
QVERIFY(mouseArea1->hovered());
QVERIFY(!mouseArea2->hovered());
// ------------------------- Touch click on mouseArea2
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QTest::touchEvent(&window, device).press(0, p2, &window);
Fix containsMouse with touch and hoverEnabled When we synthesize a press/release from touch, the item believes that the mouse never leaves, so if we have several mouse areas, they may all claim that they contain the mouse at the same time. The solution is to synthesize a move back to the actual mouse position. Task-number: QTBUG-40856 Change-Id: I43610d95aa383f847db18b387405b0c4e91cea0f Reviewed-by: Shawn Rutledge <shawn.rutledge@theqtcompany.com>
2015-11-30 15:39:15 +00:00
QVERIFY(mouseArea1->hovered());
QVERIFY(mouseArea2->hovered());
QQuickMouseArea: do not overload pressed-signal Renames the pressed() getter of the pressed property in QQuickMouseArea to isPressed() to avoid overloading the pressed()-signal. Signals should not be overloaded. Also, it makes code generation in qmltc more complicated. Task-number: QTBUG-110029 Change-Id: I2373f4fe97b1e955b815825003bc746f2eaf43be Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2023-01-11 09:37:21 +00:00
QVERIFY(mouseArea2->isPressed());
Port from container::count() and length() to size() This is a semantic patch using ClangTidyTransformator as in qtbase/df9d882d41b741fef7c5beeddb0abe9d904443d8: auto QtContainerClass = anyOf( expr(hasType(cxxRecordDecl(isSameOrDerivedFrom(hasAnyName(classes))))).bind(o), expr(hasType(namedDecl(hasAnyName(<classes>)))).bind(o)); makeRule(cxxMemberCallExpr(on(QtContainerClass), callee(cxxMethodDecl(hasAnyName({"count", "length"), parameterCountIs(0))))), changeTo(cat(access(o, cat("size"), "()"))), cat("use 'size()' instead of 'count()/length()'")) a.k.a qt-port-to-std-compatible-api with config Scope: 'Container', with the extended set of container classes recognized. Change-Id: Idb1f75dfe2323bd1d9e8b4d58d54f1b4b80c7ed7 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
2022-10-05 05:29:16 +00:00
QCOMPARE(enterSpy1.size(), 1);
QCOMPARE(enterSpy2.size(), 1);
Fix containsMouse with touch and hoverEnabled When we synthesize a press/release from touch, the item believes that the mouse never leaves, so if we have several mouse areas, they may all claim that they contain the mouse at the same time. The solution is to synthesize a move back to the actual mouse position. Task-number: QTBUG-40856 Change-Id: I43610d95aa383f847db18b387405b0c4e91cea0f Reviewed-by: Shawn Rutledge <shawn.rutledge@theqtcompany.com>
2015-11-30 15:39:15 +00:00
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QTest::touchEvent(&window, device).release(0, p2, &window);
Fix containsMouse with touch and hoverEnabled When we synthesize a press/release from touch, the item believes that the mouse never leaves, so if we have several mouse areas, they may all claim that they contain the mouse at the same time. The solution is to synthesize a move back to the actual mouse position. Task-number: QTBUG-40856 Change-Id: I43610d95aa383f847db18b387405b0c4e91cea0f Reviewed-by: Shawn Rutledge <shawn.rutledge@theqtcompany.com>
2015-11-30 15:39:15 +00:00
Port from container::count() and length() to size() This is a semantic patch using ClangTidyTransformator as in qtbase/df9d882d41b741fef7c5beeddb0abe9d904443d8: auto QtContainerClass = anyOf( expr(hasType(cxxRecordDecl(isSameOrDerivedFrom(hasAnyName(classes))))).bind(o), expr(hasType(namedDecl(hasAnyName(<classes>)))).bind(o)); makeRule(cxxMemberCallExpr(on(QtContainerClass), callee(cxxMethodDecl(hasAnyName({"count", "length"), parameterCountIs(0))))), changeTo(cat(access(o, cat("size"), "()"))), cat("use 'size()' instead of 'count()/length()'")) a.k.a qt-port-to-std-compatible-api with config Scope: 'Container', with the extended set of container classes recognized. Change-Id: Idb1f75dfe2323bd1d9e8b4d58d54f1b4b80c7ed7 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
2022-10-05 05:29:16 +00:00
QVERIFY(clickSpy2.size() == 1);
Fix containsMouse with touch and hoverEnabled When we synthesize a press/release from touch, the item believes that the mouse never leaves, so if we have several mouse areas, they may all claim that they contain the mouse at the same time. The solution is to synthesize a move back to the actual mouse position. Task-number: QTBUG-40856 Change-Id: I43610d95aa383f847db18b387405b0c4e91cea0f Reviewed-by: Shawn Rutledge <shawn.rutledge@theqtcompany.com>
2015-11-30 15:39:15 +00:00
QVERIFY(mouseArea1->hovered());
QVERIFY(!mouseArea2->hovered());
Port from container::count() and length() to size() This is a semantic patch using ClangTidyTransformator as in qtbase/df9d882d41b741fef7c5beeddb0abe9d904443d8: auto QtContainerClass = anyOf( expr(hasType(cxxRecordDecl(isSameOrDerivedFrom(hasAnyName(classes))))).bind(o), expr(hasType(namedDecl(hasAnyName(<classes>)))).bind(o)); makeRule(cxxMemberCallExpr(on(QtContainerClass), callee(cxxMethodDecl(hasAnyName({"count", "length"), parameterCountIs(0))))), changeTo(cat(access(o, cat("size"), "()"))), cat("use 'size()' instead of 'count()/length()'")) a.k.a qt-port-to-std-compatible-api with config Scope: 'Container', with the extended set of container classes recognized. Change-Id: Idb1f75dfe2323bd1d9e8b4d58d54f1b4b80c7ed7 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
2022-10-05 05:29:16 +00:00
QCOMPARE(exitSpy1.size(), 0);
QCOMPARE(exitSpy2.size(), 1);
Fix containsMouse with touch and hoverEnabled When we synthesize a press/release from touch, the item believes that the mouse never leaves, so if we have several mouse areas, they may all claim that they contain the mouse at the same time. The solution is to synthesize a move back to the actual mouse position. Task-number: QTBUG-40856 Change-Id: I43610d95aa383f847db18b387405b0c4e91cea0f Reviewed-by: Shawn Rutledge <shawn.rutledge@theqtcompany.com>
2015-11-30 15:39:15 +00:00
// ------------------------- Another touch click on mouseArea1
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QTest::touchEvent(&window, device).press(0, p1, &window);
Fix containsMouse with touch and hoverEnabled When we synthesize a press/release from touch, the item believes that the mouse never leaves, so if we have several mouse areas, they may all claim that they contain the mouse at the same time. The solution is to synthesize a move back to the actual mouse position. Task-number: QTBUG-40856 Change-Id: I43610d95aa383f847db18b387405b0c4e91cea0f Reviewed-by: Shawn Rutledge <shawn.rutledge@theqtcompany.com>
2015-11-30 15:39:15 +00:00
Port from container::count() and length() to size() This is a semantic patch using ClangTidyTransformator as in qtbase/df9d882d41b741fef7c5beeddb0abe9d904443d8: auto QtContainerClass = anyOf( expr(hasType(cxxRecordDecl(isSameOrDerivedFrom(hasAnyName(classes))))).bind(o), expr(hasType(namedDecl(hasAnyName(<classes>)))).bind(o)); makeRule(cxxMemberCallExpr(on(QtContainerClass), callee(cxxMethodDecl(hasAnyName({"count", "length"), parameterCountIs(0))))), changeTo(cat(access(o, cat("size"), "()"))), cat("use 'size()' instead of 'count()/length()'")) a.k.a qt-port-to-std-compatible-api with config Scope: 'Container', with the extended set of container classes recognized. Change-Id: Idb1f75dfe2323bd1d9e8b4d58d54f1b4b80c7ed7 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
2022-10-05 05:29:16 +00:00
QCOMPARE(enterSpy1.size(), 1);
QCOMPARE(enterSpy2.size(), 1);
QQuickMouseArea: do not overload pressed-signal Renames the pressed() getter of the pressed property in QQuickMouseArea to isPressed() to avoid overloading the pressed()-signal. Signals should not be overloaded. Also, it makes code generation in qmltc more complicated. Task-number: QTBUG-110029 Change-Id: I2373f4fe97b1e955b815825003bc746f2eaf43be Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2023-01-11 09:37:21 +00:00
QVERIFY(mouseArea1->isPressed());
Fix containsMouse with touch and hoverEnabled When we synthesize a press/release from touch, the item believes that the mouse never leaves, so if we have several mouse areas, they may all claim that they contain the mouse at the same time. The solution is to synthesize a move back to the actual mouse position. Task-number: QTBUG-40856 Change-Id: I43610d95aa383f847db18b387405b0c4e91cea0f Reviewed-by: Shawn Rutledge <shawn.rutledge@theqtcompany.com>
2015-11-30 15:39:15 +00:00
QVERIFY(mouseArea1->hovered());
QVERIFY(!mouseArea2->hovered());
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QTest::touchEvent(&window, device).release(0, p1, &window);
Port from container::count() and length() to size() This is a semantic patch using ClangTidyTransformator as in qtbase/df9d882d41b741fef7c5beeddb0abe9d904443d8: auto QtContainerClass = anyOf( expr(hasType(cxxRecordDecl(isSameOrDerivedFrom(hasAnyName(classes))))).bind(o), expr(hasType(namedDecl(hasAnyName(<classes>)))).bind(o)); makeRule(cxxMemberCallExpr(on(QtContainerClass), callee(cxxMethodDecl(hasAnyName({"count", "length"), parameterCountIs(0))))), changeTo(cat(access(o, cat("size"), "()"))), cat("use 'size()' instead of 'count()/length()'")) a.k.a qt-port-to-std-compatible-api with config Scope: 'Container', with the extended set of container classes recognized. Change-Id: Idb1f75dfe2323bd1d9e8b4d58d54f1b4b80c7ed7 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
2022-10-05 05:29:16 +00:00
QCOMPARE(clickSpy1.size(), 2);
Fix containsMouse with touch and hoverEnabled When we synthesize a press/release from touch, the item believes that the mouse never leaves, so if we have several mouse areas, they may all claim that they contain the mouse at the same time. The solution is to synthesize a move back to the actual mouse position. Task-number: QTBUG-40856 Change-Id: I43610d95aa383f847db18b387405b0c4e91cea0f Reviewed-by: Shawn Rutledge <shawn.rutledge@theqtcompany.com>
2015-11-30 15:39:15 +00:00
QVERIFY(mouseArea1->hovered());
QQuickMouseArea: do not overload pressed-signal Renames the pressed() getter of the pressed property in QQuickMouseArea to isPressed() to avoid overloading the pressed()-signal. Signals should not be overloaded. Also, it makes code generation in qmltc more complicated. Task-number: QTBUG-110029 Change-Id: I2373f4fe97b1e955b815825003bc746f2eaf43be Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2023-01-11 09:37:21 +00:00
QVERIFY(!mouseArea1->isPressed());
Fix containsMouse with touch and hoverEnabled When we synthesize a press/release from touch, the item believes that the mouse never leaves, so if we have several mouse areas, they may all claim that they contain the mouse at the same time. The solution is to synthesize a move back to the actual mouse position. Task-number: QTBUG-40856 Change-Id: I43610d95aa383f847db18b387405b0c4e91cea0f Reviewed-by: Shawn Rutledge <shawn.rutledge@theqtcompany.com>
2015-11-30 15:39:15 +00:00
QVERIFY(!mouseArea2->hovered());
}
Add TouchMouse::implicitUngrab autotest Task-number: QTBUG-57797 Task-number: QTBUG-59098 Change-Id: I3bf9ad33c22cdbd82f3efbdbfc35f63371c04bed Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2017-01-13 09:02:23 +00:00
void tst_TouchMouse::implicitUngrab()
{
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QQuickView window;
QVERIFY(QQuickTest::showView(window, testFileUrl("singleitem.qml")));
QQuickWindowPrivate *windowPriv = QQuickWindowPrivate::get(&window);
QQuickItem *root = window.rootObject();
use nullptr consistently (clang-tidy) From now on we prefer nullptr instead of 0 to clarify cases where we are assigning or testing a pointer rather than a numeric zero. Also, replaced cases where 0 was passed as Qt::KeyboardModifiers with Qt::NoModifier (clang-tidy replaced them with nullptr, which waas wrong, so it was just as well to make the tests more readable rather than to revert those lines). Change-Id: I4735d35e4d9f42db5216862ce091429eadc6e65d Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2018-02-21 09:41:54 +00:00
QVERIFY(root != nullptr);
Add TouchMouse::implicitUngrab autotest Task-number: QTBUG-57797 Task-number: QTBUG-59098 Change-Id: I3bf9ad33c22cdbd82f3efbdbfc35f63371c04bed Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2017-01-13 09:02:23 +00:00
EventItem *eventItem = root->findChild<EventItem*>("eventItem1");
eventItem->acceptMouse = true;
Don't synthesize mouse from touch for items that accept touch 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>
2020-09-30 17:36:09 +00:00
eventItem->setAcceptTouchEvents(false);
Add TouchMouse::implicitUngrab autotest Task-number: QTBUG-57797 Task-number: QTBUG-59098 Change-Id: I3bf9ad33c22cdbd82f3efbdbfc35f63371c04bed Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2017-01-13 09:02:23 +00:00
QPoint p1(20, 20);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QTest::touchEvent(&window, device).press(0, p1);
Add TouchMouse::implicitUngrab autotest Task-number: QTBUG-57797 Task-number: QTBUG-59098 Change-Id: I3bf9ad33c22cdbd82f3efbdbfc35f63371c04bed Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2017-01-13 09:02:23 +00:00
Remove QQuickPointerEvent etc.; deliver QPointerEvents directly QEventPoint does not have an accessor to get the QPointerEvent that it came from, because that's inconsistent with the idea that QPointerEvent instances are temporary, stack-allocated and movable (the pointer would often be wrong or null, therefore could not be relied upon). So most functions that worked directly with QQuickEventPoint before (which fortunately are still private API) now need to receive the QPointerEvent too, which we choose to pass by pointer. QEventPoint is always passed by reference (const where possible) to be consistent with functions in QPointerEvent that take QEventPoint by reference. QEventPoint::velocity() should be always in scene coordinates now, which saves us the trouble of transforming it to each item's coordinate system during delivery, but means that it will need to be done in handlers or applications sometimes. If we were going to transform it, it would be important to also store the sceneVelocity separately in QEventPoint so that the transformation could be done repeatedly for different items. Task-number: QTBUG-72173 Change-Id: I7ee164d2e6893c4e407fb7d579c75aa32843933a Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
2020-07-23 11:56:26 +00:00
QCOMPARE(grabMonitor.exclusiveGrabber, eventItem);
Add TouchMouse::implicitUngrab autotest Task-number: QTBUG-57797 Task-number: QTBUG-59098 Change-Id: I3bf9ad33c22cdbd82f3efbdbfc35f63371c04bed Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2017-01-13 09:02:23 +00:00
eventItem->eventList.clear();
eventItem->setEnabled(false);
QVERIFY(!eventItem->eventList.isEmpty());
QCOMPARE(eventItem->eventList.at(0).type, QEvent::UngrabMouse);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QTest::touchEvent(&window, device).release(0, p1); // clean up potential state
Move event delivery from QQWindow to QQuickDeliveryAgent QQuickWindow owns QQuickRootItem which owns QQuickDeliveryAgent, so for every window there's an object responsible for event delivery, while the window itself is mainly responsible for rendering (separation of concerns). However, QQuickRootItem and QQuickDeliveryAgent can now be used in cases where the scene doesn't directly belong to a window, such as when a Qt Quick sub-scene is mapped somewhere into a Qt Quick 3D scene. In that case, we must remember which delivery agent was in use at the time when a QEventPoint is grabbed and deliver subsequent updates via the same DA. There's also a QQuickDeliveryAgent::Transform abstraction which subscene-management code (such as QQuick3DViewport) can implement, to provide a formula to map the window's scene coordinates to subscene coordinates; if defined, it will be used during delivery of subsequent updates to existing grabbers. Task-number: QTBUG-84870 Change-Id: I70b433f7ebb05d2e60214ff3192e05da0aa84a42 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
2020-07-14 18:09:57 +00:00
QCOMPARE(windowPriv->deliveryAgentPrivate()->touchMouseId, -1);
Add TouchMouse::implicitUngrab autotest Task-number: QTBUG-57797 Task-number: QTBUG-59098 Change-Id: I3bf9ad33c22cdbd82f3efbdbfc35f63371c04bed Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2017-01-13 09:02:23 +00:00
eventItem->setEnabled(true);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QTest::touchEvent(&window, device).press(0, p1);
Add TouchMouse::implicitUngrab autotest Task-number: QTBUG-57797 Task-number: QTBUG-59098 Change-Id: I3bf9ad33c22cdbd82f3efbdbfc35f63371c04bed Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2017-01-13 09:02:23 +00:00
eventItem->eventList.clear();
eventItem->setVisible(false);
QVERIFY(!eventItem->eventList.isEmpty());
QCOMPARE(eventItem->eventList.at(0).type, QEvent::UngrabMouse);
Clean up tst_TouchMouse - 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>
2020-11-17 09:11:08 +00:00
QTest::touchEvent(&window, device).release(0, p1); // clean up potential state
Add TouchMouse::implicitUngrab autotest Task-number: QTBUG-57797 Task-number: QTBUG-59098 Change-Id: I3bf9ad33c22cdbd82f3efbdbfc35f63371c04bed Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2017-01-13 09:02:23 +00:00
}
deliveryagent: cancel touch-mouse synthesis when cancelling touch event When we get a touch cancel event from QPA, the delivery agent should also reset any ongoing touch-mouse synthesis. Otherwise it will fail to deliver the next mouse press event that is synthesized thereafter, since touchMouseId will be stuck with a value different from -1 (which we test from deliverTouchAsMouse()). A bug from this is seen on iOS while selecting text. If you do a long press on top of a line edit, it will cancel the initial press sent to the input field, like it should, and use the subsequent move events to show and drag a magnifier glass around from QPA. This works fine. When you stop the drag, a popup menu will show that lets you select the word under the cursor. Now, if you click inside the line edit once more, the selection should normally be removed. But since we didn't clear touchMouseId upon receiving the initial touchCancel event when showing the magnifier, the agent will fail to deliver the press. The result is that nothing happens until you click once more inside the line edit. This patch will make sure that we reset any ongoing touch-mouse synthesis when receiving a touch cancel event. Pick-to: 6.2 Task-number: QTBUG-72110 Change-Id: I1c753736d0078c61e40ae9a6581f967ded62a175 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
2021-10-26 13:43:31 +00:00
void tst_TouchMouse::touchCancelWillCancelMousePress()
{
QQuickView window;
QVERIFY(QQuickTest::showView(window, testFileUrl("singleitem.qml")));
QQuickItem *root = window.rootObject();
QVERIFY(root != nullptr);
EventItem *eventItem = root->findChild<EventItem*>("eventItem1");
eventItem->acceptMouse = true;
eventItem->setAcceptTouchEvents(false);
QPoint p1(20, 20);
// Begin a new touch, that gets converted to a mouse press
QTest::touchEvent(&window, device).press(0, p1);
Port from container::count() and length() to size() This is a semantic patch using ClangTidyTransformator as in qtbase/df9d882d41b741fef7c5beeddb0abe9d904443d8: auto QtContainerClass = anyOf( expr(hasType(cxxRecordDecl(isSameOrDerivedFrom(hasAnyName(classes))))).bind(o), expr(hasType(namedDecl(hasAnyName(<classes>)))).bind(o)); makeRule(cxxMemberCallExpr(on(QtContainerClass), callee(cxxMethodDecl(hasAnyName({"count", "length"), parameterCountIs(0))))), changeTo(cat(access(o, cat("size"), "()"))), cat("use 'size()' instead of 'count()/length()'")) a.k.a qt-port-to-std-compatible-api with config Scope: 'Container', with the extended set of container classes recognized. Change-Id: Idb1f75dfe2323bd1d9e8b4d58d54f1b4b80c7ed7 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
2022-10-05 05:29:16 +00:00
QCOMPARE(eventItem->eventList.size(), 1);
deliveryagent: cancel touch-mouse synthesis when cancelling touch event When we get a touch cancel event from QPA, the delivery agent should also reset any ongoing touch-mouse synthesis. Otherwise it will fail to deliver the next mouse press event that is synthesized thereafter, since touchMouseId will be stuck with a value different from -1 (which we test from deliverTouchAsMouse()). A bug from this is seen on iOS while selecting text. If you do a long press on top of a line edit, it will cancel the initial press sent to the input field, like it should, and use the subsequent move events to show and drag a magnifier glass around from QPA. This works fine. When you stop the drag, a popup menu will show that lets you select the word under the cursor. Now, if you click inside the line edit once more, the selection should normally be removed. But since we didn't clear touchMouseId upon receiving the initial touchCancel event when showing the magnifier, the agent will fail to deliver the press. The result is that nothing happens until you click once more inside the line edit. This patch will make sure that we reset any ongoing touch-mouse synthesis when receiving a touch cancel event. Pick-to: 6.2 Task-number: QTBUG-72110 Change-Id: I1c753736d0078c61e40ae9a6581f967ded62a175 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
2021-10-26 13:43:31 +00:00
QCOMPARE(eventItem->eventList.at(0).type, QEvent::MouseButtonPress);
// Cancel it...
QTouchEvent cancelEvent(QEvent::TouchCancel, device);
QCoreApplication::sendEvent(&window, &cancelEvent);
Port from container::count() and length() to size() This is a semantic patch using ClangTidyTransformator as in qtbase/df9d882d41b741fef7c5beeddb0abe9d904443d8: auto QtContainerClass = anyOf( expr(hasType(cxxRecordDecl(isSameOrDerivedFrom(hasAnyName(classes))))).bind(o), expr(hasType(namedDecl(hasAnyName(<classes>)))).bind(o)); makeRule(cxxMemberCallExpr(on(QtContainerClass), callee(cxxMethodDecl(hasAnyName({"count", "length"), parameterCountIs(0))))), changeTo(cat(access(o, cat("size"), "()"))), cat("use 'size()' instead of 'count()/length()'")) a.k.a qt-port-to-std-compatible-api with config Scope: 'Container', with the extended set of container classes recognized. Change-Id: Idb1f75dfe2323bd1d9e8b4d58d54f1b4b80c7ed7 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
2022-10-05 05:29:16 +00:00
QCOMPARE(eventItem->eventList.size(), 3);
deliveryagent: cancel touch-mouse synthesis when cancelling touch event When we get a touch cancel event from QPA, the delivery agent should also reset any ongoing touch-mouse synthesis. Otherwise it will fail to deliver the next mouse press event that is synthesized thereafter, since touchMouseId will be stuck with a value different from -1 (which we test from deliverTouchAsMouse()). A bug from this is seen on iOS while selecting text. If you do a long press on top of a line edit, it will cancel the initial press sent to the input field, like it should, and use the subsequent move events to show and drag a magnifier glass around from QPA. This works fine. When you stop the drag, a popup menu will show that lets you select the word under the cursor. Now, if you click inside the line edit once more, the selection should normally be removed. But since we didn't clear touchMouseId upon receiving the initial touchCancel event when showing the magnifier, the agent will fail to deliver the press. The result is that nothing happens until you click once more inside the line edit. This patch will make sure that we reset any ongoing touch-mouse synthesis when receiving a touch cancel event. Pick-to: 6.2 Task-number: QTBUG-72110 Change-Id: I1c753736d0078c61e40ae9a6581f967ded62a175 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
2021-10-26 13:43:31 +00:00
QCOMPARE(eventItem->eventList.at(1).type, QEvent::TouchCancel);
QCOMPARE(eventItem->eventList.at(2).type, QEvent::UngrabMouse);
// Begin a second touch. Since the last one was cancelled, this
// should end up as a new mouse press on the target item.
QTest::touchEvent(&window, device).press(0, p1);
Port from container::count() and length() to size() This is a semantic patch using ClangTidyTransformator as in qtbase/df9d882d41b741fef7c5beeddb0abe9d904443d8: auto QtContainerClass = anyOf( expr(hasType(cxxRecordDecl(isSameOrDerivedFrom(hasAnyName(classes))))).bind(o), expr(hasType(namedDecl(hasAnyName(<classes>)))).bind(o)); makeRule(cxxMemberCallExpr(on(QtContainerClass), callee(cxxMethodDecl(hasAnyName({"count", "length"), parameterCountIs(0))))), changeTo(cat(access(o, cat("size"), "()"))), cat("use 'size()' instead of 'count()/length()'")) a.k.a qt-port-to-std-compatible-api with config Scope: 'Container', with the extended set of container classes recognized. Change-Id: Idb1f75dfe2323bd1d9e8b4d58d54f1b4b80c7ed7 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
2022-10-05 05:29:16 +00:00
QVERIFY(eventItem->eventList.size() >= 5);
deliveryagent: cancel touch-mouse synthesis when cancelling touch event When we get a touch cancel event from QPA, the delivery agent should also reset any ongoing touch-mouse synthesis. Otherwise it will fail to deliver the next mouse press event that is synthesized thereafter, since touchMouseId will be stuck with a value different from -1 (which we test from deliverTouchAsMouse()). A bug from this is seen on iOS while selecting text. If you do a long press on top of a line edit, it will cancel the initial press sent to the input field, like it should, and use the subsequent move events to show and drag a magnifier glass around from QPA. This works fine. When you stop the drag, a popup menu will show that lets you select the word under the cursor. Now, if you click inside the line edit once more, the selection should normally be removed. But since we didn't clear touchMouseId upon receiving the initial touchCancel event when showing the magnifier, the agent will fail to deliver the press. The result is that nothing happens until you click once more inside the line edit. This patch will make sure that we reset any ongoing touch-mouse synthesis when receiving a touch cancel event. Pick-to: 6.2 Task-number: QTBUG-72110 Change-Id: I1c753736d0078c61e40ae9a6581f967ded62a175 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
2021-10-26 13:43:31 +00:00
QCOMPARE(eventItem->eventList.at(3).type, QEvent::MouseButtonPress);
QTest::touchEvent(&window, device).release(0, p1); // clean up potential state
}
DeliveryAgent: don't cancelTouchMouseSynthesis() prematurely Do cancelTouchMouseSynthesis() when all touchpoints are released, or when the touchmouse is released; but not because another point is released while the touchmouse is still held. Pick-to: 6.2 6.3 Fixes: QTBUG-102996 Change-Id: I1de21c1119ab1c420f41af32580b25691d28f14e Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jarkko Koivikko <jarkko.koivikko@code-q.fi> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
2022-04-29 19:49:57 +00:00
void tst_TouchMouse::oneTouchInsideAndOneOutside() // QTBUG-102996
{
QQuickView window;
QVERIFY(QQuickTest::showView(window, testFileUrl("oneMouseArea.qml")));
QQuickItem *root = window.rootObject();
QVERIFY(root);
QQuickMouseArea *ma = root->findChild<QQuickMouseArea*>();
QVERIFY(ma);
// Press the MouseArea
QPoint p1 = ma->mapToScene(ma->boundingRect().center()).toPoint();
QTest::touchEvent(&window, device).press(1, p1);
QQuickTouchUtils::flush(&window);
QQuickMouseArea: do not overload pressed-signal Renames the pressed() getter of the pressed property in QQuickMouseArea to isPressed() to avoid overloading the pressed()-signal. Signals should not be overloaded. Also, it makes code generation in qmltc more complicated. Task-number: QTBUG-110029 Change-Id: I2373f4fe97b1e955b815825003bc746f2eaf43be Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2023-01-11 09:37:21 +00:00
QVERIFY(ma->isPressed());
DeliveryAgent: don't cancelTouchMouseSynthesis() prematurely Do cancelTouchMouseSynthesis() when all touchpoints are released, or when the touchmouse is released; but not because another point is released while the touchmouse is still held. Pick-to: 6.2 6.3 Fixes: QTBUG-102996 Change-Id: I1de21c1119ab1c420f41af32580b25691d28f14e Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jarkko Koivikko <jarkko.koivikko@code-q.fi> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
2022-04-29 19:49:57 +00:00
// Tap outside the MouseArea with a second finger
QPoint p2(100, 100);
QTest::touchEvent(&window, device).stationary(1).press(2, p2);
QQuickTouchUtils::flush(&window);
QTest::touchEvent(&window, device).stationary(1).release(2, p2);
QQuickTouchUtils::flush(&window);
QQuickMouseArea: do not overload pressed-signal Renames the pressed() getter of the pressed property in QQuickMouseArea to isPressed() to avoid overloading the pressed()-signal. Signals should not be overloaded. Also, it makes code generation in qmltc more complicated. Task-number: QTBUG-110029 Change-Id: I2373f4fe97b1e955b815825003bc746f2eaf43be Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2023-01-11 09:37:21 +00:00
QVERIFY(ma->isPressed());
DeliveryAgent: don't cancelTouchMouseSynthesis() prematurely Do cancelTouchMouseSynthesis() when all touchpoints are released, or when the touchmouse is released; but not because another point is released while the touchmouse is still held. Pick-to: 6.2 6.3 Fixes: QTBUG-102996 Change-Id: I1de21c1119ab1c420f41af32580b25691d28f14e Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jarkko Koivikko <jarkko.koivikko@code-q.fi> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
2022-04-29 19:49:57 +00:00
// Press again outside the MouseArea with a second finger
QTest::touchEvent(&window, device).stationary(1).press(2, p2);
// Release the first finger: MouseArea should be released
QTest::touchEvent(&window, device).release(1, p1).stationary(2);
QQuickTouchUtils::flush(&window);
QQuickMouseArea: do not overload pressed-signal Renames the pressed() getter of the pressed property in QQuickMouseArea to isPressed() to avoid overloading the pressed()-signal. Signals should not be overloaded. Also, it makes code generation in qmltc more complicated. Task-number: QTBUG-110029 Change-Id: I2373f4fe97b1e955b815825003bc746f2eaf43be Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2023-01-11 09:37:21 +00:00
QCOMPARE(ma->isPressed(), false);
DeliveryAgent: don't cancelTouchMouseSynthesis() prematurely Do cancelTouchMouseSynthesis() when all touchpoints are released, or when the touchmouse is released; but not because another point is released while the touchmouse is still held. Pick-to: 6.2 6.3 Fixes: QTBUG-102996 Change-Id: I1de21c1119ab1c420f41af32580b25691d28f14e Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jarkko Koivikko <jarkko.koivikko@code-q.fi> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
2022-04-29 19:49:57 +00:00
// Release the second finger
QTest::touchEvent(&window, device).release(2, p2);
QQuickTouchUtils::flush(&window);
}
Don't accept all QTouchEvent::points unless the item accepts touch An items that handles touch events can accept multiple touchpoints; but after visiting an item that does not handle events at all, or that relies on synth-mouse events, let the remaining touchpoints continue propagating. Do not automatically accept all touchpoints just because an item accepted a synth-mouse event, and do not auto-grab other touchpoints besides the touchmouse point. Done-with: Shawn Rutledge Pick-to: 6.2 6.4 Fixes: QTBUG-107867 Change-Id: I6c342487a4f8bacbd84e6d7e0e7c00884791a610 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Mitch Curtis <mitch.curtis@qt.io> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
2022-10-21 08:36:14 +00:00
void tst_TouchMouse::strayTouchDoesntAutograb() // QTBUG-107867
{
QQuickView window;
QVERIFY(QQuickTest::showView(window, testFileUrl("singleitem.qml")));
QQuickItem *root = window.rootObject();
QVERIFY(root);
EventItem *eventItem = root->findChild<EventItem*>();
QVERIFY(eventItem);
// This item accepts (synth-)mouse events but NOT touch
eventItem->acceptMouse = true;
QCOMPARE(eventItem->acceptTouchEvents(), false); // the default in Qt 6
QPoint p1(6, 6);
Stabilize tst_TouchMouse::strayTouchDoesntAutograb Apparently GrabMonitor sees all grab transitions in prior autotests up until strayTouchDoesntAutograb() runs; so it's surprising that it ever passed. Now we reset its state to initial conditions at the beginning. Amends 5ced8ec177fd730676eb854aea559a5f324a39b6 Pick-to: 6.2 6.4 Fixes: QTBUG-108352 Change-Id: I31c398f9cd08b2281ea82054b667437f1151f0bd Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2022-11-11 07:56:31 +00:00
grabMonitor.reset();
Don't accept all QTouchEvent::points unless the item accepts touch An items that handles touch events can accept multiple touchpoints; but after visiting an item that does not handle events at all, or that relies on synth-mouse events, let the remaining touchpoints continue propagating. Do not automatically accept all touchpoints just because an item accepted a synth-mouse event, and do not auto-grab other touchpoints besides the touchmouse point. Done-with: Shawn Rutledge Pick-to: 6.2 6.4 Fixes: QTBUG-107867 Change-Id: I6c342487a4f8bacbd84e6d7e0e7c00884791a610 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Mitch Curtis <mitch.curtis@qt.io> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
2022-10-21 08:36:14 +00:00
// Begin a new touch, that gets converted to a mouse press
QTest::touchEvent(&window, device).press(0, p1);
QQuickTouchUtils::flush(&window);
qCDebug(lcTests) << "after touch press:" << eventItem->eventList;
QCOMPARE(eventItem->eventList.size(), 1);
QCOMPARE(eventItem->eventList.at(0).type, QEvent::MouseButtonPress);
QCOMPARE(grabMonitor.exclusiveGrabber, eventItem);
// Drag
for (int i = 0; i < 3; ++i) {
QTest::touchEvent(&window, device).move(0, p1 + QPoint(i * 5, i * 5), &window);
QQuickTouchUtils::flush(&window);
QCOMPARE(grabMonitor.transitionCount, 1); // no new grab
QCOMPARE(eventItem->eventList.size(), i + 2);
QCOMPARE(eventItem->eventList.last().type, QEvent::MouseMove);
}
// Press an extra point: EventItem should see nothing
QTest::touchEvent(&window, device).stationary(0).press(1, p1);
QQuickTouchUtils::flush(&window);
qCDebug(lcTests) << "after press of second touchpoint:" << eventItem->eventList;
QCOMPARE(eventItem->eventList.size(), 4);
QCOMPARE(grabMonitor.transitionCount, 1); // no new grab
QTest::touchEvent(&window, device).release(0, p1).release(1, p1);
}
Propagate synthesized mouse events in parallel with touch. The old way of event propagation inside QQuickCanvas was to send the touch event through all elements, and if it was accepted along the way, stop. Otherwise generate a mouse event and propagate it through the items in the same way. With this patch the behavior is changed instead to do the propagation in parallel. The idea is to first send a touch, then a mouse event to each QML item (in paint order) that can potentially handle the events. When items filter their child elements, the same logic applies. Other changes/clarifications: - mouse events no longer get synthesized for more than one touch point - TouchPoints can be distributed to multiple Items - if an item accepts a touch point, it always gets updates, even if the point is stationary - events containing only stationary TouchPoints are discarded - PinchArea must accept any initial single TouchPoint in order to receive subsequent updates, even though it's not pinching yet. This means if PA is on top, items underneath don't get touches. New unit tests showing this behavior were added. This patch was written by Frederik Gladhorn, Laszlo Agocs and Shawn Rutledge. Due to the complexity of the logic some refactoring was done. QQuickMouseEventEx has been removed because it inherently relied on using the QEvent d pointer. Change-Id: If19ef687d7602e83cc11b18d2fecfbbdb4e44f5c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
2012-06-26 16:00:59 +00:00
QTEST_MAIN(tst_TouchMouse)
#include "tst_touchmouse.moc"