Make DragGestureRecognizer abstract methods public

[angelosilvestre]

Resolves #151446

DragGestureRecognizer defines several private abstract methods that are implemented by its subclasses.
In the super_editor package, we'd like to extend PanGestureRecognizer to make it more aggressive, so it can win the gesture arena when placed inside a CustomScrollview. However, since we can't override private methods, tweaking this single function would involve copying the entire DragGestureRecognizer interface and its PanGestureRecognizer implementation.

Methods that were updated in this PR:

Method	Rationale
_hasSufficientGlobalDistanceToAccept	This is the most important method for us. Overriding this method allows tweaking the PanGestureRecognizer to be more aggressive.
_considerFling	In super_editor we use the PanGestureRecognizer, but we want the fling gesture to behave as if it was a VerticalDragRecognizer. We'll use the fling gesture just to scroll vertically.
_finalPosition	I added a getter to be able to access it inside _considerFling.
_globalDistanceMoved	I added a getter to be able to access it inside _hasSufficientGlobalDistanceToAccept.

[angelosilvestre]

I'm not sure which tests could be added here. Since this PR does not change any functionality maybe it doesn't need a test?

[nate-thegrate]

Hi @angelosilvestre, thanks for making this contribution!

I gave a bit of feedback, so take a look when you have a chance 🙂

[nate-thegrate]

Thanks very much for the update, this PR is looking fantastic!

I'll be happy to approve once we get a testing plan sorted out 👍

[nate-thegrate]

Thanks for putting in the work here!

[nate-thegrate]

It looks like there are a couple of test failures: one of them was caused by changes outside this branch, and the other is a dependency loop (that would have gone undetected if we'd kept the relative import).

Using the Axis enum in DragGestureRecognizer has caused gestures.dart and painting.dart to be codependent—in fact, I bet this is why _DragDirection was created in the first place!

In order to resolve this, we could revert to using a public DragDirection enum (or maybe just bool horizontal).

Or we could migrate some code to prevent the loop. Since painting/basic_types.dart is already exporting a type from the foundation package, I think it'd be super straightforward to just move the enums in that file into foundation/basic_types.dart.

@angelosilvestre Sorry that the act of making a few things public is turning out to be more complex than anticipated. I don't think there's anything you need to do at this point; I'll reach out to some folks tomorrow and hopefully we can come up with a solid action plan.

[angelosilvestre]

@nate-thegrate Thanks for the update. Please let me know if there is anything I should do.

[nate-thegrate]

I created #151771 in order to hopefully unblock this PR. I guess we'll see how it goes!

[Piinks]

Such methods include _considerFling, _hasSufficientGlobalDistanceToAccept, among others.

Can you update the PR description to list all of the methods that are being made public, and why? I am not sure all of them need to be exposed in this way.

[Piinks]

What about all of the other methods?

[angelosilvestre]

To make the test simpler I didn't included the other methods. This test doesn't care about the fling gesture, so it wouldn't help here.

[nate-thegrate]

I think the idea behind this comment was: each method that we make public should be included in the test framework.

[angelosilvestre]

Understood. I'll update it.

[angelosilvestre]

Updated.

For our use-case, primaryDragAxis could be kept private, since it has a default implementation and we don't need to change it. However, if someone needs to write a custom VerticalDragRecognizer or a HorizontalDragRecognizer they will need to override primaryDragAxis.

[angelosilvestre]

I think that if those methods should be re-privatized, a default implementation should be provided. Otherwise, it won't be possible to subclass DragGestureRecognizer outside of the flutter package.

[nate-thegrate]

Good point! I can see that as a reason to keep them as public.

…or, we could pull a pro gamer move and turn DragGestureRecognizer into a sealed class. This could help streamline the logic within the framework, and since extending DragGestureRecognizer directly would no longer be possible, developers wouldn't waste any time trying to do it and could instead extend its subclasses (or the base OneSequenceGestureRecognizer class).

[angelosilvestre]

Would it be possible to extend a class that extends a sealed class? I've never done that. If it works, it works for me that way, we could extend PanGestureRecognizer. I'd like to hear @Piinks opinion on that before making this change.

[nate-thegrate]

Would it be possible to extend a class that extends a sealed class?

Yes sir! The main goal of a sealed class is to enable exhaustive pattern-matching:

void foo(DragGestureRecognizer recognizer) {
  switch (recognizer) {
    case HorizontalDragGestureRecognizer():
      // ...
    case VerticalDragGestureRecognizer():
      // ...
    case PanGestureRecognizer():
      // ...
  }
}

Fortunately, passing a subtype of PanGestureRecognizer doesn't break this behavior!

[angelosilvestre]

Sounds good, I'll give it a try.