nit: add a space after period.

nit: space between "whether" and "the".

It sounds like this should default to null if no drag boundary is defined. If not then users might incorrectly think that their drag is within bounds when it is not.

Hello, I have re-examined the code here and found that it's not really necessary to call outOfBoundary, so I removed it. I put the boundary information into DragStartDetails and DragUpdateDetails, so there's no need to add some bad APIs, making it a bit simpler. Please review it again, thank you.

nit: end comment with a period.

I'm wondering if this API is needed to accomplish the given use-cases. Are the use-cases achievable just using DragRectBoundaryProvider?

Here is the example without any API changes to DragGestureRecognizer. I don't think it is too much more code to accomplish the use-case in the example without adding to the DragGestureRecognizer API.

class DragBoundaryExampleApp extends StatefulWidget {
  const DragBoundaryExampleApp({super.key});

  @override
  State<StatefulWidget> createState() => DragBoundaryExampleAppState();
}

class DragBoundaryExampleAppState extends State<DragBoundaryExampleApp> {
  Offset _basePosition = Offset.zero;
  Offset _dragPosition = Offset.zero;
  late DragBoundary? boundaryInfo;
  @override
  Widget build(BuildContext context) {
    final Offset offset = _dragPosition - _basePosition;
    return MaterialApp(
      home: Scaffold(
        body: Padding(
          padding: const EdgeInsets.all(100),
          child: DragRectBoundaryProvider(
            child: Stack(
              children: <Widget>[
                Container(
                  color: Colors.green,
                ),
                Positioned(
                  top: offset.dy,
                  left: offset.dx,
                  child: Builder(
                    builder: (BuildContext context) {
                      return GestureDetector(
                        behavior: HitTestBehavior.translucent,
                        onPanStart: (DragStartDetails details) {
                          boundaryInfo = DragRectBoundaryProvider.of(context)?.getDragBoundary(context, details.globalPosition);
                          setState(() {
                            _basePosition = details.globalPosition - offset;
                            _dragPosition = details.globalPosition;
                          });
                        },
                        onPanUpdate: (DragUpdateDetails details) {
                          setState(() {
                            if (boundaryInfo == null) {
                              return;
                            }
                            if (boundaryInfo!.isWithinBoundary(details.globalPosition)) {
                              _dragPosition = details.globalPosition;
                            } else {
                              _dragPosition = boundaryInfo!.getNearestPositionWithinBoundary(details.globalPosition);
                            }
                          });
                        },
                        child: Container(
                          width: 100,
                          height: 100,
                          color: Colors.red,
                        ),
                      );
                    },
                  ),
                ),
              ],
            ),
          ),
        ),
      ),
    );
  }
}

This is great, but it's hard to cancel the gesture through the boundary without changing the API.

I have some thoughts, as you said, we don't change any APIs to implement the boundary feature, and then let the user actively control the cancellation of the gesture in another way. I will work on this, if you have any ideas, please let me know. @Renzo-Olivares

Can you provide an example on how to use this API to fix the issue described in #146749 .

This GestureController is cool! With regards to GestureDetector would it be possible to send a GestureCancelEvent to a specific recognizer? For example if a user sets both the pan gesture callbacks and tap gesture callbacks, can they cancel just the pan gesture? I didn't see a way to do this when looking.

I'd like to hear more use-cases of cancelling gestures. From this example, I think a similar functionality can be accomplished with the below:

onPanUpdate: (DragUpdateDetails details) {
  if (_isOverlayBlocking) {
    return;
  }
  text = 'PanUpdate';
  setState(() {});
},

Where _isOverlayBlocking is set to true when the visibility of the yellow overlay is set to true. I do see the positive of not having to handle this as a user yourself and simply cancelling the gesture.

I will provide a new example for GestureController in a later PR, this example is indeed not good enough, I think I prefer to reset some things in the PanCancel callback.

nit: consider iterating through the local list of tracked pointers and calling stopTrackingPointer for each tracked pointer.

nit: The wording here is a little confusing. Maybe:

This widget creates a [GestureDragBoundaryProvider] that sets the boundary for a dragged rectangle. The drag rectangle is retrieved from the context provided in [GestureDragBoundaryProvider.getDragBoundary]. The boundary is defined by the rectangle bounds of the provided child widget.

What do you think?

nit: consider changing wording to below,

This widget creates a [GestureDragBoundaryProvider] that sets a boundary for a dragged point. The dragged point is retrieved from the [Offset] provided in [GestureDragBoundaryProvider.getDragBoundary]. The boundary is defined by the rectangle bounds of the provided child widget.

I'm leaning towards this being a different PR since the drag boundary components can work without it.

Sure, I have removed the part about GestureController from this PR.

nit: consider stopTrackingAllPointers instead to follow the naming conventions of similar methods.

nit: consider putting these drag boundary components into their own file.

This is awesome, thanks for decoupling this feature from the gesture detail object.

This will not work if localToGlobal contains scaling. You might want to use Rect.fromPoints with two localToGlobals.

I'm not very familiar with scaling, do you mean like this? Rect.fromPoints(rb!.localToGlobal(Offset.zero), rb.localToGlobal(rb.size.bottomRight(Offset.zero)));

If you are still online, could you provide a commit suggestion for this? I will look into scaling later.

I'm not very familiar with scaling, do you mean like this? Rect.fromPoints(rb!.localToGlobal(Offset.zero), rb.localToGlobal(rb.size.bottomRight(Offset.zero)));

Yes, exactly.

However, when I tried to demonstrate (and verify) it by creating a demo, which uses useGlobalPosition: true, I find it so hard that I start to wonder how it's going to be useful at all. If we want the GestureDetector to be on the rectangle being dragged, and drag boundary must also wrap the rectangle, which means the rectangle's position must not be global, but at least relative to the drag boundary. On the other hand, if the rectangle is positioned on a global overlay, then the drag boundary is unlikely a parent of the rectangle. The only case I can think of is when the GestureDetector is as big as the drag boundary. My point is, can you create an example when useGlobalPosition is true?

On the contrary, useGlobalPosition: true is actually more useful, as it is not always possible to obtain the local position of the drag object within the boundary during use. For example, if this PR is used for ReorderableList, during dragging, ReorderableList needs to use the given DragBoundaryDelegate, and here useGlobalPosition: true must be used.

However, if we can ensure that we are using the local coordinates of the boundary, useGlobalPosition: false can avoid the need for two coordinate conversions.

Why do we return a boundary even if there is none? It feels a little redundant when we can just return null and stop any further logic.

It is for this one:

If no [DragBoundary] ancestor is found, the delegate will return a delegate that allows the drag object to move freely.

This is proposed by me so that using this method is easier and doesn't have to handle nulls.

I think this way it may be hard for a user to differentiate between having no parent DragBoundary and having a default one that allows free movement. Maybe we can provide both methods of and maybeOf?

We can, but when do you think maybeOf will be useful? I think we can add it upon request in the future.

I think its useful if anyone wants to write some fallback logic in case they don't have a DragBoundary ancestor, but i'm okay on adding on request.

I think this way it may be hard for a user to differentiate between having no parent DragBoundary and having a default one that allows free movement. Maybe we can provide both methods of and maybeOf?