[Qt-qml] Mouse Event Filtering in QML 2

[Alan Alpert]

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