GNOME Bugzilla – Bug 738534
Add ::edge-hit signal
Last modified: 2014-10-20 17:01:15 UTC
In other (most touch oriented) toolkits/UIs it is a common pattern to trigger certain actions when a scrollable area hits some boundary, most usually with some edge resistance. Common actions are loading further data when hitting bottom, or reloading/updating if swiping downwards. I'm attaching a patch that adds such signal to GtkScrolledWindow, the signal will trigger only once each time the overshoot limit is hit, so dragging further won't emit again, but releasing and dragging again will. The signal has a GtkPositionType argument so different actions can be implemented. One caveat so far is that this only triggers if the scrolledwindow is is actually scrollable in the expected axis, being attached to overshooting as it is. This might need decoupling, but I can only think on a gtk_scrolled_window_set_edge_hit_sides(sw, side_flags) or a gtk_scrolled_window_set_edge_hit_enabled (sw, position_type, enabled) to allow edge-hit on non scrollable views, neither are specially appealing...
Created attachment 288526 [details] [review] scrolledwindow: Add ::edge-hit signal This signal is emitted whenever user scrolling hits the overshoot edge in the given direction. May be useful to add "reload" or "load more" behaviors in apps.
an example to play with this would be fantastic
Created attachment 288558 [details] quick example Here is a quick example. Seems to work fine. One obvious problem with using this to replace a visible load-more button is that it only works for touch scrolling - if you are using a mouse, you'll never get beyond the first chunk...
(In reply to comment #3) > Here is a quick example. Seems to work fine. One obvious problem with using > this to replace a visible load-more button is that it only works for touch > scrolling - if you are using a mouse, you'll never get beyond the first > chunk... Thanks for making the example :), I forgot to mention that this sort of depends on bug #738533 for mice... with that one you can reach the overshoot limit (and have this triggered) for both pointers and touch.
Review of attachment 288526 [details] [review]: ::: gtk/gtkscrolledwindow.c @@ +555,3 @@ + * The ::edge-hit signal is emitted whenever user initiated scrolling + * makes the scrolledwindow firmly surpass (ie. with some edge resistance) + * the lower or upper limits defined by the adjustment in that orientation. Might be good to mention here that checking for value == lower or value = upper - page is an alternative for when you want to trigger an action as soon as the edge is hit. Also, maybe edge-surpassed or edge-overshot might be a better name for this signal, in light of this fact.
*** Bug 723856 has been marked as a duplicate of this bug. ***
*** Bug 696658 has been marked as a duplicate of this bug. ***
I've finally renamed the signal to ::edge-overshot and pushed. The commit also includes the (adapted) test in comment 3 on tests/