[framework] make hit slop based on device pointer kind for drag/pan/scale gestures#64267
[framework] make hit slop based on device pointer kind for drag/pan/scale gestures#64267jonahwilliams merged 10 commits intoflutter:masterfrom
Conversation
| double computeHitSlop(PointerDeviceKind kind) { | ||
| switch (kind) { | ||
| case PointerDeviceKind.mouse: | ||
| case PointerDeviceKind.stylus: |
There was a problem hiding this comment.
unsure if stylus should be treated like mouse or touch, probably the latter to be safe.
| final bool isPostAcceptSlopPastTolerance = | ||
| _gestureAccepted && | ||
| postAcceptSlopTolerance != null && | ||
| postAcceptSlopTolerance != null && |
|
/cc @gspencergoog @dkwingsmt for desktop and gesture stuff. |
| double computeHitSlop(PointerDeviceKind kind) { | ||
| switch (kind) { | ||
| case PointerDeviceKind.mouse: | ||
| case PointerDeviceKind.stylus: |
There was a problem hiding this comment.
Unsure whether styles is more a mouse or touch device...
There was a problem hiding this comment.
yeah, I have no idea really. The only stylus I've ever used was the one that came with the Nintendo DS. In that case, it was more of a precision assist for the existing touch screen. I could imagine for a stylus like that it would not be disambiguated from a touch event.
There was a problem hiding this comment.
lol, I see you asked the same question above...
There was a problem hiding this comment.
And people often use stylii in place of mice when they use it on a drawing surface. I think of stylii as being much more precise than touch, so I'd go with the more precise slop on them.
|
Of course the other question is should the mouse slop be smaller? We could always file an issue and ask for feedback |
|
Friendly ping @gspencergoog @dkwingsmt |
| const Duration kJumpTapTimeout = Duration(milliseconds: 500); | ||
|
|
||
| /// Like [kTouchSlop], but for mouse pointers. | ||
| const double kMouseHitSlop = 1.0; // Logical pixels; |
There was a problem hiding this comment.
Should we be using the word "Mouse" in these? I think something like "kPrecisePointerHitSlop" is more correct, since it wouldn't have to be a mouse (trackpads would have this set too, for instance). We use "precise" as terminology elsewhere (but we also use mouse some places too).
There was a problem hiding this comment.
Renamed to follow the precisePointer pattern
| double computeHitSlop(PointerDeviceKind kind) { | ||
| switch (kind) { | ||
| case PointerDeviceKind.mouse: | ||
| case PointerDeviceKind.stylus: |
There was a problem hiding this comment.
And people often use stylii in place of mice when they use it on a drawing surface. I think of stylii as being much more precise than touch, so I'd go with the more precise slop on them.
| super(debugOwner: debugOwner, kind: kind); | ||
|
|
||
| static VelocityTracker _defaultBuilder(PointerEvent ev) => VelocityTracker(); | ||
| static VelocityTracker _defaultBuilder(PointerEvent ev) => VelocityTracker(ev.kind); |
There was a problem hiding this comment.
nit: it'd be nice if the variable was called event instead of just ev.
| case TargetPlatform.iOS: | ||
| case TargetPlatform.macOS: | ||
| return (PointerEvent ev) => IOSScrollViewFlingVelocityTracker(); | ||
| return (PointerEvent ev) => IOSScrollViewFlingVelocityTracker(ev.kind); |
There was a problem hiding this comment.
Can we rename ev to event here (and below) too?
|
Hello @jonahwilliams. I am using VelocityTracker for a package and this is a breaking change for me. Looking at the code it looks like VelocityTracker doesn't depend in PointerDeviceKind to calculate the velocity no? |
|
The pointer device type is used to configure the amount of touch/drag/pan slop. If you use unknown you will always have touch level low precision. |
|
This change broke builds involving any library that used Any chance this can be modified to take an optional parameter defaulting to Here's an example of a popular plugin that broke when building against |
|
@TahaTesser This change broke another popular plugin jamesblasco/modal_bottom_sheet#69 |
|
To avoid being broken by changes in Flutter, consider adding the tests of your packages to https://github.com/flutter/tests as per policy here: https://flutter.dev/docs/resources/compatibility. |
|
I am using flutter with the mp_chart library and this is the error I am getting Any idea on how to solve it? |

Description
Currently the framework uses fairly large "hit slop" values to disambiguate taps from drags/pans. This makes sense on touch devices where the interaction is not very precise, on mice however it can feel as if the UI is lagging. This is immediately noticeable on our infra dashboard, where it takes almost half of a grid square of drag before the actual drag kicks in.
One potential solution is to always use smaller constants depending on whether the interaction is mouse or touch based. The only reasonable choice is to use the pointer device kind and not target platform - same platform can have different input sources. This requires exposing the pointer device kind in a few new places in several of the gesture detectors, and using the enum to compute the correct hit slop from an expanded set of constants.
This almost works, however there are a few places (notably ListViews) which uses the touch hit slop as a default value in scroll physics. It does not seem like it will be easy to disambiguate a user provided scroll physics constant from the default and/or adjust it somehow - this might require significant changes to scroll physics which I have left out of this PR.
This PR does not adjust:
kTouchSlop used in scroll_physics.dart's minFlingDistance
kTouchSlop used in PrimaryPointerGestureRecognizer/LongPressGestureRecognizer
Before:
After: