[Qt-qml] Mouse Event Filtering in QML 2

[Alan Alpert]

On Tue, 21 Jun 2011 02:50:45 ext Adriano Rezende wrote:
> 2011/6/14 Alan Alpert <alan.alpert at nokia.com<mailto:alan.alpert at nokia.com>>
> 
> On Tue, 14 Jun 2011 23:22:11 ext Adriano Rezende wrote:
> > Sorry, I pressed send by mistake :)
> > 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?
> 
> The flickable use case is not handled by the old approach neither by the
> new one (considering what you said). It's a use case where you just need
> to filter the press/move/release events from other items, stealing the
> event when a drag movement is recognized. Consider the current QML
> Flickable item with a button inside; the button shows a highlight on
> press, but as soon as the flickable recognizes a drag movement, it will
> steal the mouse event from the button, avoiding the release and the click
> events. Ex.:
> 
> Flickable {
>     width: 400
>     height: 400
>     contentHeight: 1000
> 
>     Rectangle {
>         width: 1000
>         height: 1000
>         color: mouseArea.pressed ? "red" : "blue"
> 
>         MouseArea {
>             id: mouseArea
>             anchors.fill: parent
>             onPressed: print("pressed")
>             onClicked: print("clicked") // avoided if dragging
>         }
>     }
> }
> 
> Simulating that behavior using a mouse filter would be like below:
> 
> MouseFilter {
>     width: 400
>     height: 400
> 
>     onPressed: print("press filtered")
>     onPositionChanged: // if dragging, steal mouse
> 
>     MouseArea {
>         z: -1
>         anchors.fill: parent
>         onPressed: print("pressed")
>         onClicked: print("clicked") // avoided if dragging
>     }
> }
> 
> I thought the new approach would behave like above, which is not the case.
> In the end a C++ extension is still needed to handle that, right?
> 

Yes. 

I believe that this use case is more touch-specific, and should be considered 
in the TouchArea research. That would be a better place to solve it.

-- 
Alan Alpert
Senior Engineer
Nokia, Qt Development Frameworks