Repository navigation
Gesture detector scale and pan should work together #49025
Description
Use case
Currently in GestureDetector we are unable to use pan and scale together since pan is super of scale, but in reality pan happens when there is one finger on a component and scaling happens when there are multiple fingers. So i don't know why such issue should happens.
Our use case is that we have containers in stack which we want to pan & zoom & rotate using gestures.
Proposal
The gesture detector should be able to call pan related functions on one finger movement and should call scale related function when there is more than on finger movement.
Activity
[-]Gesture detetctor scale and pan should work together[/-][+]Gesture detector scale and pan should work together[/+]Faiyyaz commentedon Jan 21, 2020
Also i have another finding that in iOS environment onPanUpdate is also call one more time when we leave/end pan
yati989 commentedon Apr 28, 2020
Did you find any workaround for your use case? It seems like it is still not possible to use both simultaneously! I want to create a drawing canvas that wants scale gestures (for zooming, panning and rotating) and pan gestures (for drawing) to work simultaneously together. Please help!
Faiyyaz commentedon Apr 29, 2020
No its not possible to use both that's why i asked them to help me!
wanjm commentedon Jul 20, 2020
any one follow this? many people ask for it;
MandarinSmell commentedon Jul 25, 2020
I'm making my own widget, so I need both scaling and panning gestures at the same time. I won't complain that Scaling is superset of Panning gesture... if I can distinguish if users are touching screen with 2 fingers or 1 finger. Even though Flutter says scaling is super set of panning, but there is no way to distinguish if user is trying to scaling or panning. I've never developed iOS, but there are codes which tell how many fingers are on the screen in Android for sure.
So I agree that Flutter must have codes which tells how many fingers on the screen, so developers can know number of fingers on the screen, then we will be able to performing both panning and scaling by checking number of fingers. If number of fingers tells 1, then perform panning by using focalPoint or localFocalPoint. If number of fingers tells 2 or higher, then perform scaling by using scale/horizontalScale/verticalScale factor.
This may cause conflict when users put 2 fingers at first, and suddenly release only 1 finger, so Flutter must update number of fingers too when onScaleUpdate is called, then developers will handle rest of it.
taodo2291 commentedon Sep 11, 2020
As I have known we can use the Listener widget for the listens pointer event, then bases on the pointer id to detect how many fingers are touching the screen.
checkout the package gesture_x_detector for more detail.
we can listen to both scale and pan events.
Anyways, it is better if the Gesture detector can support scale and pan together, so we don't need to build our own custom gesture detector.
dancamdev commentedon Sep 26, 2020
This is a huge flaw in the GestureDetector Widget IMO. The one mentioned is a common use case, and I don't expect two extremely different gestures to collide because one is a superset of the othe.
On top of that, the message isn't clear and onScaleUpdate being used for dragging results in bad naming.
We should strive for having both working at the same time without colliding, handling two different gestures.
xu-baolin commentedon Jan 8, 2021
Hi, everyone,
#73474 This PR will expand the detail parameter of the scale gesture so that developers can get the number of tracking fingers when the event be triggered. I think this can meet the purpose.
xu-baolin commentedon Jan 12, 2021
Scale is a superset so that you can put one finger down, pan, then without lifting that finger put a second down and switch to zooming.
See Also #49025 (comment)
I will close this issue as solved.
Feel free to leave comments to request a reopen or file a new issue if it does not meet your purpose.
github-actions commentedon Aug 7, 2021
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of
flutter doctor -vand a minimal reproduction of the issue.