2009/11/25 alex <acas...@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 _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list