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

List:       koffice-devel
Subject:    Re: Events, tools and pointer devices
From:       Thomas Zander <zander () kde ! org>
Date:       2006-10-13 14:51:39
Message-ID: 200610131651.40236.zander () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Friday 13 October 2006 15:08, Boudewijn Rempt wrote:
> On Friday 13 October 2006 13:04, Thomas Zander wrote:
> > This means that we should rewrite all canvasses to redirect to a proxy
> > class (toolmanager probably) which will change the current tool if needed
> > before passing the event on.
>
> Yes, indeed. If that proxy is going to KoToolManager, the canvas should
> know about the tool manager, right? Should we move KoToolManager to flake,
> or make flake depend on ui (and ui on flake...)

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.

> Okay, that's the way it's done in Krita too, basically. We've also got a
> bunch of subclasses of KisEvent -- KisMove, KisClickEvent,
> KisDoubleClickEvent that I not sure of whether they are necessary, handy or
> superfluous. 

I remember talking about this with you and asking you why they would be 
needed.
After some research we found out that having the different classes is a thinko 
and not needed at all.

Passing any event to the mouseMoveEvent() will state it is a move event. 
Creating a different class to pass to that method does not add any 
information we don't already have.
I would be very surprised if we need anything else but the KoPointerEvent. If 
you disagree, please tell me why you think so. :)

> The problem is that a single QMouseEvent does not indicate 
> whether it was a move, a click, a double click event. Two solutions: pass a
> KoDoubleClickEvent, or add extra handlers for click, doubleclick and
> mousemove.

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.

> > 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?

-- 
Thomas Zander

[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]