[Qt-qml] Mouse Event Filtering in QML 2

[Adriano Rezende]

2011/6/13 Alan Alpert <alan.alpert at nokia.com>

> On Sat, 11 Jun 2011 19:18:05 ext Gregory Schlomoff wrote:
> > I think the event propagation behavior is the most intuitive, since it's
> > more or less how it works in html/javascript and I'm really happy how it
> > is now with the fixes on QTBUG-13007.
> >
> > I don't really like the grabMouse suggestion since it may tend to end up
> in
> > grabbing wars, and it's not very declarative by nature.
>
> I agree, it would probably end up requiring a boolean to check if you have
> the
> explicit grab and a lot of JS logic in the MouseAreas to make that work.
>

In the flickable use case, it's the only way


>
> >> On Fri, Jun 10, 2011 at 10:08 PM, Adriano Rezende
> >> <adriano.rezende at openbossa.org<mailto:adriano.rezende at openbossa.org>>
> >> wrote: I think it would be better if the mouse event propagation were
> not
> >> default. In general the blocking behavior is the most common one. Just
> for
> >> special cases, like flickables, the propagation is desired.
>
> It's default if you do not ask to handle the event. If you accept the mouse
> event, it does not propagate by default. If the blocking behaviour is a
> common
> one, then perhaps MouseBlocker would solve this problem?
>
> Also note that this only applies to the 'meta' events like clicked,
> doubleClicked, and pressAndHold. Because they are made of multiple mouse
> events they cannot be forwarded otherwise. Standard Qt mouse events
> (pressed,
> released, mousePositionChanged) behave the same as before.
>
> >> I don't know if it's QtQuick 2.0, but looking at qt-staging code, it
> seems
> >> that MouseArea have a forwardTo property. This property seems like a
> >> workaround to handle a specific use case. If you need to propagate an
> >> event to other levels, in most of the cases you don't know or you don't
> >> care what item(s) could receive that event.
>
> That was a workaround to handle a specific case, and was committed by
> accident. It is now removed (it can still be found as a patch attached to
> QTBUG-13007 if needed).
>
> --
> Alan Alpert
> Senior Engineer
> Nokia, Qt Development Frameworks
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.qt.nokia.com/pipermail/qt-qml/attachments/20110614/fe98b273/attachment.html