summaryrefslogtreecommitdiff
path: root/gtk/gtkprintutils.h
diff options
context:
space:
mode:
authorAlexander Mikhaylenko <alexm@gnome.org>2020-12-14 19:57:38 +0500
committerAlexander Mikhaylenko <alexm@gnome.org>2020-12-15 21:21:49 +0500
commit41dcb144274da0b78df4539783862872d581c23c (patch)
treed6fd278bf276af2af618c917c3962cf591e4d8c2 /gtk/gtkprintutils.h
parent29c49e085dd3075c1f05766a52ebaa31db2918c6 (diff)
downloadgtk+-wip/exalm/nested-scrolling.tar.gz
scrolledwindow: Support nested scrollingwip/exalm/nested-scrolling
While it's possible to scroll GtkScrolledWindow with touchscreen gestures, currently it doesn't work for touchpad: GtkScrolledWindow never propagates scroll events and if multiple scrolled windows are nested, only the inner one will receive any events. Since e9fe270e94d6dbae4655f8a31910f9fb7288d457, GtkScrolledWindow handles only full scroll sequences, but still accepts any scroll sequence, causing issues with nested scrolling. Take another step and keep track of the sequence state, checking the direction when a smooth scroll starts and only claiming the sequence if the scrolled window can scroll in the direction of the current scrolling, and otherwise denying it and ignoring any further events until it ends. The check must be done on the bubble phase because if there are nested scrolled windows that can scroll in the same direction, we want to pick the inner one and not the outer one. The check also has to be done in the scroll signal handler, since we don't have scroll deltas available in scroll-begin. After we determine the direction and claim the sequence, we can switch to the capture phase and proceed with scrolling as usual. This also means that there are 3 states of the sequence state: a sequence can be claimed, denied, or during the first invocation of the scroll signal handler it's undecided. This neatly maps to GtkEventSequenceState, so we can reuse it.
Diffstat (limited to 'gtk/gtkprintutils.h')
0 files changed, 0 insertions, 0 deletions