diff options
author | Tor Arne Vestbø <tor.arne.vestbo@qt.io> | 2018-08-17 13:30:38 +0200 |
---|---|---|
committer | Shawn Rutledge <shawn.rutledge@qt.io> | 2018-08-17 15:01:38 +0000 |
commit | e09f5b17865a09dac41d0f30ef2ea238f38873eb (patch) | |
tree | 2eaf32b8f9727c2009b64056310f1289f3152570 /qtbase.pro | |
parent | a4a730f4cbe63ef14edce6be0dfb50a34eb08255 (diff) |
macOS: Teach QWheelEvent to handle a new ScrollMomentum phase
We detect if there's an upcoming momentum phase using the same trick
used by e.g. Mozilla in their event handling: https://tinyurl.com/yd8lcs4l,
and as recommended by an Apple engineer: https://tinyurl.com/y8yytlgv
The event is not guaranteed to be in the queue, but in practice it seems
to be. If this assumption fails we can add a wait timeout to the event
search instead of using [NSDate distantPast] as a timeout (which only
looks at queued events).
When the momentum phase is detected, QWheelEvent::phase will have the
new ScrollMomentum value, and the phase transitions will be
ScrollBegin -> ScrollUpdate -> ScrollMomentum -> ScrollEnd.
We no longer send ScrollEnd to signify that the user's fingers have
been lifted off the trackpad; rather, the first event with ScrollMomentum
phase means that the fingers have been lifted and macOS is now sending
simulated-momentum events.
This means ScrollEnd is a reliable indicator that the entire scroll
gesture (both the user interaction and the momentum) has ended.
If the ScrollMomentum phase is skipped, it means the user's fingers
came to rest before being lifted, so there is no momentum. In that case
the transitions will be ScrollBegin -> ScrollUpdate -> ScrollEnd.
Task-number: QTBUG-63026
Task-number: QTBUG-65160
Change-Id: I80191a472f6fa892387004c199166a6350124274
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Diffstat (limited to 'qtbase.pro')
0 files changed, 0 insertions, 0 deletions