[Qt-qml] Mouse Event Filtering in QML 2

[Adriano Rezende]

Sorry, I pressed send by mistake :)

On Tue, Jun 14, 2011 at 10:06 AM, Adriano Rezende <
adriano.rezende at openbossa.org> wrote:

> 2011/6/13 Alan Alpert <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.

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


>
>> >> 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).
>>
>
That's nice! I thought it would be in the final API.


Br,
Adriano
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.qt.nokia.com/pipermail/qt-qml/attachments/20110614/0e5997e2/attachment.html