Open s0nerik opened 4 years ago
Is it also possible to fix this issue using the same approach? Thanks.
@emvaized It's very likely that this PR will fix the issue you've mentioned as well.
@s0nerik Unfortunately, it's not -- I just tried to implement your changes, and issue still persists.
@s0nerik I've also tried your solution with TabView
children of panelBuilder
, and it seems not working as well - panel's still reacting to swipe when scrolling between tabs. Maybe I've implemented it wrong?
@s0nerik UPDATE: It actually solves my problem with Draggable children, but at first you have to move item horizontally, and only after that panel stops to react to the movement of the item.
Maybe your code can be slightly changed in some way, in order to fix it?
@emvaized This fix solves only the problem of counting the vertical component of the horizontal scroll.
If I understood your use-case correctly, you have list items within sliding panel that can be dragged both horizontally and vertically. In your case, there're two vertically-draggable components: SlidingUpPanel, LongPressDraggable. I didn't envision such usages when I wrote it, and, from my experience, having more than one draggable component within the same axis is always problematic (two drags within different axes are OK).
Probably what you're seeing is LongPressDraggable
being dragged the same amount of vertical pixels as the SlidingUpPanel
since AFAIK, Listener
doesn't block any gesture detectors from receiving the drag events.
I think that the only way to fix your problem is to have some sort of drag rejection mechanism within the SlidingUpPanel
.
The way I envision it to work is the following:
SlidingUpPanel
that it should stop any drag it's currently tracking. **_VerticalDragListener
receives the signal_VerticalDragListener
notifies SlidingUpPanel
that the drag was canceledSlidingUpPanel
animates back to the position before drag occurred (should not be visible at all if you notify the panel early enough)* There's already an isDraggable
parameter, and it should* work by simply removing the vertical drag listener from the widget tree, but I'm not sure how the gesture tracking mechanism would react to that. My guess would be that the old Listener callbacks will still be called for the drag that started while it was within the widget tree.
Considering the above, probably using something like ValueListenable
that's listened within the _VerticalDragListener
would be better than a widget property in this case since it won't require the widget tree rebuild to stop the drag from being tracked by the panel, and will definitely work regardless of the way Flutter handles Listener removal from the tree.
@s0nerik
Thanks for extended response!
I got your thought. Just as you guessed, simply wrapping SlidingUpPanel
into ValueListenableBuilder
doesn't help -- panel continues to react to gestures.
Could you please explain, what you mean by this line:
ValueListenable
that's listened within the_VerticalDragListener
Do you mean modifying SlidingUpPanel
constructor in order to make it accept custom ValueListenable
parameter, and then listen to it's value inside _VerticalDragListener
?
@emvaized Yes. Ignoring the drag upon receiving the event from ValueListenable
within the _VerticalDragListener
looks like the way out for me.
@s0nerik Thanks, it seems to work with no issues now :)
Not sure if it will be right to ask you to add these changes to your pull request, since they require wrapping SlidingUpPanel
widget in the ValueListenableBuilder
(at least in my case).
Can this be merged? 🤔 We are waiting for this fix
@JulianBissekkou You can simply import the whole panel.dart
file in your project, and rename class to something like CustomSlidingUpPanel
. It should work until the creators will merge @s0nerik 's patches.
Yes can we merge this. I also have the same problem
Really useful, thanks!
@s0nerik Hi, thanks for this fixing, but now it's not working? can you update this fixing? thanks
Really useful, thanks!
@TheBarn did you solve it? can you help?
@Shahmirzali-Huseynov
Unfortunately, I no longer support the lib's fork. My team decided to abandon this lib due to its limitations/problems. Instead, we made a self-written "sliding panel" implementation that satisfied all of our needs. The lib isn't open-source, unfortunately, but, TBH, it was quite straightforward to implement, so I can only suggest you do the same.
@s0nerik thank you for code, fixed now, it's working
This fixes an issue with horizontally-slideable children in
panelBuilder
that cause the panel to drag vertically during the horizontal scroll.Also, multi-touch recognition prevention is implemented just in case.