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. That being said, it's only my 2 cents of bikeshedding. Cheers, greg On Fri, Jun 10, 2011 at 10:08 PM, Adriano Rezende < [email protected]> 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. > > 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 <[email protected]>wrote: > >> 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 >> > > > _______________________________________________ > Qt-qml mailing list > [email protected] > http://lists.qt.nokia.com/mailman/listinfo/qt-qml > > -- Gregory Schlomoff http://www.gregschlom.com
_______________________________________________ Qt-qml mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt-qml
