1. 15 Dec, 2023 1 commit
  2. 20 Sep, 2023 1 commit
  3. 09 Jun, 2022 1 commit
  4. 14 Apr, 2022 1 commit
  5. 11 Nov, 2021 1 commit
  6. 23 Aug, 2021 1 commit
  7. 08 Jul, 2021 1 commit
  8. 13 May, 2021 1 commit
  9. 21 Apr, 2021 1 commit
  10. 02 Apr, 2021 1 commit
  11. 02 Mar, 2021 1 commit
  12. 04 Feb, 2021 1 commit
  13. 15 Oct, 2020 1 commit
  14. 17 Sep, 2020 1 commit
    • Jonah Williams's avatar
      Deprecate VelocityTracker default constructor and added... · b1d17c91
      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
      b1d17c91
  15. 08 Sep, 2020 1 commit
    • Jonah Williams's avatar
      [framework] make hit slop based on device pointer kind for drag/pan/scale gestures (#64267) · 29898812
      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
      29898812
  16. 07 Sep, 2020 1 commit
  17. 13 Aug, 2020 1 commit
  18. 11 Aug, 2020 1 commit
    • Ian Hickson's avatar
      Fix RangeMaintainingScrollPhysics (#63146) · e3c7fb5b
      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.
      e3c7fb5b
  19. 28 Jul, 2020 1 commit
  20. 11 Jun, 2020 1 commit
  21. 08 May, 2020 1 commit