Re: Multitouch review 3: kinetic scrolling

[Carlos Garnacho <carlosg gnome org>]

Hey,

On mié, 2012-02-01 at 08:00 -0500, Matthias Clasen wrote:
> API
>   GTK_KINETIC_SCROLLING_{NONE,ENABLED,CAPTURE_BUTTON_PRESS}
>   GtkScrolledWindow::kinetic-scrolling property
> 
> Not much API here. Kinetic scrolling is enabled by setting the
> kinetic-scrolling property on the scrolledwindow. You can also add the
> CAPTURE_BUTTON_PRESS flag to that property to opt into the event
> storage/release that we've discussed earlier. This is to prevent a
> button press from triggering an irreversible action before it is known
> if it was just the beginning of a scrolling swipe. Kinetic scrolling
> and button capture are turned on by default.
> 
> Implementation-wise, kinetic scrolling only affects touch devices.
> Overshooting is also implemented using an extra, intermediate window.
> One of the limitations of the overshooting implementations is that the
> scrollbars do not 'bounce'. The deceleration function is hardcoded.

Another thing worth noting, the scrolledwindow stops trying to capture
events if, after a timeout, the touch coordinates didn't move past a
threshold.

> 
> Questions, comments:
> 
> - Restricting kinetic scrolling to touch devices is correct,
> experience-wise, but it makes testing harder. Could we have some debug
> mode ?

That's a fair point. I wonder where's best to do this, an envvar to have
mice and such have GDK_SOURCE_TOUCH sounds icky, although it'd allow to
test all touch-specific code in a go.

> 
> - The documentation of CAPTURE_BUTTON_PRESS states that
>   "This flag should be enabled if the child widget(s) perform
> non-reversible actions on #GtkWidget::button-press-event. If the
> widget does not do so, and handles #GtkWidget::grab-broken-event, it
> might be better off without this flag."
>   Are there any concrete use cases where this flag needs to be turned
> off for best results ? If not, could we get away with just always
> turning it on ?

Disabling CAPTURE_BUTTON_PRESS is mostly about getting a natural
interaction, where the scrolled window and the child can negotiate which
is going to keep handling the events (through handling captured events
on one direction, through GDK/GTK+ grabs on the other), while still
providing user feedback (eg: the button/row/... is pressed, but goes
back to normal as soon as it's clearly scrolling).

The downside is that both unprepared widgets and apps (ie those changing
UI somewhere else on ::button-press-notify) may hinder this. If API
simplicity is preferred, we can get rid of this flag and turn the
property into a boolean, but it'd be great to keep in mind doing
something akin for 4.x.

Another thing that could greatly benefit from !CAPTURE_BUTTON_PRESS is
DnD, with the default settings you always have to wait for the timeout
mentioned above, although through disabling the flag, you could have the
child selectively starting DnD if clicked in the selection or not, as
said this is about making touch interaction feel more natural :)

  Carlos