> -----Original Message-----
> From: J-P Nurmi
> Sent: Sunday, 16 October 2016 4:06 PM
> To: Mitch Curtis <mitch.cur...@qt.io>; Qt Project <email@example.com>
> Subject: Re: Mouse event propagation in Qt Quick
> Hey Mitch,
> > - In example #2, why is Flickable happy to steal events that it doesn't do
> anything with? Shouldn't it see that it wasn't a "flick" and ignore the
> event, so
> that it goes to the next highest item in the stacking order (the mouse area)?
> An interactive Flickable always accepts mouse press events, because it needs
> to become the "mouse grabber item" ie. the item that receives the
> consequent mouse move events. This way Flickable can detect drags and
I was about to reply to myself after realising exactly this, hahaha. It would
be too late to propagate press events by the time it receives the final
> > - Why aren't the scroll bars blocked by the mouse area in example #3?
> The MouseArea is under the ScrollBar, because its parent is under the
> ScrollBar. The MouseArea is a child of Flickable::contentItem, whereas
> ScrollBars are children of the Flickable they are attached to. ScrollBar and
> Flickable::contentItem are siblings, ScrollBar being higher in the stacking
Ahhhh. That makes perfect sense, thanks!
> > - Why does example #3 work if I remove "preventStealing: true"?
> What do you mean? That's the exact use case "preventStealing" is meant for.
> :) When the MouseArea's preventStealing is true, Flickable honors it and
> won't be able to flick or drag since it's not allowed to steal events from the
> MouseArea. When preventStealing is false, Flickable's
> childMouseEventFilter() steals the press from the MouseArea when it
> detects a flick or drag.
Because of the other misunderstandings that I had, I thought that
preventStealing was the only thing allowing the MouseArea to get events, which
is why I thought it was strange that leaving it as false allowed the example to
continue working. :D
> J-P Nurmi
> Interest mailing list
Interest mailing list