Details
-
Task
-
Resolution: Unresolved
-
Not Evaluated
-
None
-
None
-
None
Description
processTouchEvent starts like this:
void QGuiApplicationPrivate::processTouchEvent(QWindowSystemInterfacePrivate::TouchEvent *e)
{
modifier_buttons = e->modifiers;
QPointingDevice *device = const_cast<QPointingDevice *>(static_cast<const QPointingDevice *>(e->device));
QPointingDevicePrivate *devPriv = QPointingDevicePrivate::get(device);
if (e->touchType == QEvent::TouchCancel) {
// The touch sequence has been canceled (e.g. by the compositor).
// Send the TouchCancel to all windows with active touches and clean up.
QTouchEvent touchEvent(QEvent::TouchCancel, device, e->modifiers);
touchEvent.setTimestamp(e->timestamp);
QSet<QWindow *> windowsNeedingCancel;
for (auto &epd : devPriv->activePoints.values()) {
auto &mut = QMutableEventPoint::from(const_cast<QEventPoint &>(epd.eventPoint));
QWindow *w = mut.window();
if (w)
windowsNeedingCancel.insert(w);
}
Since it has to iterate all known touchpoints anyway to figure out which windows need to receive the TouchCancel event, it could just as well add the points to the event(s) that it creates. This would save some trouble during delivery; Qt Quick currently calls this function to insert the missing touchpoints into the event:
/*!
\internal
First, ensure that the \a cancelEvent's QTouchEvent::points() list contains
all points that have exclusive grabs. Then send the event to each object
that has an exclusive grab of any of the points.
*/
void QPointingDevicePrivate::sendTouchCancelEvent(QTouchEvent *cancelEvent)
Perhaps a touch cancel could be treated like any other touch update event then: just send it to the grabbers. So we wouldn't need a separate QQuickDeliveryAgentPrivate::deliverTouchCancelEvent().
It has also happened multiple times that I changed code, wrote it in a way that expected that every QPointerEvent will have at least one point, forgot about TouchCancel, experienced a crash, debugged, added an if to ignore all events that don't have any points (thinking it was a bug), and then eventually realized again why that happened, after noticing that tst_qquickwindow::touchEvent_cancel fails for example. So this is an aspect of unifying delivery logic, so that TouchCancel will stop being such a special case. It will be noticeable to users though, if they've also been writing code like that.