[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 20:10:55
Message-ID: 200610132210.57525.boud () valdyas ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Friday 13 October 2006 21:38, Thomas Zander wrote:
> On Friday 13 October 2006 21:07, Boudewijn Rempt wrote:
> > I thought the idea was not just to determine whether we should change
> > tools, but to actually forward the events to the current tool.
>
> In the start of my email I used the word 'proxy' indeed. But later I
> stopped using that and corrected myself in stating we really only need one
> or two methods on the ToolManager.

Yes, I was wondering why you were misusing the word factory there... But 
really, I think life would be a lot easier if we would actually have a proxy. 
Look at your own KWord code below: those lines would need to be duplicated in 
all canvas implementations in KOffice. Better have it in one place in 
KOffice, so there can be no inconsistencies between applications. Especially 
the code that handles the tablet proximity events!

> So, the KoToolManager can just have the factory method for our event and
> keep on using the member of the canvas to actually forward the events to.
>
> Note we will not eliminate the usage of the m_tool member in Canvas even if
> we stop forwarding events directly from the canvas.

I was wondering about that -- what does the canvas actually use the tool for? 
Passing input events to the tool (which should include wheel and key events) 
and passing a QPainter to the tool during a paint event. That's all, right? 
There is actually no reason for the canvas to know about the current tool, or 
even the existence of KoTool if all those methods go through a proxy.

> I think you misunderstood. Nothing goes via the toolManager.

Well, you were a bit inconsistent, but I liked the idea of going through a 
proxy (and the toolmanager seems the right place for that) much more than the 
factory idea.

> > * 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.
>
> This doesn't make sense to me.
> the toolmanager sets the tool on the canvas. There is no way things can get
> out of sync.

Er... Experience learns that determining the current tool is everything but an 
atomic operation and that a mess will invariably result if there are two 
classes that keep the notion of "current tool" in their private variables.

> In short;
> KWCanvas::mouseMoveEvent(QMouseEvent *event) {
>   KoPointerEvent *pe = KoToolManager::instance()->create(event);
>   m_tool->mouseMoveEvent(pe);
>   delete pe;
> }
>
> KWCanvas::tabletEvent(QTabletEvent *event) {
>   KoPointerEvent *pe = KoToolManager::instance()->create(event);
>   switch(event->type()) {
>    case QEvent::TabletMove:
>      m_tool->mouseMoveEvent(pe); break;
>     case QEvent::TabletPress:
>        // foo bar
>     case QEvent::TabletRelease:
>     case QEvent::TabletEnterProximity:
>     case QEvent::TabletLeaveProximity:
>     default:
>   }
>   delete pe;
> }

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