[Qt-qml] Mouse Event Filtering in QML 2

[Adriano Rezende]

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.

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.

How about something like below?

MouseArea {
    anchors.fill: parent
    onPressed: {} // it will be called
    onCanceled: {}

    // the following handlers will be called
    // if the user doesn't change mouse position
    onMousePositionChanged: {}
    onReleased: {}
    onClicked: {}
}

MouseArea {
    anchors.fill: parent
    propagateMouseEvent: true
    onPressed: {} // it will be called
    onMousePositionChanged: grabMouse(); // steal from other grabbers
    onReleased: {} // it will be called
    onClicked: {} // it will be called
}

Br,
Adriano

On Thu, Jun 9, 2011 at 10:35 PM, Alan Alpert <alan.alpert at nokia.com> wrote:

> On Fri, 10 Jun 2011 10:28:03 ext aaron.kennedy at nokia.com wrote:
> > Hi,
> >
> > On 10/06/2011, at 10:02 AM, ext michael.brasser at nokia.com wrote:
> > > On 07/06/2011, at 10:51 AM, ext Alan Alpert wrote:
> > >> On Tue, 7 Jun 2011 01:23:51 Cunha Leo (Nokia-MP-Qt/Oslo) wrote:
> > >>> hi,
> > >>>
> > >>> in qml1 I used to have an empty MouseArea{ enabled: animation.running
> }
> > >>> to filter events while an animation was ongoing.
> > >>>
> > >>> in qml2 this empty mouse area is no longer accepting the events by
> > >>> default, so the only way I found was to declare empty handlers for
> all
> > >>> mouse events.
> > >>>
> > >>> is there a better way to achieve mouse events filtering in qml2 ?
> > >>>
> > >>> cheers,
> > >>> // leo
> > >>
> > >> Currently you do need to declare empty handlers, due to changes in
> mouse
> > >> event propagation, but this is clearly not ideal. I don't think the
> > >> empty mouse area was that great either though. Do you have any
> > >> suggestions on the best way to accomplish this?
> > >
> > > What about a convenience MouseBlocker element? e.g. something like:
> > >
> > > //MouseBlocker.qml
> > > import QtQuick 2.0
> > > MouseArea {
> > >
> > >    onPressed: {}
> > >    onClicked: {}
> > >    onPressAndHold: {}
> > >    onDoubleClicked: {}
> > >
> > > }
> >
> > Has anyone investigated exactly why this has changed?  As far as I know
> it
> > wasn't intentional, so we should probably figure it out and decide which
> > behavior we want before we go developing work arounds :)
>
> It was intentional, it's the fix for QTBUG-13007.
>
> Most of the discussion is in the comments of that issue, but the basic
> reasoning is that the higher level input abstractions need to be propagated
> differently. Qt's standard event processing passes along low-level input
> events like press and release just fine, but does not handle redirecting
> clicks or other events made after the initial press. The simplest and most
> intuitive way to propagate these events in QML is to have them be handled
> by
> the first item that asks to handle them, in stacking order. This does mean
> that they propagate individually, and simply grabbing the pressed event
> will
> no longer stop all mouse events. Hence the current issue.
>
> I think the MouseBlocker element is a good solution, because it's clearer
> than
> the empty MouseArea that we had before and just as easy to use.
>
> --
> Alan Alpert
> Senior Engineer
> Nokia, Qt Development Frameworks
> _______________________________________________
> Qt-qml mailing list
> Qt-qml at qt.nokia.com
> http://lists.qt.nokia.com/mailman/listinfo/qt-qml
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.qt.nokia.com/pipermail/qt-qml/attachments/20110610/b1e948e7/attachment.html