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

[Christian Gagneraud]

On 11/25/2010 08:40 AM, Oliver.Knoll at comit.ch wrote:
> On 2010-11-25 Christian Christian Gagneraud wrote:
>
>> ...
>> Should I let the tools register/unregister themselves as event filters
>> to the scene, or should I forward the events to the current tool in
>> the scene's event handler using postEvent()? Or are there any other solutions for this typical use-case?
>
> I did something similar a few years ago which comes pretty close of what you want to do (tools are available as plugins):
>
>    http://www.pointshop3d.com

Hi Oliver,

Thank you very much for sharing your experience.
So you choose to forward the event by calling directly event handlers.
I thought about this one, but it didn't looks like to me to be in the 
"QT spirit" hence my post here (I'm still a beginner with QT and user 
interface).
Anyway, this solution seems to work well and is simple, I think I'll 
stick to that one.
I saw some posts in the archives about using event filters, but it 
looks a bit tricky to me.

Thanks,
Chris

>
> It was QWidget based though (the 3D point s/w renderer - we also had a OpenGL point renderer/QGLWidget, also pluggable), not graphicsscene based. IIRC I had a "ToolManager" which exposed the "current tool" to the graphics widget:
>
>    http://graphics.ethz.ch/pointshop3d/sourcedoc/html/classToolManager.html
>
> The ToolInterface itself then exposed the various mouse event handlers:
>
>    http://graphics.ethz.ch/pointshop3d/sourcedoc/html/classToolInterface.html
>
> so I guess the renderer widget checked whether there was a "current tool" and simply "forwarded" the QMouseEvents to those handlers (by simply calling them). When the tool would accept that event it would simply "accept()" this event - as with normal Qt mouse/keyboard event handling and the render widget would not deal with the event itself. If the tool did not care about that event however the renderer widget would deal with it itself, if necessary (e.g. rotation, translation, ...).
>
>
> If you don't want to have a singleton "Tool Manager" you could certainly also use postEvent and forward the mouse event to the well-known "destination" (i.e. the "active" tool).
>
>
> As a sidenote: in my case the "Tool Manager" also cared about the "tools plugin" directory and loading the plugins. 3 tools were "hardcoded" (always available): ColorPickerTool, NavigationTool, SelectionTool. Those are the ones you see in the class diagram in the link above ;) Oh and yes, that's totally Qt 2.x ;) (someone ported it to Qt 3 later on).
>
> Hope that gives you some inspiration :)
>
>
> Cheers, Oliver
> --
> Oliver Knoll
> Dipl. Informatik-Ing. ETH
> COMIT AG - ++41 79 520 95 22
>
>
> _______________________________________________
> Qt-interest mailing list
> Qt-interest at trolltech.com
> http://lists.trolltech.com/mailman/listinfo/qt-interest


-- 
Christian Gagneraud,
Electronics and software engineer

TechWorks Marine Ltd
4a, Park Lane
Dun Laoghaire, Co Dublin
Ireland

Tel: + 353 1 2365990
Fax: + 353 1 2365992
Web: www.techworks.ie