[Qt-qml] Mouse Event Filtering in QML 2

[Alan Alpert]

On Tue, 14 Jun 2011 23:22:11 ext Adriano Rezende wrote:
> Sorry, I pressed send by mistake :)
> 
> On Tue, Jun 14, 2011 at 10:06 AM, Adriano Rezende
> <adriano.rezende at openbossa.org<mailto:adriano.rezende at openbossa.org>>
> wrote: 2011/6/13 Alan Alpert
> <alan.alpert at nokia.com<mailto:alan.alpert at nokia.com>>
> 
> 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.
> 
> In the flickable use case, it's the only way I can see to handle the mouse
> steal. It could be declarative of course, but in that case it would be
> very specific to a flickable behavior.
> 

What is this 'flickable' use case specifically, and how is it not handled by 
the new approach?

> In the end, the JS logic would be needed just for the 'flickable' mouse
> area. The other mouse areas would behave the same. They should just handle
> the cancel signal, which is already needed in case a Flickable or a
> ListView steal the mouse event.
> 
> >> On Fri, Jun 10, 2011 at 10:08 PM, Adriano Rezende
> >> <adriano.rezende at openbossa.org<mailto:adriano.rezende at openbossa.org><mai
> >> lto: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.
> 
> Sorry then, I think I misunderstood. I thought the new implementation would
> behave like a MouseFilter element due the bug reference QTBUG-13007. Is
> that the case?
> 
> The QtQuick 2.0 mouse event arch will behave the same as the QGV mouse
> event?
> 

The 'basic' mouse events (pressed, released, positionChanged) will behave the 
same as before. It is only the composite events (clicked, doubleClicked, 
onPressAndHold) which have changed, because the QGV approach did not allow 
effective forwarding of these events. So only these events propagate 
differently.

-- 
Alan Alpert
Senior Engineer
Nokia, Qt Development Frameworks