Kinetic scrolling (was Minutes of the GTK+ Team Meeting - 2009-11-27)

[Javier Jardón <javierjc1982 gmail com>]

2009/11/25 alex <acastro igalia com>:
> On Tue, Nov 24, 2009 at 10:13:20PM +0000, Emmanuele Bassi wrote:
>>
>> [...]
>>
>> 4. Implement finger and kinetic scrolling [jjardon]
>> - Midori has a finger/kinetic scrolled window implementation
>> - Hildon has one as well
>> - OpenMoko had one
>> - would it make sense to port the feature to GtkScrolledWindow when
>>   :gtk-touchscreen-mode is set to TRUE?
>> - issue: event delivery to children requires subclassing to override
>>   current default behaviour of gtk+ widgets


> The main issues now:
>   - Selection/dragging vs scrolling (touchscreen mode?, more complex
>   widgets or subclassing)
>   - Animations with timeouts in gtk are not that good (check Owen posts about
>   that), this is something to discuss about the library
>   - Embedding finger scroll widgets inside each other?
>   - Double events in the callbacks, original and reinjection if
>   widgets do not deal with them.
>
> I do not think this solution is a clean option, we should add clean
> support for this event handling, maybe using top-down widget detection
> in csw or adding new specific gdk event or something like that. We
> could check how to do that.

FYI, This is what was discussed in the meeting: ( see the complete log
here: [1])

 <jjardon> kinetic bug number: https://bugzilla.gnome.org/show_bug.cgi?id=601923
< jjardon> kalikianatoli added support for this in midori recently,
maybe this stuff could be added to gtk+
< shaunm> is this the same kind of widget as HildonPannableArea?  i.e.
you can grab anywhere inside it to flick?
< kalikianatoli> ebassi, I would wonder if it makes sense to support
that in scrolled window itself
< ebassi> kalikianatoli: well, yeah: if we decided to get it in gtk+
I'd definitely vote for adding the feature to ScrolledWindow
< kalikianatoli> shaunm, yep, and you can choose whether it should
just drag, or also move further
< shaunm> ok, so one of the quirks I noticed is that other widgets
needed to be modified/subclassed so as not to consume the drags in
order to work correctly inside a pannable area
< shaunm> because events in gtk are handled innermost-first
< shaunm> at least in hildon.  do other implementations have a less
hacky way around this?
< kalikianatoli> shaunm, Probably a property would solve this. To say
whether it should select or drag
< shaunm> yeah, I'm kind of wondering if gtk could have a cleaner way
for parents to intercept events, without relying on the good faith of
child widgets
< shaunm> maybe a two-pass event propagation: top down and back up
< ebassi> shaunm: just like clutter ;-)
< ebassi> the first pass is: top-level to innermost child; the second
pass is: innermost child to top-level
< ebassi> so the kinetic scroller would intercept the events before
they reach the children
< kalikianatoli> although then you can't know if the child had a
better idea of how to treat the situation
< ebassi> it would imply adding a new event and doing the event chain
in reverse order; then, if nothing returned TRUE, continue with the
current behaviour
< ebassi> kalikianatoli: there are always side effects :-)
< kalikianatoli> a bit like going from not good to not good either :)
< ebassi> you could handle the event and let it through anyway
< kalikianatoli> but I definitely recall more than once where that
would have been useful
< kalikianatoli> so I would like to follow the idea if it can be done
< ebassi> we added that behavioir exactly after doing the finger
scrolling window on openmoko :-)


[1] http://live.gnome.org/GTK%2B/Meetings?action=AttachFile&do=view&target=20091124.txt

-- 
Javier Jardón Cabezas