- 15 Dec, 2023 1 commit
-
-
Polina Cherkasova authored
-
- 20 Sep, 2023 1 commit
-
-
Kostia Sokolovskyi authored
-
- 09 Jun, 2022 1 commit
-
-
Kate Lovett authored
-
- 14 Apr, 2022 1 commit
-
-
Michael Goderbauer authored
-
- 11 Nov, 2021 1 commit
-
-
nt4f04uNd authored
-
- 23 Aug, 2021 1 commit
-
-
chunhtai authored
-
- 08 Jul, 2021 1 commit
-
-
Alexandre Ardhuin authored
-
- 13 May, 2021 1 commit
-
-
Alexandre Ardhuin authored
-
- 21 Apr, 2021 1 commit
-
-
Phil Quitslund authored
-
- 02 Apr, 2021 1 commit
-
-
Kate Lovett authored
-
- 02 Mar, 2021 1 commit
-
-
Michael Goderbauer authored
-
- 04 Feb, 2021 1 commit
-
-
Ian Hickson authored
-
- 15 Oct, 2020 1 commit
-
-
Kate Lovett authored
-
- 17 Sep, 2020 1 commit
-
-
Jonah Williams authored
Deprecate VelocityTracker default constructor and added VelocityTracker.withKind constructor (#66043) We've gotten feedback that the VelocityTracker change was disruptive, though it did not break any of the flutter framework or customer tests. In order to make the change non-breaking, PointerDeviceKind parameter can be made optional. Nevertheless, this parameter should be provided so that the existing touch handlers can use more accurate gestures on mouse/stylus inputs, so we can encourage this by deprecating the default constructor and pointing users towards the VelocityTracker.withKind constructor that takes a non-optional parameter
-
- 08 Sep, 2020 1 commit
-
-
Jonah Williams authored
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
-
- 07 Sep, 2020 1 commit
-
-
Ian Hickson authored
-
- 13 Aug, 2020 1 commit
-
-
renyou authored
-
- 11 Aug, 2020 1 commit
-
-
Ian Hickson authored
It now uses the scroll metrics as they stood at the end of the last frame. It previously used a weird combination of the old extents and the newish position, which led to some weird effects when the position had been changed in expectation of a viewport or content dimension change.
-
- 28 Jul, 2020 1 commit
-
-
Darren Austin authored
-
- 11 Jun, 2020 1 commit
-
-
Alexandre Ardhuin authored
* add language version 2.8 in packages/flutter * enable non-nullable analyzer flag
-
- 08 May, 2020 1 commit
-
-
Ian Hickson authored
-