Re: Minutes of the GTK+ Team Meeting - 2009-11-27
- From: alex <acastro igalia com>
- To: gtk-devel-list gnome org
- Subject: Re: Minutes of the GTK+ Team Meeting - 2009-11-27
- Date: Wed, 25 Nov 2009 16:49:00 +0100
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
some comments about the hildon kinetic scrolling widget
(HildonPannableArea ), it was implemented using moko finger
scroll, the solution was improved so basically we could consider
both options the same one, some of the changes:
- added API (jump-to, scroll-to)
- changed children detection
- added gesture signals
- changed the structure of the composition
- added more events handlers
- added the auto-mode
- reviewed kinetics (very adapted to the N900)
Basically it has a GdkWindow and it captures and later uses or
reinjects the events to the proper children. Before that we did the
test of implementing it as a modification of gtkscrolledwindow with
signals, it was restricted to direct children, not an option for
hildon. We decided to use the gdkwindow+reinjection solution but it
created a very different code so we decided to create a new widget
instead of adding the code. I agree with Kris about adding a new
widget if we do not implement a new support to the event handling that
removes all the gdkwindow/event hadler/signals.
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.
Anyway, not sure if we should think about a touchscreen mode in
the library, not just in the widget if we want to add this kind of
features. Or if this should stay in a mobile/touchscreen specific fork
(hildon/gtk) at least if we do not find any good option to include the
code, was there any debate about this?
I hope it helps.
] [Thread Prev