I'd like to drag a Draggable to a DragTarget, and get position information while still being dragged (not yet dropped). This will be both for visual changes and business logic.
See the gif for clarification of what I'd like to do. The green area is a DragTarget. As the Draggable (or rather, the 'feedback' widget of the Draggable, aka a _DragAvatar) is within the DragTarget, I paint both within the DragTarget (the light blue square) and outside the DragTarget (the dark blue line).
This coordinate value is already tracked within _DragAvatar, so it is just a matter of piping it back to the DragTarget

I see two possibilities, but am open to other designs.
- The movement of
_DragAvatars within a DragTarget trigger the builder, with a new parameter of in-motion offsets.
The signature of the builder would change, and the construction of [DragTarget] could signify whether to fire the builder on move, vs keep the existing behavior (only fire the builder on entry/exit)
eg:
typedef DragTargetBuilder<T> = Widget Function(BuildContext context, List<T> candidateData, List<dynamic> rejectedData, List<Offset> candidateOffsets);
-
Pros: drawing within the [DragTarget] becomes simpler, since the [DragTarget] children are rebuilt on each move.
-
Cons: breaking change to [DragTargetBuilder].
2_The movement of _DragAvatars fires a new optional callback on DragTarget, e.g. onMove(T data, Offset offset).
-
Pros: no breaking change, no change to the builder logic.
-
Cons: updating the drawing of children is a more awkward since it is not part of the rebuild. Instead, users would likely need to call another setState after the current build has finished, e.g.
DragTarget(builder: onMove:(_,offset)=>
SchedulerBinding.instance.addPostFrameCallback((_) => setState(()=>_offset = offset));
which means that paint updates are always a frame behind.
Open to suggestions, thanks!
I'd like to drag a
Draggableto aDragTarget, and get position information while still being dragged (not yet dropped). This will be both for visual changes and business logic.See the gif for clarification of what I'd like to do. The green area is a
DragTarget. As theDraggable(or rather, the 'feedback' widget of theDraggable, aka a_DragAvatar) is within theDragTarget, I paint both within theDragTarget(the light blue square) and outside theDragTarget(the dark blue line).This coordinate value is already tracked within
_DragAvatar, so it is just a matter of piping it back to theDragTargetI see two possibilities, but am open to other designs.
_DragAvatarswithin aDragTargettrigger the builder, with a new parameter of in-motion offsets.The signature of the builder would change, and the construction of [DragTarget] could signify whether to fire the builder on move, vs keep the existing behavior (only fire the builder on entry/exit)
eg:
typedef DragTargetBuilder<T> = Widget Function(BuildContext context, List<T> candidateData, List<dynamic> rejectedData, List<Offset> candidateOffsets);Pros: drawing within the [DragTarget] becomes simpler, since the [DragTarget] children are rebuilt on each move.
Cons: breaking change to [DragTargetBuilder].
2_The movement of
_DragAvatarsfires a new optional callback onDragTarget, e.g.onMove(T data, Offset offset).Pros: no breaking change, no change to the builder logic.
Cons: updating the drawing of children is a more awkward since it is not part of the rebuild. Instead, users would likely need to call another setState after the current build has finished, e.g.
which means that paint updates are always a frame behind.
Open to suggestions, thanks!