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

1586 lines
62 KiB
C++
Raw Normal View History

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
/****************************************************************************
**
Updated license headers From Qt 5.7 -> tools & applications are lisenced under GPL v3 with some exceptions, see http://blog.qt.io/blog/2016/01/13/new-agreement-with-the-kde-free-qt-foundation/ Updated license headers to use new GPL-EXCEPT header instead of LGPL21 one (in those files which will be under GPL 3 with exceptions) Change-Id: I04760a0801837cfc516d1c7c02d4f503f6bb70b6 Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
2016-01-19 11:23:05 +00:00
** Copyright (C) 2016 The Qt Company Ltd.
** Contact: https://www.qt.io/licensing/
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
**
** This file is part of the QtQml module of the Qt Toolkit.
**
Updated license headers From Qt 5.7 -> tools & applications are lisenced under GPL v3 with some exceptions, see http://blog.qt.io/blog/2016/01/13/new-agreement-with-the-kde-free-qt-foundation/ Updated license headers to use new GPL-EXCEPT header instead of LGPL21 one (in those files which will be under GPL 3 with exceptions) Change-Id: I04760a0801837cfc516d1c7c02d4f503f6bb70b6 Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
2016-01-19 11:23:05 +00:00
** $QT_BEGIN_LICENSE:GPL-EXCEPT$
Change copyrights from Nokia to Digia Change copyrights and license headers from Nokia to Digia Change-Id: Ie7f5d49ed8235d7a7845ab68f99ad1c220e64d5c Reviewed-by: Lars Knoll <lars.knoll@digia.com>
2012-09-20 05:21:40 +00:00
** Commercial License Usage
** Licensees holding valid commercial Qt licenses may use this file in
** accordance with the commercial license agreement provided with the
** Software or, alternatively, in accordance with the terms contained in
Update copyright headers Qt copyrights are now in The Qt Company, so we could update the source code headers accordingly. In the same go we should also fix the links to point to qt.io. Change-Id: I61120571787870c0ed17066afb31779b1e6e30e9 Reviewed-by: Iikka Eklund <iikka.eklund@theqtcompany.com>
2015-01-28 11:55:39 +00:00
** a written agreement between you and The Qt Company. For licensing terms
Updated license headers From Qt 5.7 -> tools & applications are lisenced under GPL v3 with some exceptions, see http://blog.qt.io/blog/2016/01/13/new-agreement-with-the-kde-free-qt-foundation/ Updated license headers to use new GPL-EXCEPT header instead of LGPL21 one (in those files which will be under GPL 3 with exceptions) Change-Id: I04760a0801837cfc516d1c7c02d4f503f6bb70b6 Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
2016-01-19 11:23:05 +00:00
** and conditions see https://www.qt.io/terms-conditions. For further
** information use the contact form at https://www.qt.io/contact-us.
Change copyrights from Nokia to Digia Change copyrights and license headers from Nokia to Digia Change-Id: Ie7f5d49ed8235d7a7845ab68f99ad1c220e64d5c Reviewed-by: Lars Knoll <lars.knoll@digia.com>
2012-09-20 05:21:40 +00:00
**
Updated license headers From Qt 5.7 -> tools & applications are lisenced under GPL v3 with some exceptions, see http://blog.qt.io/blog/2016/01/13/new-agreement-with-the-kde-free-qt-foundation/ Updated license headers to use new GPL-EXCEPT header instead of LGPL21 one (in those files which will be under GPL 3 with exceptions) Change-Id: I04760a0801837cfc516d1c7c02d4f503f6bb70b6 Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
2016-01-19 11:23:05 +00:00
** GNU General Public License Usage
** Alternatively, this file may be used under the terms of the GNU
** General Public License version 3 as published by the Free Software
** Foundation with exceptions as appearing in the file LICENSE.GPL3-EXCEPT
** included in the packaging of this file. Please review the following
** information to ensure the GNU General Public License requirements will
** be met: https://www.gnu.org/licenses/gpl-3.0.html.
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
**
** $QT_END_LICENSE$
**
****************************************************************************/
#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>
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>
#include "../../shared/util.h"
Compress touch events in QQuickWindow. Instead of sending multiple touch updates per frame, we store the last one and flush the pending events just before we enter into the scene graph sync phase. [ChangeLog][QtQuick] QQuickWindow will compresses touch events and delivers at most one touch event per frame. Done-with: Robin Burchell <robin.burchell@jollamobile.com> Change-Id: Ia0169bc4a3f0da67709b91ca65c326934b55d372 Reviewed-by: Laszlo Agocs <laszlo.agocs@digia.com> Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
2014-04-03 11:16:42 +00:00
#include "../shared/viewtestutil.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)
{}
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
Event(QEvent::Type t, QList<QEventPoint> touch)
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
:type(t), points(touch)
{}
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
dbg << ", " << event.points.count() << " touchpoints: " << event.points;
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);
Default QQuickItem::acceptTouchEvents to true until Qt 6 This is a partial revert of 1457df74f4c1d770e1e820de8cd082be1bd2489e to avoid making a mandatory API change so soon. Change-Id: I05040579fa36d3dc5ef7616861f6d17adf500d2c Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2017-05-02 09:34:19 +00:00
#if QT_VERSION >= QT_VERSION_CHECK(6, 0, 0)
Add QQuickItem acceptTouchEvents/setAcceptTouchEvents; require for touch It has been suboptimal to speculatively deliver touch events to Items which are not interested; even worse is when we must deliver to a parent item which is filtering events, when the child Item will not accept the touch event anyway. So now it is required that any QQuickItem subclass which wishes to accept touch events must call setAcceptTouchEvents(true) (typically in its constructor). If it does not do this, it will not get any touch events (and this saves us the trouble of looking for parents which filter touch events, too). It is consistent with needing to call setAcceptHoverEvents() to get hover events, and setAcceptedMouseButtons() to get mouse events. [ChangeLog][QtQuick][QQuickItem] When subclassing QQuickItem, it is now required to call setAcceptTouchEvents(true) if you need the item to receive touch events. Change-Id: Idc76c04f4e7f1d4a613087e756e96dac368f4f23 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2017-04-05 09:21:29 +00:00
setAcceptTouchEvents(true);
Default QQuickItem::acceptTouchEvents to true until Qt 6 This is a partial revert of 1457df74f4c1d770e1e820de8cd082be1bd2489e to avoid making a mandatory API change so soon. Change-Id: I05040579fa36d3dc5ef7616861f6d17adf500d2c Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2017-05-02 09:34:19 +00:00
#endif
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
}
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 touchEvent(QTouchEvent *event)
{
eventList.append(Event(event->type(), event->touchPoints()));
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> tps = event->touchPoints();
Relax assumptions of the value of the touchMouseId This is needed in order to be able to integrate a change that mangles the device identifier into the touch point id in qtbase Change-Id: I7675ade377da51f8da31830c7d43875487680845 Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
2016-10-12 08:50:22 +00:00
Q_ASSERT(!tps.isEmpty());
point0 = tps.first().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
}
void mousePressEvent(QMouseEvent *event)
{
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()));
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);
}
void mouseMoveEvent(QMouseEvent *event)
{
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()));
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);
}
void mouseReleaseEvent(QMouseEvent *event)
{
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()));
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);
}
void mouseDoubleClickEvent(QMouseEvent *event)
{
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()));
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
void mouseUngrabEvent()
{
eventList.append(Event(QEvent::UngrabMouse, QPoint(0,0), QPoint(0,0)));
}
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 touchUngrabEvent()
{
++touchUngrabCount;
}
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
bool event(QEvent *event) {
return QQuickItem::event(event);
}
QList<Event> eventList;
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
bool eventFilter(QObject *, QEvent *event)
{
if (event->type() == QEvent::TouchBegin ||
event->type() == QEvent::TouchUpdate ||
event->type() == QEvent::TouchCancel ||
event->type() == QEvent::TouchEnd) {
QTouchEvent *touch = static_cast<QTouchEvent*>(event);
eventList.append(Event(event->type(), touch->touchPoints()));
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> tps = touch->touchPoints();
Relax assumptions of the value of the touchMouseId This is needed in order to be able to integrate a change that mangles the device identifier into the touch point id in qtbase Change-Id: I7675ade377da51f8da31830c7d43875487680845 Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
2016-10-12 08:50:22 +00:00
Q_ASSERT(!tps.isEmpty());
point0 = tps.first().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
};
class tst_TouchMouse : public QQmlDataTest
{
Q_OBJECT
public:
tst_TouchMouse()
{}
private slots:
void initTestCase();
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();
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
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:
bool eventFilter(QObject *, QEvent *event)
{
if (event->type() == QEvent::MouseButtonPress ||
event->type() == QEvent::MouseMove ||
event->type() == QEvent::MouseButtonRelease) {
QMouseEvent *me = static_cast<QMouseEvent*>(event);
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
filteredEventList.append(Event(me->type(), me->position().toPoint(), me->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;
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");
}
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);
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());
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
window->setSource(testFileUrl("singleitem.qml"));
window->show();
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
QQuickViewTestUtil::centerOnScreen(window.data());
QVERIFY(QTest::qWaitForWindowActive(window.data()));
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(window->rootObject() != 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
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
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);
// Do not accept touch or mouse
QPoint p1;
p1 = QPoint(20, 20);
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
QTest::touchEvent(window.data(), device).press(0, p1, window.data());
QQuickTouchUtils::flush(window.data());
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
// Get a touch and then mouse event offered
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
QCOMPARE(eventItem1->eventList.size(), synthMouse ? 2 : 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
QCOMPARE(eventItem1->eventList.at(0).type, QEvent::TouchBegin);
p1 += QPoint(10, 0);
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
QTest::touchEvent(window.data(), device).move(0, p1, window.data());
QQuickTouchUtils::flush(window.data());
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
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
QCOMPARE(eventItem1->eventList.size(), synthMouse ? 2 : 1);
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
QTest::touchEvent(window.data(), device).release(0, p1, window.data());
QQuickTouchUtils::flush(window.data());
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
QCOMPARE(eventItem1->eventList.size(), synthMouse ? 2 : 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
eventItem1->eventList.clear();
// Accept touch
eventItem1->acceptTouch = true;
p1 = QPoint(20, 20);
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
QTest::touchEvent(window.data(), device).press(0, p1, window.data());
QQuickTouchUtils::flush(window.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
QCOMPARE(eventItem1->eventList.size(), 1);
p1 += QPoint(10, 0);
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
QTest::touchEvent(window.data(), device).move(0, p1, window.data());
QQuickTouchUtils::flush(window.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
QCOMPARE(eventItem1->eventList.size(), 2);
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
QTest::touchEvent(window.data(), device).release(0, p1, window.data());
QQuickTouchUtils::flush(window.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
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;
eventItem1->setAcceptedMouseButtons(Qt::LeftButton);
p1 = QPoint(20, 20);
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
QTest::touchEvent(window.data(), device).press(0, p1, window.data());
QQuickTouchUtils::flush(window.data());
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
QCOMPARE(eventItem1->eventList.size(), synthMouse ? 2 : 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
QCOMPARE(eventItem1->eventList.at(0).type, QEvent::TouchBegin);
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)
QCOMPARE(eventItem1->eventList.at(1).type, QEvent::MouseButtonPress);
QCOMPARE(window->mouseGrabberItem(), 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();
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
QPoint globalPos = window->mapToGlobal(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
QPoint scenePos = p1; // item is at 0,0
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
QCOMPARE(eventItem1->eventList.at(0).points.at(0).position().toPoint(), localPos);
QCOMPARE(eventItem1->eventList.at(0).points.at(0).scenePosition().toPoint(), scenePos);
QCOMPARE(eventItem1->eventList.at(0).points.at(0).globalPosition().toPoint(), 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
if (synthMouse) {
QCOMPARE(eventItem1->eventList.at(1).mousePos, localPos);
QCOMPARE(eventItem1->eventList.at(1).mousePosGlobal, globalPos);
}
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);
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
QTest::touchEvent(window.data(), device).move(0, p1, window.data());
QQuickTouchUtils::flush(window.data());
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
QCOMPARE(eventItem1->eventList.size(), synthMouse ? 4 : 1);
if (synthMouse) {
QCOMPARE(eventItem1->eventList.at(2).type, QEvent::TouchUpdate);
QCOMPARE(eventItem1->eventList.at(3).type, QEvent::MouseMove);
}
// else, if there was no synth-mouse and we didn't accept the touch,
// TouchUpdate was not sent to eventItem1 either.
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
QTest::touchEvent(window.data(), device).release(0, p1, window.data());
QQuickTouchUtils::flush(window.data());
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
QCOMPARE(eventItem1->eventList.size(), synthMouse ? 7 : 1);
if (synthMouse) {
QCOMPARE(eventItem1->eventList.at(4).type, QEvent::TouchEnd);
QCOMPARE(eventItem1->eventList.at(5).type, QEvent::MouseButtonRelease);
QCOMPARE(eventItem1->eventList.at(6).type, QEvent::UngrabMouse);
}
// 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);
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
QTest::touchEvent(window.data(), device).press(0, p1, window.data());
QQuickTouchUtils::flush(window.data());
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
QCOMPARE(eventItem1->eventList.size(), synthMouse ? 2 : 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
QCOMPARE(eventItem1->eventList.at(0).type, QEvent::TouchBegin);
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)
QCOMPARE(eventItem1->eventList.at(1).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);
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
QTest::touchEvent(window.data(), device).move(0, p1, window.data());
QQuickTouchUtils::flush(window.data());
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
QCOMPARE(eventItem1->eventList.size(), synthMouse ? 2 : 1);
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
QTest::touchEvent(window.data(), device).release(0, p1, window.data());
QQuickTouchUtils::flush(window.data());
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
QCOMPARE(eventItem1->eventList.size(), synthMouse ? 2 : 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
eventItem1->eventList.clear();
// wait to avoid getting a double click event
QTest::qWait(qApp->styleHints()->mouseDoubleClickInterval() + 10);
// Accept touch and mouse
eventItem1->acceptTouch = true;
eventItem1->setAcceptedMouseButtons(Qt::LeftButton);
p1 = QPoint(20, 20);
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
QTest::touchEvent(window.data(), device).press(0, p1, window.data());
QQuickTouchUtils::flush(window.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
QCOMPARE(eventItem1->eventList.size(), 1);
QCOMPARE(eventItem1->eventList.at(0).type, QEvent::TouchBegin);
p1 += QPoint(10, 0);
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
QTest::touchEvent(window.data(), device).move(0, p1, window.data());
QQuickTouchUtils::flush(window.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
QCOMPARE(eventItem1->eventList.size(), 2);
QCOMPARE(eventItem1->eventList.at(1).type, QEvent::TouchUpdate);
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
QTest::touchEvent(window.data(), device).release(0, p1, window.data());
QQuickTouchUtils::flush(window.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
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());
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
// window->setSource(testFileUrl("singleitem.qml"));
// window->show();
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
// QQuickViewTestUtil::centerOnScreen(window.data());
// QVERIFY(QTest::qWaitForWindowActive(window.data()));
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
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
// 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);
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
// QTest::touchEvent(window.data(), device).press(0, p1, window.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
// // QEXPECT_FAIL("", "We do not implement event filters correctly", Abort);
// QCOMPARE(eventItem1->eventList.size(), 0);
// QCOMPARE(filter->eventList.size(), 1);
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
// QTest::touchEvent(window.data(), device).release(0, p1, window.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
// QCOMPARE(eventItem1->eventList.size(), 0);
// QCOMPARE(filter->eventList.size(), 2);
// delete filter;
}
void tst_TouchMouse::mouse()
{
// eventItem1
// - eventItem2
QTest::qWait(qApp->styleHints()->mouseDoubleClickInterval() + 10);
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());
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
window->setSource(testFileUrl("twoitems.qml"));
window->show();
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
QQuickViewTestUtil::centerOnScreen(window.data());
QVERIFY(QTest::qWaitForWindowActive(window.data()));
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(window->rootObject() != 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
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
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);
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
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);
eventItem1->acceptMouse = true;
// item 2 doesn't accept anything, thus it sees a touch pass by
QPoint p1 = QPoint(30, 30);
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
QTest::touchEvent(window.data(), device).press(0, p1, window.data());
QQuickTouchUtils::flush(window.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
QCOMPARE(eventItem1->eventList.size(), 2);
QCOMPARE(eventItem1->eventList.at(0).type, QEvent::TouchBegin);
QCOMPARE(eventItem1->eventList.at(1).type, QEvent::MouseButtonPress);
}
void tst_TouchMouse::touchOverMouse()
{
// eventItem1
// - eventItem2
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());
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
window->setSource(testFileUrl("twoitems.qml"));
window->show();
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
QQuickViewTestUtil::centerOnScreen(window.data());
QVERIFY(QTest::qWaitForWindowActive(window.data()));
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(window->rootObject() != 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
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
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);
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
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);
eventItem2->acceptTouch = true;
QCOMPARE(eventItem1->eventList.size(), 0);
QPoint p1 = QPoint(20, 20);
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
QTest::touchEvent(window.data(), device).press(0, p1, window.data());
QQuickTouchUtils::flush(window.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
QCOMPARE(eventItem1->eventList.size(), 0);
QCOMPARE(eventItem2->eventList.size(), 1);
QCOMPARE(eventItem2->eventList.at(0).type, QEvent::TouchBegin);
p1 += QPoint(10, 0);
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
QTest::touchEvent(window.data(), device).move(0, p1, window.data());
QQuickTouchUtils::flush(window.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
QCOMPARE(eventItem2->eventList.size(), 2);
QCOMPARE(eventItem2->eventList.at(1).type, QEvent::TouchUpdate);
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
QTest::touchEvent(window.data(), device).release(0, p1, window.data());
QQuickTouchUtils::flush(window.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
QCOMPARE(eventItem2->eventList.size(), 3);
QCOMPARE(eventItem2->eventList.at(2).type, QEvent::TouchEnd);
eventItem2->eventList.clear();
}
void tst_TouchMouse::mouseOverTouch()
{
// eventItem1
// - eventItem2
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());
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
window->setSource(testFileUrl("twoitems.qml"));
window->show();
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
QQuickViewTestUtil::centerOnScreen(window.data());
QVERIFY(QTest::qWaitForWindowActive(window.data()));
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(window->rootObject() != 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
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
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);
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
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;
QPoint p1 = QPoint(20, 20);
QTest::qWait(qApp->styleHints()->mouseDoubleClickInterval() + 10);
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
QTest::touchEvent(window.data(), device).press(0, p1, window.data());
QQuickTouchUtils::flush(window.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
QCOMPARE(eventItem1->eventList.size(), 0);
QCOMPARE(eventItem2->eventList.size(), 2);
QCOMPARE(eventItem2->eventList.at(0).type, QEvent::TouchBegin);
QCOMPARE(eventItem2->eventList.at(1).type, QEvent::MouseButtonPress);
// p1 += QPoint(10, 0);
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
// QTest::touchEvent(window.data(), device).move(0, p1, window.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
// QCOMPARE(eventItem2->eventList.size(), 1);
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
// QTest::touchEvent(window.data(), device).release(0, p1, window.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
// QCOMPARE(eventItem2->eventList.size(), 1);
// eventItem2->eventList.clear();
}
void tst_TouchMouse::buttonOnFlickable()
{
// flickable - height 500 / 1000
// - eventItem1 y: 100, height 100
// - eventItem2 y: 300, height 100
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());
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
window->setSource(testFileUrl("buttononflickable.qml"));
window->show();
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
QQuickViewTestUtil::centerOnScreen(window.data());
QVERIFY(QTest::qWaitForWindowActive(window.data()));
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(window->rootObject() != 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
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
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 :)
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
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;
// should a touch button be touchable on top of flickable? yes :)
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
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;
// 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);
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
QTest::touchEvent(window.data(), device).press(0, p1, window.data());
QQuickTouchUtils::flush(window.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
QTRY_COMPARE(eventItem1->eventList.size(), 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
QCOMPARE(eventItem1->eventList.at(0).type, QEvent::TouchBegin);
QCOMPARE(eventItem1->eventList.at(1).type, QEvent::MouseButtonPress);
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
QTest::touchEvent(window.data(), device).release(0, p1, window.data());
QQuickTouchUtils::flush(window.data());
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(), 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
QCOMPARE(eventItem1->eventList.at(2).type, QEvent::TouchEnd);
QCOMPARE(eventItem1->eventList.at(3).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(4).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);
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
QTest::touchEvent(window.data(), device).press(0, p1, window.data());
QQuickTouchUtils::flush(window.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
QCOMPARE(eventItem2->eventList.size(), 1);
QCOMPARE(eventItem2->eventList.at(0).type, QEvent::TouchBegin);
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
QTest::touchEvent(window.data(), device).release(0, p1, window.data());
QQuickTouchUtils::flush(window.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
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);
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
QTest::touchEvent(window.data(), device).press(0, p1, window.data());
QQuickTouchUtils::flush(window.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
QCOMPARE(eventItem1->eventList.size(), 0);
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
QTest::touchEvent(window.data(), device).release(0, p1, window.data());
QQuickTouchUtils::flush(window.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
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);
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
QTest::touchEvent(window.data(), device).press(0, p1, window.data());
QQuickTouchUtils::flush(window.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
QCOMPARE(eventItem1->eventList.size(), 2);
QCOMPARE(eventItem1->eventList.at(0).type, QEvent::TouchBegin);
QCOMPARE(eventItem1->eventList.at(1).type, QEvent::MouseButtonPress);
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
QQuickWindowPrivate *windowPriv = QQuickWindowPrivate::get(window.data());
Relax assumptions of the value of the touchMouseId This is needed in order to be able to integrate a change that mangles the device identifier into the touch point id in qtbase Change-Id: I7675ade377da51f8da31830c7d43875487680845 Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
2016-10-12 08:50:22 +00:00
QVERIFY(windowPriv->touchMouseId != -1);
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
auto pointerEvent = windowPriv->pointerEventInstance(device);
clarify further exclusive vs. passive grabs Add documentation to the grab-related event and eventpoint methods. Rename "grabber" functions which relate only to the exclusive grab, in cases where it would otherwise be ambiguous. And a few other documentation changes. Change-Id: I1a203c8c06a19d4abdb000f08b387c38341ef476 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2017-02-13 14:18:43 +00:00
QCOMPARE(pointerEvent->point(0)->exclusiveGrabber(), eventItem1);
Prefer public API in test Change-Id: Ib161ffaaea57bdf74e02d0f56c3e02d484a26fcc Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2016-07-07 23:16:11 +00:00
QCOMPARE(window->mouseGrabberItem(), 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();
p1 += QPoint(0, dragDelta);
QPoint p2 = p1 + QPoint(0, dragDelta);
QPoint p3 = p2 + QPoint(0, dragDelta);
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
QQuickTouchUtils::flush(window.data());
QTest::touchEvent(window.data(), device).move(0, p1, window.data());
QQuickTouchUtils::flush(window.data());
QTest::touchEvent(window.data(), device).move(0, p2, window.data());
QQuickTouchUtils::flush(window.data());
QTest::touchEvent(window.data(), device).move(0, p3, window.data());
QQuickTouchUtils::flush(window.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
// we cannot really know when the events get grabbed away
QVERIFY(eventItem1->eventList.size() >= 4);
QCOMPARE(eventItem1->eventList.at(2).type, QEvent::TouchUpdate);
QCOMPARE(eventItem1->eventList.at(3).type, QEvent::MouseMove);
Prefer public API in test Change-Id: Ib161ffaaea57bdf74e02d0f56c3e02d484a26fcc Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2016-07-07 23:16:11 +00:00
QCOMPARE(window->mouseGrabberItem(), flickable);
Relax assumptions of the value of the touchMouseId This is needed in order to be able to integrate a change that mangles the device identifier into the touch point id in qtbase Change-Id: I7675ade377da51f8da31830c7d43875487680845 Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
2016-10-12 08:50:22 +00:00
QVERIFY(windowPriv->touchMouseId != -1);
clarify further exclusive vs. passive grabs Add documentation to the grab-related event and eventpoint methods. Rename "grabber" functions which relate only to the exclusive grab, in cases where it would otherwise be ambiguous. And a few other documentation changes. Change-Id: I1a203c8c06a19d4abdb000f08b387c38341ef476 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2017-02-13 14:18:43 +00:00
QCOMPARE(pointerEvent->point(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
QVERIFY(flickable->isMovingVertically());
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
QTest::touchEvent(window.data(), device).release(0, p3, window.data());
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
QQuickTouchUtils::flush(window.data());
}
void tst_TouchMouse::touchButtonOnFlickable()
{
// flickable - height 500 / 1000
// - eventItem1 y: 100, height 100
// - eventItem2 y: 300, height 100
QScopedPointer<QQuickView> window(createView());
window->setSource(testFileUrl("buttononflickable.qml"));
window->show();
QQuickViewTestUtil::centerOnScreen(window.data());
QVERIFY(QTest::qWaitForWindowActive(window.data()));
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(window->rootObject() != nullptr);
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
QQuickFlickable *flickable = window->rootObject()->findChild<QQuickFlickable*>("flickable");
QVERIFY(flickable);
EventItem *eventItem2 = window->rootObject()->findChild<EventItem*>("eventItem2");
QVERIFY(eventItem2);
QCOMPARE(eventItem2->eventList.size(), 0);
eventItem2->acceptTouch = true;
// 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);
QTest::touchEvent(window.data(), device).press(0, p1, window.data());
QQuickTouchUtils::flush(window.data());
QCOMPARE(eventItem2->eventList.size(), 1);
QCOMPARE(eventItem2->eventList.at(0).type, QEvent::TouchBegin);
QQuickWindowPrivate *windowPriv = QQuickWindowPrivate::get(window.data());
QVERIFY(windowPriv->touchMouseId == -1);
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
auto pointerEvent = windowPriv->pointerEventInstance(device);
Merge remote-tracking branch 'origin/dev' into wip/pointerhandler Change-Id: Ie2894830470a69827d4ace3d8af9bee971e3fbd4
2017-04-13 18:56:01 +00:00
QCOMPARE(pointerEvent->point(0)->grabberItem(), 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
QCOMPARE(window->mouseGrabberItem(), nullptr);
int dragDelta = qApp->styleHints()->startDragDistance() * -0.7;
p1 += QPoint(0, dragDelta);
QPoint p2 = p1 + QPoint(0, dragDelta);
QPoint p3 = p2 + QPoint(0, dragDelta);
QQuickTouchUtils::flush(window.data());
QTest::touchEvent(window.data(), device).move(0, p1, window.data());
QQuickTouchUtils::flush(window.data());
QTest::touchEvent(window.data(), device).move(0, p2, window.data());
QQuickTouchUtils::flush(window.data());
QTest::touchEvent(window.data(), device).move(0, p3, window.data());
QQuickTouchUtils::flush(window.data());
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);
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->eventList.size() > 2);
QCOMPARE(eventItem2->eventList.at(1).type, QEvent::TouchUpdate);
QCOMPARE(window->mouseGrabberItem(), flickable);
QVERIFY(windowPriv->touchMouseId != -1);
Merge remote-tracking branch 'origin/dev' into wip/pointerhandler Change-Id: Ie2894830470a69827d4ace3d8af9bee971e3fbd4
2017-04-13 18:56:01 +00:00
QCOMPARE(pointerEvent->point(0)->grabberItem(), 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());
QTest::touchEvent(window.data(), device).release(0, p3, window.data());
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
QQuickTouchUtils::flush(window.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
}
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);
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
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
#ifdef Q_OS_MACOS
QSKIP("Deadlocks or crashes due to events changes in qtbase");
#endif
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();
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());
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
window->setSource(testFileUrl("buttononflickable.qml"));
window->show();
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
QQuickViewTestUtil::centerOnScreen(window.data());
QVERIFY(QTest::qWaitForWindowActive(window.data()));
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(window->rootObject() != nullptr);
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
QQuickFlickable *flickable = window->rootObject()->findChild<QQuickFlickable*>("flickable");
QVERIFY(flickable);
window->installEventFilter(this);
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 :)
EventItem *eventItem1 = window->rootObject()->findChild<EventItem*>("eventItem1");
QVERIFY(eventItem1);
eventItem1->setAcceptedMouseButtons(Qt::LeftButton);
eventItem1->acceptMouse = true;
// should a touch button be touchable on top of flickable? yes :)
EventItem *eventItem2 = window->rootObject()->findChild<EventItem*>("eventItem2");
QVERIFY(eventItem2);
QCOMPARE(eventItem2->eventList.size(), 0);
eventItem2->acceptTouch = true;
// wait to avoid getting a double click event
QTest::qWait(qApp->styleHints()->mouseDoubleClickInterval() + 10);
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
QQuickWindowPrivate *windowPriv = QQuickWindowPrivate::get(window.data());
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(windowPriv->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);
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
QPoint pEnd = p1;
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
QTest::touchEvent(window.data(), device).press(0, p1, window.data());
QQuickTouchUtils::flush(window.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
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
QTRY_COMPARE(eventItem1->eventList.size(), 1);
QCOMPARE(eventItem1->eventList.at(0).type, QEvent::MouseButtonPress);
QCOMPARE(filteredEventList.count(), 1);
}
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
p1 += QPoint(0, -10);
QPoint p2 = p1 + QPoint(0, -10);
pEnd = p2 + QPoint(0, -10);
QQuickTouchUtils::flush(window.data());
QTest::touchEvent(window.data(), device).move(0, p1, window.data());
QQuickTouchUtils::flush(window.data());
QTest::touchEvent(window.data(), device).move(0, p2, window.data());
QQuickTouchUtils::flush(window.data());
QTest::touchEvent(window.data(), device).move(0, pEnd, window.data());
QQuickTouchUtils::flush(window.data());
QTRY_VERIFY(flickable->isMovingVertically());
if (scrollBeforeDelayIsOver) {
QCOMPARE(eventItem1->eventList.size(), 0);
QCOMPARE(filteredEventList.count(), 0);
} else {
// see at least press, move and ungrab
QTRY_VERIFY(eventItem1->eventList.size() > 2);
QCOMPARE(eventItem1->eventList.at(0).type, QEvent::MouseButtonPress);
QCOMPARE(eventItem1->eventList.last().type, QEvent::UngrabMouse);
QCOMPARE(filteredEventList.count(), 1);
}
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
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
// flickable should have the mouse grab, and have moved the itemForTouchPointId
// for the touchMouseId to the new grabber.
QCOMPARE(window->mouseGrabberItem(), flickable);
QVERIFY(windowPriv->touchMouseId != -1);
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
auto pointerEvent = windowPriv->pointerEventInstance(device);
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(pointerEvent->point(0)->grabberItem(), 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
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::touchEvent(window.data(), device).release(0, pEnd, window.data());
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
QQuickTouchUtils::flush(window.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
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
qCDebug(lcTests) << "expected delivered events: press, release, ungrab" << eventItem1->eventList;
qCDebug(lcTests) << "expected filtered events: delayed press, release" << filteredEventList;
Temporarily skip part of tst_TouchMouse::buttonOnDelayedPressFlickable We can revisit tests involving the replaying of press events soon, after getting them replayed as the original type, i.e. stop synthesizing mouse for touch during replay. Task-number: QTBUG-85607 Change-Id: Ib978c84a5e61bb21e0dc017eb386cadec5390418 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2020-07-15 18:33:36 +00:00
QSKIP("QTBUG-85607");
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_COMPARE(eventItem1->eventList.size(), 3);
QCOMPARE(eventItem1->eventList.at(0).type, QEvent::MouseButtonPress);
QCOMPARE(eventItem1->eventList.at(1).type, QEvent::MouseButtonRelease);
QCOMPARE(eventItem1->eventList.last().type, QEvent::UngrabMouse);
// QQuickWindow filters the delayed press and release
QCOMPARE(filteredEventList.count(), 2);
QCOMPARE(filteredEventList.at(0).type, QEvent::MouseButtonPress);
QCOMPARE(filteredEventList.at(1).type, QEvent::MouseButtonRelease);
} else {
// QQuickWindow filters the delayed press if there was one; otherwise nothing
if (scrollBeforeDelayIsOver) {
QCOMPARE(filteredEventList.count(), 0);
} else {
qCDebug(lcTests) << "expected filtered event: delayed press" << filteredEventList;
QCOMPARE(filteredEventList.count(), 1);
QCOMPARE(filteredEventList.at(0).type, QEvent::MouseButtonPress);
}
}
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
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());
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
window->setSource(testFileUrl("buttonontouch.qml"));
window->show();
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
QQuickViewTestUtil::centerOnScreen(window.data());
QVERIFY(QTest::qWaitForWindowActive(window.data()));
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(window->rootObject() != 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
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
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);
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
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);
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
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);
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
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);
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
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);
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
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);
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
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);
Quick tests: remember positions of stationary points We need Items to receive accurate positions for stationary touch points: that is, the last-known position from the previous touch event. (And we hope that all actual touch-capable platforms also send proper QPA events with correct positions for stationary points. We assert that it's a bug if they don't.) As explained in qtbase 7cef4b6463fdb73ff602ade64b222333dd23e46c, it's OK to retain a copy of a QTest::QTouchEventSequence for this purpose, so that the QMap<int, QTouchEvent::TouchPoint> previousPoints will not be discarded between events. Change-Id: I12a04323b0d82dc325348c0fa3e067a4b63f57e9 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2018-07-03 12:38:46 +00:00
QTest::QTouchEventSequence touchSeq = QTest::touchEvent(window.data(), 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);
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);
Quick tests: remember positions of stationary points We need Items to receive accurate positions for stationary touch points: that is, the last-known position from the previous touch event. (And we hope that all actual touch-capable platforms also send proper QPA events with correct positions for stationary points. We assert that it's a bug if they don't.) As explained in qtbase 7cef4b6463fdb73ff602ade64b222333dd23e46c, it's OK to retain a copy of a QTest::QTouchEventSequence for this purpose, so that the QMap<int, QTouchEvent::TouchPoint> previousPoints will not be discarded between events. Change-Id: I12a04323b0d82dc325348c0fa3e067a4b63f57e9 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2018-07-03 12:38:46 +00:00
touchSeq.press(0, p1, window.data()).commit();
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
QQuickTouchUtils::flush(window.data());
Quick tests: remember positions of stationary points We need Items to receive accurate positions for stationary touch points: that is, the last-known position from the previous touch event. (And we hope that all actual touch-capable platforms also send proper QPA events with correct positions for stationary points. We assert that it's a bug if they don't.) As explained in qtbase 7cef4b6463fdb73ff602ade64b222333dd23e46c, it's OK to retain a copy of a QTest::QTouchEventSequence for this purpose, so that the QMap<int, QTouchEvent::TouchPoint> previousPoints will not be discarded between events. Change-Id: I12a04323b0d82dc325348c0fa3e067a4b63f57e9 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2018-07-03 12:38:46 +00:00
touchSeq.release(0, p1, window.data()).commit();
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
QQuickTouchUtils::flush(window.data());
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(), 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
QCOMPARE(eventItem1->eventList.at(0).type, QEvent::TouchBegin);
QCOMPARE(eventItem1->eventList.at(1).type, QEvent::MouseButtonPress);
QCOMPARE(eventItem1->eventList.at(2).type, QEvent::TouchEnd);
QCOMPARE(eventItem1->eventList.at(3).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(4).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
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
QTest::mouseClick(window.data(), 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
Quick tests: remember positions of stationary points We need Items to receive accurate positions for stationary touch points: that is, the last-known position from the previous touch event. (And we hope that all actual touch-capable platforms also send proper QPA events with correct positions for stationary points. We assert that it's a bug if they don't.) As explained in qtbase 7cef4b6463fdb73ff602ade64b222333dd23e46c, it's OK to retain a copy of a QTest::QTouchEventSequence for this purpose, so that the QMap<int, QTouchEvent::TouchPoint> previousPoints will not be discarded between events. Change-Id: I12a04323b0d82dc325348c0fa3e067a4b63f57e9 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2018-07-03 12:38:46 +00:00
touchSeq.press(0, p1, window.data()).commit();
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
QQuickTouchUtils::flush(window.data());
Quick tests: remember positions of stationary points We need Items to receive accurate positions for stationary touch points: that is, the last-known position from the previous touch event. (And we hope that all actual touch-capable platforms also send proper QPA events with correct positions for stationary points. We assert that it's a bug if they don't.) As explained in qtbase 7cef4b6463fdb73ff602ade64b222333dd23e46c, it's OK to retain a copy of a QTest::QTouchEventSequence for this purpose, so that the QMap<int, QTouchEvent::TouchPoint> previousPoints will not be discarded between events. Change-Id: I12a04323b0d82dc325348c0fa3e067a4b63f57e9 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2018-07-03 12:38:46 +00:00
touchSeq.stationary(0).press(1, p2, window.data()).commit();
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
QQuickTouchUtils::flush(window.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
QCOMPARE(button1->scale(), 1.0);
// This event seems to be discarded, let's ignore it for now until someone digs into pincharea
p1 -= QPoint(10, 0);
p2 += QPoint(10, 0);
Quick tests: remember positions of stationary points We need Items to receive accurate positions for stationary touch points: that is, the last-known position from the previous touch event. (And we hope that all actual touch-capable platforms also send proper QPA events with correct positions for stationary points. We assert that it's a bug if they don't.) As explained in qtbase 7cef4b6463fdb73ff602ade64b222333dd23e46c, it's OK to retain a copy of a QTest::QTouchEventSequence for this purpose, so that the QMap<int, QTouchEvent::TouchPoint> previousPoints will not be discarded between events. Change-Id: I12a04323b0d82dc325348c0fa3e067a4b63f57e9 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2018-07-03 12:38:46 +00:00
touchSeq.move(0, p1, window.data()).move(1, p2, window.data()).commit();
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
QQuickTouchUtils::flush(window.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
p1 -= QPoint(10, 0);
p2 += QPoint(10, 0);
Quick tests: remember positions of stationary points We need Items to receive accurate positions for stationary touch points: that is, the last-known position from the previous touch event. (And we hope that all actual touch-capable platforms also send proper QPA events with correct positions for stationary points. We assert that it's a bug if they don't.) As explained in qtbase 7cef4b6463fdb73ff602ade64b222333dd23e46c, it's OK to retain a copy of a QTest::QTouchEventSequence for this purpose, so that the QMap<int, QTouchEvent::TouchPoint> previousPoints will not be discarded between events. Change-Id: I12a04323b0d82dc325348c0fa3e067a4b63f57e9 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2018-07-03 12:38:46 +00:00
touchSeq.move(0, p1, window.data()).move(1, p2, window.data()).commit();
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
QQuickTouchUtils::flush(window.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
// QCOMPARE(button1->scale(), 1.5);
qDebug() << "Button scale: " << button1->scale();
p1 -= QPoint(10, 0);
p2 += QPoint(10, 0);
Quick tests: remember positions of stationary points We need Items to receive accurate positions for stationary touch points: that is, the last-known position from the previous touch event. (And we hope that all actual touch-capable platforms also send proper QPA events with correct positions for stationary points. We assert that it's a bug if they don't.) As explained in qtbase 7cef4b6463fdb73ff602ade64b222333dd23e46c, it's OK to retain a copy of a QTest::QTouchEventSequence for this purpose, so that the QMap<int, QTouchEvent::TouchPoint> previousPoints will not be discarded between events. Change-Id: I12a04323b0d82dc325348c0fa3e067a4b63f57e9 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2018-07-03 12:38:46 +00:00
touchSeq.move(0, p1, window.data()).move(1, p2, window.data()).commit();
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
QQuickTouchUtils::flush(window.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
// QCOMPARE(button1->scale(), 2.0);
qDebug() << "Button scale: " << button1->scale();
Quick tests: remember positions of stationary points We need Items to receive accurate positions for stationary touch points: that is, the last-known position from the previous touch event. (And we hope that all actual touch-capable platforms also send proper QPA events with correct positions for stationary points. We assert that it's a bug if they don't.) As explained in qtbase 7cef4b6463fdb73ff602ade64b222333dd23e46c, it's OK to retain a copy of a QTest::QTouchEventSequence for this purpose, so that the QMap<int, QTouchEvent::TouchPoint> previousPoints will not be discarded between events. Change-Id: I12a04323b0d82dc325348c0fa3e067a4b63f57e9 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2018-07-03 12:38:46 +00:00
touchSeq.release(0, p1, window.data()).release(1, p2, window.data()).commit();
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
QQuickTouchUtils::flush(window.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
// QVERIFY(eventItem1->eventList.isEmpty());
// QCOMPARE(button1->scale(), 2.0);
qDebug() << "Button scale: " << button1->scale();
// 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);
Quick tests: remember positions of stationary points We need Items to receive accurate positions for stationary touch points: that is, the last-known position from the previous touch event. (And we hope that all actual touch-capable platforms also send proper QPA events with correct positions for stationary points. We assert that it's a bug if they don't.) As explained in qtbase 7cef4b6463fdb73ff602ade64b222333dd23e46c, it's OK to retain a copy of a QTest::QTouchEventSequence for this purpose, so that the QMap<int, QTouchEvent::TouchPoint> previousPoints will not be discarded between events. Change-Id: I12a04323b0d82dc325348c0fa3e067a4b63f57e9 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2018-07-03 12:38:46 +00:00
touchSeq.press(0, p1, window.data()).press(1, p2, window.data()).commit();
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
QQuickTouchUtils::flush(window.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
QCOMPARE(button1->scale(), 1.0);
QCOMPARE(eventItem1->eventList.count(), 2);
QCOMPARE(eventItem1->eventList.at(0).type, QEvent::TouchBegin);
QCOMPARE(eventItem1->eventList.at(1).type, QEvent::MouseButtonPress);
// This event seems to be discarded, let's ignore it for now until someone digs into pincharea
p1 -= QPoint(10, 0);
p2 += QPoint(10, 0);
Quick tests: remember positions of stationary points We need Items to receive accurate positions for stationary touch points: that is, the last-known position from the previous touch event. (And we hope that all actual touch-capable platforms also send proper QPA events with correct positions for stationary points. We assert that it's a bug if they don't.) As explained in qtbase 7cef4b6463fdb73ff602ade64b222333dd23e46c, it's OK to retain a copy of a QTest::QTouchEventSequence for this purpose, so that the QMap<int, QTouchEvent::TouchPoint> previousPoints will not be discarded between events. Change-Id: I12a04323b0d82dc325348c0fa3e067a4b63f57e9 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2018-07-03 12:38:46 +00:00
touchSeq.move(0, p1, window.data()).move(1, p2, window.data()).commit();
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
QQuickTouchUtils::flush(window.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
p1 -= QPoint(10, 0);
p2 += QPoint(10, 0);
Quick tests: remember positions of stationary points We need Items to receive accurate positions for stationary touch points: that is, the last-known position from the previous touch event. (And we hope that all actual touch-capable platforms also send proper QPA events with correct positions for stationary points. We assert that it's a bug if they don't.) As explained in qtbase 7cef4b6463fdb73ff602ade64b222333dd23e46c, it's OK to retain a copy of a QTest::QTouchEventSequence for this purpose, so that the QMap<int, QTouchEvent::TouchPoint> previousPoints will not be discarded between events. Change-Id: I12a04323b0d82dc325348c0fa3e067a4b63f57e9 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2018-07-03 12:38:46 +00:00
touchSeq.move(0, p1, window.data()).move(1, p2, window.data()).commit();
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
QQuickTouchUtils::flush(window.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
//QCOMPARE(button1->scale(), 1.5);
qDebug() << button1->scale();
p1 -= QPoint(10, 0);
p2 += QPoint(10, 0);
Quick tests: remember positions of stationary points We need Items to receive accurate positions for stationary touch points: that is, the last-known position from the previous touch event. (And we hope that all actual touch-capable platforms also send proper QPA events with correct positions for stationary points. We assert that it's a bug if they don't.) As explained in qtbase 7cef4b6463fdb73ff602ade64b222333dd23e46c, it's OK to retain a copy of a QTest::QTouchEventSequence for this purpose, so that the QMap<int, QTouchEvent::TouchPoint> previousPoints will not be discarded between events. Change-Id: I12a04323b0d82dc325348c0fa3e067a4b63f57e9 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2018-07-03 12:38:46 +00:00
touchSeq.move(0, p1, window.data()).move(1, p2, window.data()).commit();
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
QQuickTouchUtils::flush(window.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
qDebug() << button1->scale();
//QCOMPARE(button1->scale(), 2.0);
Quick tests: remember positions of stationary points We need Items to receive accurate positions for stationary touch points: that is, the last-known position from the previous touch event. (And we hope that all actual touch-capable platforms also send proper QPA events with correct positions for stationary points. We assert that it's a bug if they don't.) As explained in qtbase 7cef4b6463fdb73ff602ade64b222333dd23e46c, it's OK to retain a copy of a QTest::QTouchEventSequence for this purpose, so that the QMap<int, QTouchEvent::TouchPoint> previousPoints will not be discarded between events. Change-Id: I12a04323b0d82dc325348c0fa3e067a4b63f57e9 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2018-07-03 12:38:46 +00:00
touchSeq.release(0, p1, window.data()).release(1, p2, window.data()).commit();
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
QQuickTouchUtils::flush(window.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
// QCOMPARE(eventItem1->eventList.size(), 99);
qDebug() << button1->scale();
//QCOMPARE(button1->scale(), 2.0);
}
void tst_TouchMouse::pinchOnFlickable()
{
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());
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
window->setSource(testFileUrl("pinchonflickable.qml"));
window->show();
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
QQuickViewTestUtil::centerOnScreen(window.data());
QVERIFY(QTest::qWaitForWindowActive(window.data()));
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(window->rootObject() != 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
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
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);
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
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);
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
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);
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
QTest::touchEvent(window.data(), device).press(0, p, window.data());
QQuickTouchUtils::flush(window.data());
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);
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
QTest::touchEvent(window.data(), device).move(0, p, window.data());
QQuickTouchUtils::flush(window.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
p -= QPoint(10, 0);
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
QTest::touchEvent(window.data(), device).move(0, p, window.data());
QQuickTouchUtils::flush(window.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
p -= QPoint(10, 0);
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
QTest::touchEvent(window.data(), device).move(0, p, window.data());
QQuickTouchUtils::flush(window.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
p -= QPoint(10, 0);
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
QTest::touchEvent(window.data(), device).move(0, p, window.data());
QQuickTouchUtils::flush(window.data());
QTest::touchEvent(window.data(), device).release(0, p, window.data());
QQuickTouchUtils::flush(window.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
QGuiApplication::processEvents();
QTest::qWait(10);
QVERIFY(!flickable->isAtXBeginning());
// wait until flicking is done
QTRY_VERIFY(!flickable->isFlicking());
// pinch
QPoint p1 = QPoint(40, 20);
QPoint p2 = QPoint(60, 20);
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
QTest::QTouchEventSequence pinchSequence = QTest::touchEvent(window.data(), device);
QQuickTouchUtils::flush(window.data());
pinchSequence.press(0, p1, window.data()).commit();
QQuickTouchUtils::flush(window.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
// 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.
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
pinchSequence.stationary(0).press(1, p2, window.data()).commit();
QQuickTouchUtils::flush(window.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
p1 -= QPoint(10,10);
p2 += QPoint(10,10);
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
pinchSequence.move(0, p1, window.data()).move(1, p2, window.data()).commit();
QQuickTouchUtils::flush(window.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
QCOMPARE(rect->scale(), 1.0);
p1 -= QPoint(10, 0);
p2 += QPoint(10, 0);
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
pinchSequence.move(0, p1, window.data()).move(1, p2, window.data()).commit();
QQuickTouchUtils::flush(window.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
p1 -= QPoint(10, 0);
p2 += QPoint(10, 0);
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
pinchSequence.move(0, p1, window.data()).move(1, p2, window.data()).commit();
QQuickTouchUtils::flush(window.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
p1 -= QPoint(10, 0);
p2 += QPoint(10, 0);
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
pinchSequence.move(0, p1, window.data()).move(1, p2, window.data()).commit();
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());
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
QQuickTouchUtils::flush(window.data());
pinchSequence.release(0, p1, window.data()).release(1, p2, window.data()).commit();
QQuickTouchUtils::flush(window.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
QVERIFY(rect->scale() > 1.0);
}
void tst_TouchMouse::flickableOnPinch()
{
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());
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
window->setSource(testFileUrl("flickableonpinch.qml"));
window->show();
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
QQuickViewTestUtil::centerOnScreen(window.data());
QVERIFY(QTest::qWaitForWindowActive(window.data()));
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(window->rootObject() != 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
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
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);
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
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);
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
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);
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
QTest::touchEvent(window.data(), device).press(0, p, window.data());
QQuickTouchUtils::flush(window.data());
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);
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
QTest::touchEvent(window.data(), device).move(0, p, window.data());
QQuickTouchUtils::flush(window.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
p -= QPoint(10, 0);
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
QTest::touchEvent(window.data(), device).move(0, p, window.data());
QQuickTouchUtils::flush(window.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
QTest::qWait(1000);
p -= QPoint(10, 0);
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
QTest::touchEvent(window.data(), device).move(0, p, window.data());
QQuickTouchUtils::flush(window.data());
QTest::touchEvent(window.data(), device).release(0, p, window.data());
QQuickTouchUtils::flush(window.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
QTest::qWait(1000);
//QVERIFY(flickable->isMovingHorizontally());
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
qDebug() << "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);
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
QTest::QTouchEventSequence pinchSequence = QTest::touchEvent(window.data(), device);
pinchSequence.press(0, p1, window.data()).commit();
QQuickTouchUtils::flush(window.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
// 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.
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
pinchSequence.stationary(0).press(1, p2, window.data()).commit();
QQuickTouchUtils::flush(window.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
p1 -= QPoint(10,10);
p2 += QPoint(10,10);
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
pinchSequence.move(0, p1, window.data()).move(1, p2, window.data()).commit();
QQuickTouchUtils::flush(window.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
QCOMPARE(rect->scale(), 1.0);
p1 -= QPoint(10, 0);
p2 += QPoint(10, 0);
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
pinchSequence.move(0, p1, window.data()).move(1, p2, window.data()).commit();
QQuickTouchUtils::flush(window.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
p1 -= QPoint(10, 0);
p2 += QPoint(10, 0);
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
pinchSequence.move(0, p1, window.data()).move(1, p2, window.data()).commit();
QQuickTouchUtils::flush(window.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
p1 -= QPoint(10, 0);
p2 += QPoint(10, 0);
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
pinchSequence.move(0, p1, window.data()).move(1, p2, window.data()).commit();
QQuickTouchUtils::flush(window.data());
pinchSequence.release(0, p1, window.data()).release(1, p2, window.data()).commit();
QQuickTouchUtils::flush(window.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
QVERIFY(rect->scale() > 1.0);
}
void tst_TouchMouse::mouseOnFlickableOnPinch()
{
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());
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
window->setSource(testFileUrl("mouseonflickableonpinch.qml"));
window->show();
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
QQuickViewTestUtil::centerOnScreen(window.data());
QVERIFY(QTest::qWaitForWindowActive(window.data()));
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(window->rootObject() != nullptr);
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
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
QRect windowRect = QRect(window->position(), window->size());
QCursor::setPos(windowRect.center());
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
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
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);
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
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);
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
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);
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
QTest::touchEvent(window.data(), device).press(0, p, window.data());
QQuickTouchUtils::flush(window.data());
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);
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
QTest::touchEvent(window.data(), device).move(0, p, window.data());
QQuickTouchUtils::flush(window.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
p -= QPoint(10, 0);
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
QTest::touchEvent(window.data(), device).move(0, p, window.data());
QQuickTouchUtils::flush(window.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
p -= QPoint(10, 0);
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
QTest::touchEvent(window.data(), device).move(0, p, window.data());
QQuickTouchUtils::flush(window.data());
QTest::touchEvent(window.data(), device).release(0, p, window.data());
QQuickTouchUtils::flush(window.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
//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());
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
qDebug() << "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);
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
QTest::QTouchEventSequence pinchSequence = QTest::touchEvent(window.data(), device);
pinchSequence.press(0, p1, window.data()).commit();
QQuickTouchUtils::flush(window.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
// 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.
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
pinchSequence.stationary(0).press(1, p2, window.data()).commit();
QQuickTouchUtils::flush(window.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
p1 -= QPoint(10,10);
p2 += QPoint(10,10);
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
pinchSequence.move(0, p1, window.data()).move(1, p2, window.data()).commit();
QQuickTouchUtils::flush(window.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
QCOMPARE(rect->scale(), 1.0);
p1 -= QPoint(10, 0);
p2 += QPoint(10, 0);
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
pinchSequence.move(0, p1, window.data()).move(1, p2, window.data()).commit();
QQuickTouchUtils::flush(window.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
p1 -= QPoint(10, 0);
p2 += QPoint(10, 0);
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
pinchSequence.move(0, p1, window.data()).move(1, p2, window.data()).commit();
QQuickTouchUtils::flush(window.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
p1 -= QPoint(10, 0);
p2 += QPoint(10, 0);
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
pinchSequence.move(0, p1, window.data()).move(1, p2, window.data()).commit();
QQuickTouchUtils::flush(window.data());
pinchSequence.release(0, p1, window.data()).release(1, p2, window.data()).commit();
QQuickTouchUtils::flush(window.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
QVERIFY(rect->scale() > 1.0);
// PinchArea should steal the event after flicking started
rect->setScale(1.0);
flickable->setContentX(0.0);
p = QPoint(100, 100);
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
pinchSequence.press(0, p, window.data()).commit();
QQuickTouchUtils::flush(window.data());
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);
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
pinchSequence.move(0, p, window.data()).commit();
QQuickTouchUtils::flush(window.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
p -= QPoint(10, 0);
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
pinchSequence.move(0, p, window.data()).commit();
QQuickTouchUtils::flush(window.data());
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);
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
pinchSequence.move(0, p, window.data()).commit();
QQuickTouchUtils::flush(window.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
Prefer public API in test Change-Id: Ib161ffaaea57bdf74e02d0f56c3e02d484a26fcc Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2016-07-07 23:16:11 +00:00
QCOMPARE(window->mouseGrabberItem(), 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
// Add a second finger, this should lead to stealing
p1 = QPoint(40, 100);
p2 = QPoint(60, 100);
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
pinchSequence.stationary(0).press(1, p2, window.data()).commit();
QQuickTouchUtils::flush(window.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
QCOMPARE(rect->scale(), 1.0);
p1 -= QPoint(5, 0);
p2 += QPoint(5, 0);
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
pinchSequence.move(0, p1, window.data()).move(1, p2, window.data()).commit();
QQuickTouchUtils::flush(window.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
p1 -= QPoint(5, 0);
p2 += QPoint(5, 0);
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
pinchSequence.move(0, p1, window.data()).move(1, p2, window.data()).commit();
QQuickTouchUtils::flush(window.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
p1 -= QPoint(5, 0);
p2 += QPoint(5, 0);
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
pinchSequence.move(0, p1, window.data()).move(1, p2, window.data()).commit();
QQuickTouchUtils::flush(window.data());
pinchSequence.release(0, p1, window.data()).release(1, p2, window.data()).commit();
QQuickTouchUtils::flush(window.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
QVERIFY(rect->scale() > 1.0);
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
pinchSequence.release(0, p, window.data()).commit();
QQuickTouchUtils::flush(window.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
}
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()
{
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());
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
window->setSource(testFileUrl("twoMouseAreas.qml"));
window->show();
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
QQuickViewTestUtil::centerOnScreen(window.data());
QVERIFY(QTest::qWaitForWindowActive(window.data()));
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(window->rootObject() != nullptr);
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 =
window->rootObject()->findChild<QQuickMouseArea*>("rear mouseArea");
QSignalSpy bottomClickedSpy(bottomMouseArea, SIGNAL(clicked(QQuickMouseEvent*)));
QSignalSpy bottomDoubleClickedSpy(bottomMouseArea,
SIGNAL(doubleClicked(QQuickMouseEvent*)));
// tap the front mouse area (see qml file)
QPoint p1(20, 20);
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
QTest::touchEvent(window.data(), device).press(0, p1, window.data());
QQuickTouchUtils::flush(window.data());
QTest::touchEvent(window.data(), device).release(0, p1, window.data());
QQuickTouchUtils::flush(window.data());
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
QCOMPARE(bottomClickedSpy.count(), 1);
QCOMPARE(bottomDoubleClickedSpy.count(), 0);
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
QTest::touchEvent(window.data(), device).press(0, p1, window.data());
QQuickTouchUtils::flush(window.data());
QTest::touchEvent(window.data(), device).release(0, p1, window.data());
QQuickTouchUtils::flush(window.data());
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
QCOMPARE(bottomClickedSpy.count(), 1);
QCOMPARE(bottomDoubleClickedSpy.count(), 1);
}
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()
{
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());
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
window->setSource(testFileUrl("twosiblingitems.qml"));
window->show();
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
QQuickViewTestUtil::centerOnScreen(window.data());
QVERIFY(QTest::qWaitForWindowActive(window.data()));
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(window->rootObject() != 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
EventItem *leftItem = window->rootObject()->findChild<EventItem*>("leftItem");
QVERIFY(leftItem);
EventItem *rightItem = window->rootObject()->findChild<EventItem*>("rightItem");
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);
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
QTest::touchEvent(window.data(), device).press(0, p1, window.data());
QQuickTouchUtils::flush(window.data());
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(leftItem->eventList.size(), 2);
QCOMPARE(leftItem->eventList.at(0).type, QEvent::TouchBegin);
QCOMPARE(leftItem->eventList.at(1).type, QEvent::MouseButtonPress);
QCOMPARE(window->mouseGrabberItem(), leftItem);
leftItem->eventList.clear();
rightItem->acceptTouch = true;
{
Use QList instead of QVector Task-number: QTBUG-84469 Change-Id: I4c3353c00a566023503fbc178ba8454391dc334c Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2020-06-22 10:12:52 +00:00
QList<int> ids;
Relax assumptions of the value of the touchMouseId This is needed in order to be able to integrate a change that mangles the device identifier into the touch point id in qtbase Change-Id: I7675ade377da51f8da31830c7d43875487680845 Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
2016-10-12 08:50:22 +00:00
ids.append(leftItem->point0);
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
rightItem->grabTouchPoints(ids);
}
// 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);
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
QCOMPARE(window->mouseGrabberItem(), (QQuickItem*)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
}
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
QScopedPointer<QQuickView> window(createView());
window->setSource(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
window->show();
QQuickViewTestUtil::centerOnScreen(window.data());
QVERIFY(QTest::qWaitForWindowActive(window.data()));
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);
Quick tests: remember positions of stationary points We need Items to receive accurate positions for stationary touch points: that is, the last-known position from the previous touch event. (And we hope that all actual touch-capable platforms also send proper QPA events with correct positions for stationary points. We assert that it's a bug if they don't.) As explained in qtbase 7cef4b6463fdb73ff602ade64b222333dd23e46c, it's OK to retain a copy of a QTest::QTouchEventSequence for this purpose, so that the QMap<int, QTouchEvent::TouchPoint> previousPoints will not be discarded between events. Change-Id: I12a04323b0d82dc325348c0fa3e067a4b63f57e9 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2018-07-03 12:38:46 +00:00
QTest::QTouchEventSequence touchSeq = QTest::touchEvent(window.data(), 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;
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");
QVERIFY(background);
QVERIFY(left);
QVERIFY(middle);
QVERIFY(right);
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); });
Quick tests: remember positions of stationary points We need Items to receive accurate positions for stationary touch points: that is, the last-known position from the previous touch event. (And we hope that all actual touch-capable platforms also send proper QPA events with correct positions for stationary points. We assert that it's a bug if they don't.) As explained in qtbase 7cef4b6463fdb73ff602ade64b222333dd23e46c, it's OK to retain a copy of a QTest::QTouchEventSequence for this purpose, so that the QMap<int, QTouchEvent::TouchPoint> previousPoints will not be discarded between events. Change-Id: I12a04323b0d82dc325348c0fa3e067a4b63f57e9 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2018-07-03 12:38:46 +00:00
touchSeq.press(0, pLeft, window.data()).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
QQuickTouchUtils::flush(window.data());
// 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
Quick tests: remember positions of stationary points We need Items to receive accurate positions for stationary touch points: that is, the last-known position from the previous touch event. (And we hope that all actual touch-capable platforms also send proper QPA events with correct positions for stationary points. We assert that it's a bug if they don't.) As explained in qtbase 7cef4b6463fdb73ff602ade64b222333dd23e46c, it's OK to retain a copy of a QTest::QTouchEventSequence for this purpose, so that the QMap<int, QTouchEvent::TouchPoint> previousPoints will not be discarded between events. Change-Id: I12a04323b0d82dc325348c0fa3e067a4b63f57e9 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2018-07-03 12:38:46 +00:00
touchSeq.stationary(0).press(1, pRightMiddle, window.data()).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
QQuickTouchUtils::flush(window.data());
QCOMPARE(events.size(), 3);
QCOMPARE(events.at(0), middle);
QCOMPARE(events.at(1), right);
QCOMPARE(events.at(2), background);
events.clear();
Quick tests: remember positions of stationary points We need Items to receive accurate positions for stationary touch points: that is, the last-known position from the previous touch event. (And we hope that all actual touch-capable platforms also send proper QPA events with correct positions for stationary points. We assert that it's a bug if they don't.) As explained in qtbase 7cef4b6463fdb73ff602ade64b222333dd23e46c, it's OK to retain a copy of a QTest::QTouchEventSequence for this purpose, so that the QMap<int, QTouchEvent::TouchPoint> previousPoints will not be discarded between events. Change-Id: I12a04323b0d82dc325348c0fa3e067a4b63f57e9 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2018-07-03 12:38:46 +00:00
touchSeq.release(0, pLeft, window.data()).release(1, pRightMiddle, window.data()).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
QQuickTouchUtils::flush(window.data());
QCOMPARE(events.size(), 0); // no accepted events
// Two presses, the first point should come first
Quick tests: remember positions of stationary points We need Items to receive accurate positions for stationary touch points: that is, the last-known position from the previous touch event. (And we hope that all actual touch-capable platforms also send proper QPA events with correct positions for stationary points. We assert that it's a bug if they don't.) As explained in qtbase 7cef4b6463fdb73ff602ade64b222333dd23e46c, it's OK to retain a copy of a QTest::QTouchEventSequence for this purpose, so that the QMap<int, QTouchEvent::TouchPoint> previousPoints will not be discarded between events. Change-Id: I12a04323b0d82dc325348c0fa3e067a4b63f57e9 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2018-07-03 12:38:46 +00:00
touchSeq.press(0, pLeft, window.data()).press(1, pRight, window.data()).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
QQuickTouchUtils::flush(window.data());
QCOMPARE(events.size(), 3);
QCOMPARE(events.at(0), left);
QCOMPARE(events.at(1), right);
QCOMPARE(events.at(2), background);
Quick tests: remember positions of stationary points We need Items to receive accurate positions for stationary touch points: that is, the last-known position from the previous touch event. (And we hope that all actual touch-capable platforms also send proper QPA events with correct positions for stationary points. We assert that it's a bug if they don't.) As explained in qtbase 7cef4b6463fdb73ff602ade64b222333dd23e46c, it's OK to retain a copy of a QTest::QTouchEventSequence for this purpose, so that the QMap<int, QTouchEvent::TouchPoint> previousPoints will not be discarded between events. Change-Id: I12a04323b0d82dc325348c0fa3e067a4b63f57e9 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2018-07-03 12:38:46 +00:00
touchSeq.release(0, pLeft, window.data()).release(1, pRight, window.data()).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
Quick tests: remember positions of stationary points We need Items to receive accurate positions for stationary touch points: that is, the last-known position from the previous touch event. (And we hope that all actual touch-capable platforms also send proper QPA events with correct positions for stationary points. We assert that it's a bug if they don't.) As explained in qtbase 7cef4b6463fdb73ff602ade64b222333dd23e46c, it's OK to retain a copy of a QTest::QTouchEventSequence for this purpose, so that the QMap<int, QTouchEvent::TouchPoint> previousPoints will not be discarded between events. Change-Id: I12a04323b0d82dc325348c0fa3e067a4b63f57e9 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2018-07-03 12:38:46 +00:00
touchSeq.press(0, pRight, window.data()).press(1, pLeft, window.data()).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
QQuickTouchUtils::flush(window.data());
QCOMPARE(events.size(), 3);
QCOMPARE(events.at(0), right);
QCOMPARE(events.at(1), left);
QCOMPARE(events.at(2), background);
Quick tests: remember positions of stationary points We need Items to receive accurate positions for stationary touch points: that is, the last-known position from the previous touch event. (And we hope that all actual touch-capable platforms also send proper QPA events with correct positions for stationary points. We assert that it's a bug if they don't.) As explained in qtbase 7cef4b6463fdb73ff602ade64b222333dd23e46c, it's OK to retain a copy of a QTest::QTouchEventSequence for this purpose, so that the QMap<int, QTouchEvent::TouchPoint> previousPoints will not be discarded between events. Change-Id: I12a04323b0d82dc325348c0fa3e067a4b63f57e9 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2018-07-03 12:38:46 +00:00
touchSeq.release(0, pRight, window.data()).release(1, pLeft, window.data()).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)
Quick tests: remember positions of stationary points We need Items to receive accurate positions for stationary touch points: that is, the last-known position from the previous touch event. (And we hope that all actual touch-capable platforms also send proper QPA events with correct positions for stationary points. We assert that it's a bug if they don't.) As explained in qtbase 7cef4b6463fdb73ff602ade64b222333dd23e46c, it's OK to retain a copy of a QTest::QTouchEventSequence for this purpose, so that the QMap<int, QTouchEvent::TouchPoint> previousPoints will not be discarded between events. Change-Id: I12a04323b0d82dc325348c0fa3e067a4b63f57e9 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2018-07-03 12:38:46 +00:00
touchSeq.press(0, pLeftMiddle, window.data()).press(1, pRightMiddle, window.data()).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);
Quick tests: remember positions of stationary points We need Items to receive accurate positions for stationary touch points: that is, the last-known position from the previous touch event. (And we hope that all actual touch-capable platforms also send proper QPA events with correct positions for stationary points. We assert that it's a bug if they don't.) As explained in qtbase 7cef4b6463fdb73ff602ade64b222333dd23e46c, it's OK to retain a copy of a QTest::QTouchEventSequence for this purpose, so that the QMap<int, QTouchEvent::TouchPoint> previousPoints will not be discarded between events. Change-Id: I12a04323b0d82dc325348c0fa3e067a4b63f57e9 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2018-07-03 12:38:46 +00:00
touchSeq.release(0, pLeftMiddle, window.data()).release(1, pRightMiddle, window.data()).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();
Quick tests: remember positions of stationary points We need Items to receive accurate positions for stationary touch points: that is, the last-known position from the previous touch event. (And we hope that all actual touch-capable platforms also send proper QPA events with correct positions for stationary points. We assert that it's a bug if they don't.) As explained in qtbase 7cef4b6463fdb73ff602ade64b222333dd23e46c, it's OK to retain a copy of a QTest::QTouchEventSequence for this purpose, so that the QMap<int, QTouchEvent::TouchPoint> previousPoints will not be discarded between events. Change-Id: I12a04323b0d82dc325348c0fa3e067a4b63f57e9 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2018-07-03 12:38:46 +00:00
touchSeq.press(0, pRightMiddle, window.data()).press(1, pLeftMiddle, window.data()).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
qDebug() << events;
QCOMPARE(events.size(), 4);
QCOMPARE(events.at(0), middle);
QCOMPARE(events.at(1), right);
QCOMPARE(events.at(2), left);
QCOMPARE(events.at(3), background);
Quick tests: remember positions of stationary points We need Items to receive accurate positions for stationary touch points: that is, the last-known position from the previous touch event. (And we hope that all actual touch-capable platforms also send proper QPA events with correct positions for stationary points. We assert that it's a bug if they don't.) As explained in qtbase 7cef4b6463fdb73ff602ade64b222333dd23e46c, it's OK to retain a copy of a QTest::QTouchEventSequence for this purpose, so that the QMap<int, QTouchEvent::TouchPoint> previousPoints will not be discarded between events. Change-Id: I12a04323b0d82dc325348c0fa3e067a4b63f57e9 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2018-07-03 12:38:46 +00:00
touchSeq.release(0, pRightMiddle, window.data()).release(1, pLeftMiddle, window.data()).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
}
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 tst_TouchMouse::hoverEnabled()
{
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());
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
window->setSource(testFileUrl("hoverMouseAreas.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
QQuickViewTestUtil::centerOnScreen(window.data());
QQuickViewTestUtil::moveMouseAway(window.data());
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
window->show();
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
QVERIFY(QTest::qWaitForWindowActive(window.data()));
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
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);
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
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
QTest::mouseMove(window.data(), 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
QVERIFY(enterSpy1.count() == 1);
QVERIFY(mouseArea1->hovered());
QVERIFY(!mouseArea2->hovered());
// ------------------------- Touch click on mouseArea1
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
QTest::touchEvent(window.data(), device).press(0, p1, window.data());
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
stabilize tst_TouchMouse::hoverEnabled The autotest does not generate the mouse movement that will occur if you touch an actual touchscreen on X11. QQuickWindowPrivate::flushFrameSynchronousEvents() will hover the MouseArea as if the mouse had moved, but that doesn't update QGuiApplicationPrivate::lastCursorPosition. The test checks that the synth mouse move in QQuickWindowPrivate::deliverTouchAsMouse() occurred in response to the touch release, but if flushFrameSynchronousEvents occurs before these lines QVERIFY(mouseArea1->hovered()); QVERIFY(!mouseArea2->hovered()); then it will fail because the touchpoint left mouseArea2 hovered. Also replace QVERIFY with QCOMPARE where we are comparing a value, so that when it fails we can see why. Task-number: QTBUG-55350 Change-Id: I6c9c9ff1aa57c199cdc4be59156bd36e487cbd2b Reviewed-by: Jan Arve Sæther <jan-arve.saether@theqtcompany.com>
2016-08-17 13:05:24 +00:00
QCOMPARE(enterSpy1.count(), 1);
QCOMPARE(enterSpy2.count(), 0);
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->pressed());
QVERIFY(mouseArea1->hovered());
QVERIFY(!mouseArea2->hovered());
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
QTest::touchEvent(window.data(), device).release(0, p1, window.data());
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(clickSpy1.count() == 1);
QVERIFY(mouseArea1->hovered());
QVERIFY(!mouseArea2->hovered());
// ------------------------- Touch click on mouseArea2
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
QTest::touchEvent(window.data(), device).press(0, p2, window.data());
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());
QVERIFY(mouseArea2->pressed());
stabilize tst_TouchMouse::hoverEnabled The autotest does not generate the mouse movement that will occur if you touch an actual touchscreen on X11. QQuickWindowPrivate::flushFrameSynchronousEvents() will hover the MouseArea as if the mouse had moved, but that doesn't update QGuiApplicationPrivate::lastCursorPosition. The test checks that the synth mouse move in QQuickWindowPrivate::deliverTouchAsMouse() occurred in response to the touch release, but if flushFrameSynchronousEvents occurs before these lines QVERIFY(mouseArea1->hovered()); QVERIFY(!mouseArea2->hovered()); then it will fail because the touchpoint left mouseArea2 hovered. Also replace QVERIFY with QCOMPARE where we are comparing a value, so that when it fails we can see why. Task-number: QTBUG-55350 Change-Id: I6c9c9ff1aa57c199cdc4be59156bd36e487cbd2b Reviewed-by: Jan Arve Sæther <jan-arve.saether@theqtcompany.com>
2016-08-17 13:05:24 +00:00
QCOMPARE(enterSpy1.count(), 1);
QCOMPARE(enterSpy2.count(), 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
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
QTest::touchEvent(window.data(), device).release(0, p2, window.data());
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(clickSpy2.count() == 1);
QVERIFY(mouseArea1->hovered());
QVERIFY(!mouseArea2->hovered());
stabilize tst_TouchMouse::hoverEnabled The autotest does not generate the mouse movement that will occur if you touch an actual touchscreen on X11. QQuickWindowPrivate::flushFrameSynchronousEvents() will hover the MouseArea as if the mouse had moved, but that doesn't update QGuiApplicationPrivate::lastCursorPosition. The test checks that the synth mouse move in QQuickWindowPrivate::deliverTouchAsMouse() occurred in response to the touch release, but if flushFrameSynchronousEvents occurs before these lines QVERIFY(mouseArea1->hovered()); QVERIFY(!mouseArea2->hovered()); then it will fail because the touchpoint left mouseArea2 hovered. Also replace QVERIFY with QCOMPARE where we are comparing a value, so that when it fails we can see why. Task-number: QTBUG-55350 Change-Id: I6c9c9ff1aa57c199cdc4be59156bd36e487cbd2b Reviewed-by: Jan Arve Sæther <jan-arve.saether@theqtcompany.com>
2016-08-17 13:05:24 +00:00
QCOMPARE(exitSpy1.count(), 0);
QCOMPARE(exitSpy2.count(), 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
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
QTest::touchEvent(window.data(), device).press(0, p1, window.data());
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
stabilize tst_TouchMouse::hoverEnabled The autotest does not generate the mouse movement that will occur if you touch an actual touchscreen on X11. QQuickWindowPrivate::flushFrameSynchronousEvents() will hover the MouseArea as if the mouse had moved, but that doesn't update QGuiApplicationPrivate::lastCursorPosition. The test checks that the synth mouse move in QQuickWindowPrivate::deliverTouchAsMouse() occurred in response to the touch release, but if flushFrameSynchronousEvents occurs before these lines QVERIFY(mouseArea1->hovered()); QVERIFY(!mouseArea2->hovered()); then it will fail because the touchpoint left mouseArea2 hovered. Also replace QVERIFY with QCOMPARE where we are comparing a value, so that when it fails we can see why. Task-number: QTBUG-55350 Change-Id: I6c9c9ff1aa57c199cdc4be59156bd36e487cbd2b Reviewed-by: Jan Arve Sæther <jan-arve.saether@theqtcompany.com>
2016-08-17 13:05:24 +00:00
QCOMPARE(enterSpy1.count(), 1);
QCOMPARE(enterSpy2.count(), 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->pressed());
QVERIFY(mouseArea1->hovered());
QVERIFY(!mouseArea2->hovered());
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
QTest::touchEvent(window.data(), device).release(0, p1, window.data());
stabilize tst_TouchMouse::hoverEnabled The autotest does not generate the mouse movement that will occur if you touch an actual touchscreen on X11. QQuickWindowPrivate::flushFrameSynchronousEvents() will hover the MouseArea as if the mouse had moved, but that doesn't update QGuiApplicationPrivate::lastCursorPosition. The test checks that the synth mouse move in QQuickWindowPrivate::deliverTouchAsMouse() occurred in response to the touch release, but if flushFrameSynchronousEvents occurs before these lines QVERIFY(mouseArea1->hovered()); QVERIFY(!mouseArea2->hovered()); then it will fail because the touchpoint left mouseArea2 hovered. Also replace QVERIFY with QCOMPARE where we are comparing a value, so that when it fails we can see why. Task-number: QTBUG-55350 Change-Id: I6c9c9ff1aa57c199cdc4be59156bd36e487cbd2b Reviewed-by: Jan Arve Sæther <jan-arve.saether@theqtcompany.com>
2016-08-17 13:05:24 +00:00
QCOMPARE(clickSpy1.count(), 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());
QVERIFY(!mouseArea1->pressed());
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()
{
QScopedPointer<QQuickView> window(createView());
window->setSource(testFileUrl("singleitem.qml"));
window->show();
QQuickViewTestUtil::centerOnScreen(window.data());
QQuickViewTestUtil::moveMouseAway(window.data());
QVERIFY(QTest::qWaitForWindowActive(window.data()));
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;
QPoint p1(20, 20);
QTest::touchEvent(window.data(), device).press(0, p1);
QCOMPARE(window->mouseGrabberItem(), eventItem);
eventItem->eventList.clear();
eventItem->setEnabled(false);
QVERIFY(!eventItem->eventList.isEmpty());
QCOMPARE(eventItem->eventList.at(0).type, QEvent::UngrabMouse);
QTest::touchEvent(window.data(), device).release(0, p1); // clean up potential state
eventItem->setEnabled(true);
QTest::touchEvent(window.data(), device).press(0, p1);
eventItem->eventList.clear();
eventItem->setVisible(false);
QVERIFY(!eventItem->eventList.isEmpty());
QCOMPARE(eventItem->eventList.at(0).type, QEvent::UngrabMouse);
QTest::touchEvent(window.data(), device).release(0, p1); // clean up potential state
}
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"