On Fri, 10 Jun 2011 10:28:03 ext [email protected] wrote: > Hi, > > On 10/06/2011, at 10:02 AM, ext [email protected] 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 [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt-qml
