[Qt-interest] FW: QgraphicsScene: best way to manage events

[Oliver.Knoll at comit.ch]

Accidentally was sent to me in private I guess ;)

Cheers, Oliver

-----Original Message-----
From: Ross Bencina [mailto:rossb-lists at audiomulch.com] 
Sent: Friday, November 26, 2010 3:31 PM
To: Knoll Oliver, ITS-CMT-SUI-SL-SFR-FIN-DEV
Subject: Re: [Qt-interest] QgraphicsScene: best way to manage events

>> Oliver Knoll wrote:
> On 2010-11-26 Ross Ross Bencina wrote:
>
>> Oliver Knoll wrote:
>>
>>> I don't think QGraphicsView/Scene "eats" such events before they
>>> deliver it to your method. ...
>> One reason I have not used event filtering is that QGraphicsScene doesn't
>> (didn't?) provide a mechanism to intercept all QGraphicsSceneHoverEvents 
>> for the
>> whole scene -- so I have a convoluted mechanism where the GraphicsItems 
>> notify
>> my scene subclass of these events,
>
> I am just doing my first steps with QGraphicsScene myself, but from what 
> you write I understand the problem was that you did not get /all/ events 
> on a "global QGraphicsScene" level, but instead the events were consumed 
> by the individual QGraphicsItems?

Correct.

>But isn't that the desired behaviour, analog to how events are handled in 
>QWidget hierarchies?

Sure.

> The "most specific" widget/item gets the mouse event first (especially 
> when talking about "mouse hover/move only" events), and only if that 
> widget/item is *not* interested in that event it gets dispatched up the 
> hierarchy, until the root element (the QGraphicsScene for example).

But those particular events don't bubble all the way up since they're 
synthesized by QGraphicsScene, so its not possible to intercept them at the 
"global QGraphicsScene" level, or as a result, with an event filter on 
QGraphicsScene. (perhaps they do now, this was a few years ago when I wrote 
this code).


> So that would be the use case then to install an "event filter", in order 
> to prevent the "most specific" widget/item from receiving the event.

You're right, but I looked at the QGraphicsScene source code and at the time 
there was no way to get access to those events in one filter for the whole 
scene.

> Or maybe your concrete use case was more complex or I don't understand the 
> core problem you had ;)

The way I my code works I avoid putting most mouse/interaction behavior in 
the GraphicsItems and instead put them in my Interactor classes. This is 
similar to Tools but more flexible (for example it allows a separate 
Interactor for each graphics item, whereas a Tool would have to be global 
accross the whole scene -- I have scene-global Interactors too).

So my Interactors need access to all events that QGraphicsItem's have access 
to because they really replace event handling in graphics items with event 
handling in Interactors. This is kind-of a form of the State design pattern 
for handling mouse events. You can use the same pattern for multi-touch too 
(separate Interactors for each finger for example) -- I havn't done that 
with Qt but did it with TUIO and a Python graphics library a few years ago.

Of course a choice of pattern is dependent on lots of factors -- I wouldn't 
argue Interactor is good for everything -- it is very flexible though.


>> That said, I probably wouldn't have used the event filter mechanism 
>> anyway.
>> I'm not a big fan of subclassing QObject for lightweight classes like 
>> Interactors
>
> I agree that if there is no real need to subclass from QObject, well, then 
> don't: in this case it is easier to expose the mouseMoveEvent() etc. 
> methods and call them directly (also a bit more performant than re-sending 
> events ;) But most often you need to subclass from QObject anyway, in 
> order to have signal/slots working, and this is very likely the case for 
> "tools" anyway (a paint tool might want to get informed whenever the 
> "colour picker tool" has chosen another colour, as to bring up some 
> artificial example), and "tools" usually remain in memory for the lifespan 
> of the application, or at least for the lifespan of the "document" they 
> are operating upon.

Agreed, although I never found a use for this kind of Tool pattern in my 
project. My interaction is all modeless -- with different behavior coming 
from clicking and manipulating different parts of the scene (which spawns 
different Interactors as necessary).

Ross.