[Qt-qml] Mouse Event Filtering in QML 2

[Alan Alpert]

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.

>> 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