Comment by ~eliasnaur on ~eliasnaur/gio
Sure, why not? Would you like to submit a change to https://git.sr.ht/~eliasnaur/giouiorg?
Comment by ~eliasnaur on ~eliasnaur/gio
I shall try to find some time to work on this, but it won't be before end of this month.
In the meantime, I encourage you look into adding
DragX
andDragY
fields topointer.Filter
. They likely work similar to the existingScrollX
/ScrollY
fields declared on line 68-69 in pointer.go. In fact, you may even get away with using the existing scroll limit values for drag limits for a prototype.
Comment by ~eliasnaur on ~eliasnaur/gio
Thank you for the detailed report, and in particular the bisection. I've pushed a change that alleviates the problem a bit. Your example now scrolls, but not the inner list.
The diagnosis is that with the bisected change, both scrollable Lists receive the drag events, and both would execute a grab of the pointer. Before, the grabs would cancel each other out, but with the change the first grabber wins.
This is not a complete fix, because the outer List processes events before the nested List and thus wins the grab.
I'm not sure what the right fix is.
An option is to rework the List to process events last, but that complicates the List implementation and requires it to lay out children both before and and after scroll events.
Another option is to defer pointer grabs, and resolve multiple grabs by granting the top-most handler the grab, not just the first. This change seems right, and I started working on it. However, I ran into complexities during which I realized that not even top-most grabs will completely fix the issue: what is lacking is ability for the inner/top-most List to scroll until it reaches one of its extremes and then allow the outer List to continue scrolling. This is the behaviour of scroll (z-axis) events, and I'd like to have that for touch-based scrolling as well.
Scroll events are filtered by scroll distance, so perhaps something similar can be done here. Say, a pointer handler can declare its maximum drag distance in each direction, and then the Gio event machinery can route drag events to the handler that have remaining drag distance, prioritized by top-most-ness. That is, the inner List will be dragged until its extreme, and then the outer List and so on.
Since this is a bigger change, I won't be able to work on it right now, but I'd be happy to review any attempts at implementing it.
Comment by ~eliasnaur on ~eliasnaur/gio
Elias Naur referenced this ticket in commit efd31ad.
Comment by ~eliasnaur on ~eliasnaur/gio
Marcel Juffermans referenced this ticket in commit 35ec76e.
REPORTED
RESOLVED FIXEDon ~eliasnaur/gio
Thank you very much for the bisection! I think we need ~eliasnaur's input on this one.
Comment by ~eliasnaur on ~eliasnaur/gio
I suppose it's an improvement, so sure. Please also add a comment to explain the importance of the order of the lines.
Comment by ~eliasnaur on ~eliasnaur/gio
Annoying. Would you like to contribute a patch?
Comment by ~eliasnaur on ~eliasnaur/gio
Absolutely, but I haven't gotten around to to do it. Would you like to attempt it?
Comment by ~eliasnaur on ~eliasnaur/gio
Dave Akers referenced this ticket in commit 016714a.
REPORTED
RESOLVED FIXED