[Qt-qml] Mouse Event Filtering in QML 2

[Gregory Schlomoff]

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 <
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.
>
> 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 <alan.alpert at nokia.com>wrote:
>
>> On Fri, 10 Jun 2011 10:28:03 ext aaron.kennedy at nokia.com wrote:
>> > Hi,
>> >
>> > On 10/06/2011, at 10:02 AM, ext michael.brasser at nokia.com 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
>> Qt-qml at qt.nokia.com
>> http://lists.qt.nokia.com/mailman/listinfo/qt-qml
>>
>
>
> _______________________________________________
> Qt-qml mailing list
> Qt-qml at qt.nokia.com
> http://lists.qt.nokia.com/mailman/listinfo/qt-qml
>
>


-- 
Gregory Schlomoff
http://www.gregschlom.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.qt.nokia.com/pipermail/qt-qml/attachments/20110611/15fafb31/attachment-0001.html