On Tue, Jan 11, 2011 at 13:00, Chris Lord <[email protected]> wrote: > On Tue, 2011-01-11 at 09:18 +0100, Tomeu Vizoso wrote: >> On Tue, Jan 11, 2011 at 04:41, James Moschou <[email protected]> wrote: >> > On 5 January 2011 02:36, Tomeu Vizoso <[email protected]> wrote: >> >> Hi, >> >> >> >> my understanding by reading MxKineticScrollView's code is that right >> >> now all pointer events will be captured and not passed down to the >> >> contained children, there's one bug already filed about button events: >> >> >> >> http://bugzilla.clutter-project.org/show_bug.cgi?id=2488 >> >> >> >> Additionally, I wonder what could be done so contained children can >> >> also get motion and button events so for example they can react to >> >> horizontal swipes when the scroll view only scrolls vertically. >> >> >> >> Thanks, >> >> >> >> Tomeu > > In the scroll-view's default mode, it uses the bubble phase of the event > mechanism, so if a widget responds to the button event and swallows it, > the scroll-view will not respond to it. > > It can be told to use capture events though (via the 'use-captured' > property) whereby it will steal all events. Previously, this mode would > pretty much disable widgets inside it (unless they were very > specifically written to be put in a kinetic scroll-view), but I recently > added the drag-threshold to MxSettings, so this behaviour is better > defined. > > The button-press event will only be swallowed by the kinetic scroll-view > if the drag threshold is zero - otherwise, this will always pass > through, whether in bubble or capture mode. > > Motion events will not be swallowed until the drag threshold is > surpassed - after which, they will be swallowed. > > The release event will be swallowed if the drag threshold was surpassed, > otherwise it will be passed through. > > Note, that in bubble mode, if a widget swallows the button-press, the > kinetic scroll-view will not respond (buttons do this, for example). > This allows widgets like buttons to be used within scroll views. > > If in capture mode, the scroll-view will only swallow the press if the > drag-threshold is zero. It will swallow the motion and release events > once the drag-threshold is surpassed. > > The drag-threshold allows widgets like buttons to be used in capture > mode, though there may be odd behaviour if scrolling is begun by > clicking a button (I'm not sure if the current button code reacts well > to only receiving the press, but not any motion or release event). > > This allows widgets like web-pages to be used in the finger-scroll, as > they need to respond to button events (for things like links), but you > may still want kinetic scrolling.
Enabling back captured events and setting a dragging threshold works great here for the tapping scenario, thanks. > This doesn't solve the problem of vertical scrolling stealing horizontal > motion events, but I do wonder what use-case this would allow for? Will try to get more details and explain here. Thanks, Tomeu > Hope this helps, > > --Chris > > >> >> _______________________________________________ >> >> clutter-app-devel-list mailing list >> >> [email protected] >> >> http://lists.clutter-project.org/listinfo/clutter-app-devel-list >> >> >> > >> > I'm not familiar with MxScrollView or MxKineticScrollView, but for the >> > sake of reference, UIScrollView from iOS deals with this same issue >> > using a timer: >> > >> > http://developer.apple.com/library/ios/#documentation/uikit/reference/UIScrollView_Class/Reference/UIScrollView.html >> > >> > For a more thorough explanation see "Cover story: How does UIScrollView >> > work": >> > >> > https://github.com/andreyvit/ScrollingMadness >> > >> > However this solution relies on being able to cancel events, which I >> > don't think is possible to do in clutter. >> >> Taps (button release events) can be passed without needing to replay >> events, we can just check in the release handler if we are going to >> consider it a panning gesture or not. If not, we return FALSE and the >> release event will reach the contained children. This is what used to >> be done in Maemo's Tidy: >> >> http://maemo.gitorious.org/fremantle-hildon-desktop/hildon-desktop/blobs/master/src/tidy/tidy-finger-scroll.c#line249 >> >> I agree that taking into account the elapsed time would be a nice addition. >> >> But for gestures composed of button presses and motion events, I don't >> see either how MxKineticScrollView could handle them without stealing >> them from its children. So maybe we need event synthesis and replay? >> >> Regards, >> >> Tomeu >> >> > - James >> > >> _______________________________________________ >> clutter-app-devel-list mailing list >> [email protected] >> http://lists.clutter-project.org/listinfo/clutter-app-devel-list >> > > > _______________________________________________ clutter-app-devel-list mailing list [email protected] http://lists.clutter-project.org/listinfo/clutter-app-devel-list
