Nested scrolling regions do not work properly. This has been a known issue for some time, and I'm only creating this ticket to make it easier to find. This isn't a fundamental problem, but just something that needs implementing.
Previous Slack discussion: https://gophers.slack.com/archives/CM87SNCGM/p1591237250177700
In response to a patch by ~inkeliz:
In Gio, the input events are disambiguated by io/router.Router, implemented by the pointerQueue. I think a better solution to the nested scrolling problem is to expand the router to correctly disambiguate scroll events.
Right now the Router doesn't have enough information to know whether one widget can use a particular scroll event. InputOp.Types only says whether a widget is scrollable, not how far it scrolls.
I suggest providing this information by adding it to InputOp, say:
package pointer type InputOp struct { XScrollRange ScrollRange YScrollRange ScrollRange } // ScrollBounds represent a range of scrolling along an axis. type ScrollRange struct { // Min and Max limit the range to [Min,Max] pixels. Min, Max int }I have ideas to handle mobile gesture scrolls, but let's fix the mouse first.
[0] https://gioui.org/issue/148
[1] https://gophers.slack.com/archives/CM87SNCGM/p1591237250177700
How would the scroll ranges be determined? Currently, using the InputOp area seems fine.
What happens when overlapping widgets need to process scroll events but according to some state?
i.e. a list of editors where you want to scroll the text if the editor is in focus and scroll the list otherwise
On Thu Feb 18, 2021 at 11:50 CET, ~pierrec wrote:
How would the scroll ranges be determined? Currently, using the InputOp area seems fine.
Perhaps I misunderstand your question, but scroll ranges are up to the widgets to specify. A widget such as List not yet at its end can specify a large value for the indeterminate bound(s).
What happens when overlapping widgets need to process scroll events but according to some state? i.e. a list of editors where you want to scroll the text if the editor is in focus and scroll the list otherwise
The Editor will use non-zero scroll bounds only when the Editor wants the scroll events, zero otherwise. The mouse event router will make sure to route scroll events accordingly.
Elias
Adding Elias' response to a first round patch. It does clarify a few things.
My suggestion for ranges were not meant as extensions to the existing AreaOps, which already bound the InputOps in the (absolute) x,y dimensions.
Rather, the vertical and horizontal ranges bound the handlers in the (relative) scroll dimensions. For example, a vertical List will report HorizontalRange (Min:0, Max:0) because it can't be scrolled horizontally. If it is scrolled to the top, VerticalRange min will be 0, and its max the total height of the children not yet scrolled into view (or MaxInt if List doesn't know the total height).
With that information, the pointer router can precisely decide where to deliver scroll events. It can even split up a scroll event between multiple handlers if their ranges are lower than the scrolled amount.
Fixed by https://gioui.org/commit/5e1a662b. Thanks, ~pierrec!