qt5base-lts/tests/auto/gui/kernel/qmouseevent/CMakeLists.txt

# Generated from qmouseevent.pro.

#####################################################################
## tst_qmouseevent Test:
#####################################################################

qt_add_test(tst_qmouseevent
    SOURCES
        tst_qmouseevent.cpp
    PUBLIC_LIBRARIES
        Qt::Gui
        Qt::GuiPrivate
)
cmake: add gui/kernel tests Fixes: QTBUG-78224 Change-Id: I9e6294b5035b066dead0f5ff91f81e472bc56d62 Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> 2019-10-08 14:46:11 +00:00			`# Generated from qmouseevent.pro.`

			`#####################################################################`
			`## tst_qmouseevent Test:`
			`#####################################################################`

CMake: Regenerate tests with new qt_ prefixed APIs Use pro2cmake with '--api-version 2' to force regenerate projects to use the new prefixed qt_foo APIs. Change-Id: I055c4837860319e93aaa6b09d646dda4fc2a4069 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> 2020-07-07 16:01:06 +00:00			`qt_add_test(tst_qmouseevent`
cmake: add gui/kernel tests Fixes: QTBUG-78224 Change-Id: I9e6294b5035b066dead0f5ff91f81e472bc56d62 Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> 2019-10-08 14:46:11 +00:00			`SOURCES`
			`tst_qmouseevent.cpp`
			`PUBLIC_LIBRARIES`
			`Qt::Gui`
Track grab state in QPointingDevicePrivate::activePoints QQuickEventPoint instances were very long-lived and got reused from one event to the next. That was initially done because they were "heavy" QObjects; but it also became useful to store state in them between events. But this is in conflict with the ubiquitous event replay code that assumes it's OK to hold an event instance (especially a QMouseEvent) for any length of time, and then send it to some widget, item or window. Clearly QEventPoints must be stored in the QPointerEvent, if we are to avoid the need for workarounds to keep such old code working. And now they have d-pointers, so copying is cheap. But replay code will need to detach() their QEventPoints now. QEventPoint is useful as an object to hold state, but we now store the truly persistent state separately in an EventPointData struct, in QPointingDevicePrivate::activePoints. Incoming events merely update the persistent points, then we deliver those instead. Thus when event handler code modifies state, it will be remembered even when the delivery is done and the QPA event is destroyed. This gets us a step closer to supporting multiple simultaneous mice. Within pointer events, the points are moved up to QPointerEvent itself: QList<QEventPoint> m_points; This means pointCount(), point(int i) and points() can be non-virtual. However in any QSinglePointEvent, the list only contains one point. We hope that pessimization is worthwhile for the sake of removing virtual functions, simplifying code in event classes themselves, and enabling the use of the range-for loop over points() with any kind of QPointerEvent, not just QTouchEvent. points() is a nicer API for the sake of range-for looping; but point() is more suited to being non-const. In QML it's expected to be OK to emit a signal with a QPointerEvent by value: that will involve copying the event. But QEventPoint instances are explicitly shared, so calling setAccepted() modifies the instance in activePoints (EventPointData.eventPoint.d->accept); and the grabbers are stored separately and thus preserved between events. In code such as MouseArea { onPressed: mouse.accepted = false } we can either continue to emit the QQuickMouseEvent wrapper or perhaps QEvent::setAccepted() could become virtual and set the eventpoint's accepted flag instead, so that it will survive after the event copy that QML sees is discarded. The grabChanged() signal is useful to keep QQuickWindow informed when items or handlers change exclusive or passive grabbers. When a release happens at a different location than the last move event, Qt synthesizes an additional move. But it would be "boring" if QEventPoint::lastXPosition() accessors in any released eventpoint always returned the same as the current QEventPoint::xPosition()s just because of that; and it would mean that the velocity() must always be zero on release, which would make it hard to use the final velocity to drive an animation. So now we expect the lastPositions to be different than current positions in a released eventpoint. De-inline some functions whose implementations might be subject to change later on. Improve documentation. Since we have an accessor for pressTimestamp(), we might as well add one for timestamp() too. That way users get enough information to calculate instantaneous velocity, since the plan is for velocity() to be somewhat smoothed. Change-Id: I2733d847139a1b1bea33c00275459dcd2a145ffc Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> 2020-09-03 19:34:31 +00:00			`Qt::GuiPrivate`
cmake: add gui/kernel tests Fixes: QTBUG-78224 Change-Id: I9e6294b5035b066dead0f5ff91f81e472bc56d62 Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> 2019-10-08 14:46:11 +00:00			`)`