[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: Events, tools and pointer devices
From:       Boudewijn Rempt <boud () valdyas ! org>
Date:       2006-10-13 19:07:40
Message-ID: 200610132107.40933.boud () valdyas ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Friday 13 October 2006 16:51, Thomas Zander wrote:

> Using the KoToolManager from a class that inherits from the KoCanvasBase
> interface does not form a dependency in KoCanvasBase.
> Note that KoToolManager is a singleton and does not have to be seen in the
> API of the canvas at all.

That's true, of course. I still like to have some indication in KoCanvasBase 
that classes implementing that interface should route events through the 
toolmanager.

<...>

> Extra handlers?
> Take a look at KoTool. We already have all the methods we need.
> If KoTool::mousePressEvent() is called then we know what event will be
> passed.
>

But who calls KoTool::mousePressEvent? I would prefer it if all event routing 
to the tools went through the KoToolManager for the following reasons:

* consistency -- having the move events, but not the others go through 
KoToolManager is confusing.

* encapsulation -- if the toolmanager is the sole way to get the current tool 
to do something, we never have to worry about things getting out of sync, 
which would be possible if both the canvas implementation and the toolmanager 
have their own pointers to the current tool.

There was something else, but that has escaped my tired mind.

> > > Thinking about it a little longer, the proxy class I suggested above
> > > can be just one or two methods.
> > > So; what about
> > >   KoPointerEvent *KoToolManager::handle(QInputEvent *);
>
> ...
>
> > KoPointerEvent *KoToolManager::handleMouseMove(QMouseEvent *);
> > KoPointerEvent *KoToolManager::handleMouseClick(QMouseEvent *);
> > KoPointerEvent *KoToolManager::handleMouseDoubleClick(QMouseEvent *);
> > KoPointerEvent *KoToolManager::handle(QTabletEvent *);
> > KoPointerEvent *KoToolManager::handle(QKeyEvent *);
> > KoPointerEvent *KoToolManager::handle(QWheelEvent *);
>
> Right.
> I assumed that just having _any_ QMouseEvent or QTabletEvent would be
> enough. without any need for context (move/ double click etc). Or even a
> need for the keyEvents.
> Why do you think we need them? What logic will require that extra knowledge
> in determining if we should change tool?

I thought the idea was not just to determine whether we should change tools, 
but to actually forward the events to the current tool.

(Btw, Corel Painter and Photoshop play foul: they have one global tool, so I 
cannot even pan & paint with mouse and stylus. Feeble wannabees!)

-- 
Boudewijn Rempt 
http://www.valdyas.org/fading/index.cgi

[Attachment #5 (application/pgp-signature)]

_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel


[prev in list] [next in list] [prev in thread] [next in thread]