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.

This doesn't solve the problem of vertical scrolling stealing horizontal
motion events, but I do wonder what use-case this would allow for?

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

Reply via email to