diff options
author | Volker Hilsheimer <volker.hilsheimer@qt.io> | 2020-04-21 13:39:59 +0200 |
---|---|---|
committer | Volker Hilsheimer <volker.hilsheimer@qt.io> | 2020-04-25 01:34:04 +0200 |
commit | bc205d81e7c0cc33ee1f5b72c3745c958f3f2aa7 (patch) | |
tree | c11a9eead09ac20c1bc8ca30902ddc85cae9b1e3 /src/widgets/kernel/qapplication.cpp | |
parent | f6bd056803e389ef19d699932fe2c3cb23c1e4af (diff) |
QApplication: deliver all wheel events to widget that accepts the first
For kinetic wheel events, Qt tries to make sure that all events in the
stream go to the widget that accepted the first wheel event.
It did so by directing all events from the stream to the widget from
which the spontaneous event was returned as accepted.
However, that widget might have passed the event on to some other
widgets; e.g QScrollArea forwards wheel events from the viewport to the
relevant scroll bar. The event might then have come back accepted only
because parent propagation kicked in (the scrollbar might not accept
the event, so the parents get a chance, and some parent's scrollbar
ultimately accepts the event).
In this scenario, the wheel widget would be the viewport under the
mouse, when it should have been the scrollbar of the parent. The
next events from the stream were then delivered to a widget that didn't
scroll; and parent propagation is not (and should not be) implemented
for the case where Qt has a wheel widget.
Instead, make the first widget that accepts any initial wheel event
the wheel widget, even if the event was not spontaneous. With this
change, all events from the stream are delivered to the widget that
actually handled the event. That has the effect that ie. a viewport
of a scroll area only gets the first event; all following events are
delivered directly to the scrollbar.
The test case added simulates the different scenarios - nesting of
scroll areas, classic wheel events and a stream of kinetic wheel
events.
[ChangeLog][QtWidgets][QApplication] Wheel events from a device that
creates an event stream are correctly delivered to the widget that
accepts the first wheel event in the stream.
Change-Id: I5ebfc7789b5c32ebc8d881686f450fa05ec92cfe
Fixes: QTBUG-79102
Pick-to: 5.15
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Diffstat (limited to 'src/widgets/kernel/qapplication.cpp')
-rw-r--r-- | src/widgets/kernel/qapplication.cpp | 8 |
1 files changed, 4 insertions, 4 deletions
diff --git a/src/widgets/kernel/qapplication.cpp b/src/widgets/kernel/qapplication.cpp index d0d2ab22ce..1567f7173b 100644 --- a/src/widgets/kernel/qapplication.cpp +++ b/src/widgets/kernel/qapplication.cpp @@ -3010,7 +3010,7 @@ bool QApplication::notify(QObject *receiver, QEvent *e) // // We assume that, when supported, the phase cycle follows the pattern: // - // ScrollBegin (ScrollUpdate* ScrollEnd)+ + // ScrollBegin (ScrollUpdate* ScrollMomentum* ScrollEnd)+ // // This means that we can have scrolling sequences (starting with ScrollBegin) // or partial sequences (after a ScrollEnd and starting with ScrollUpdate). @@ -3024,7 +3024,7 @@ bool QApplication::notify(QObject *receiver, QEvent *e) if (spontaneous && phase == Qt::ScrollBegin) QApplicationPrivate::wheel_widget = nullptr; - QPoint relpos = wheel->position().toPoint(); + const QPoint relpos = wheel->position().toPoint(); if (spontaneous && (phase == Qt::NoScrollPhase || phase == Qt::ScrollUpdate)) QApplicationPrivate::giveFocusAccordingToFocusPolicy(w, e, relpos); @@ -3050,7 +3050,7 @@ QT_WARNING_POP // A new scrolling sequence or partial sequence starts and w has accepted // the event. Therefore, we can set wheel_widget, but only if it's not // the end of a sequence. - if (spontaneous && (phase == Qt::ScrollBegin || phase == Qt::ScrollUpdate)) + if (QApplicationPrivate::wheel_widget == nullptr && (phase == Qt::ScrollBegin || phase == Qt::ScrollUpdate)) QApplicationPrivate::wheel_widget = w; break; } @@ -3069,7 +3069,7 @@ QT_WARNING_POP // we can send it straight to the receiver. d->notify_helper(w, wheel); } else { - // The phase is either ScrollUpdate or ScrollEnd, and wheel_widget + // The phase is either ScrollUpdate, ScrollMomentum, or ScrollEnd, and wheel_widget // is set. Since it accepted the wheel event previously, we continue // sending those events until we get a ScrollEnd, which signifies // the end of the natural scrolling sequence. |