[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 20:58:08
Message-ID: 200610132258.08565.zander () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Friday 13 October 2006 22:10, Boudewijn Rempt wrote:
> 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!

The code I pasted didn't handle the tablet proximity events. That would be 
handled by the tooManager already.
The pasted code does nothing but forward to the current tool. With a switch 
for the tablet version since there Qt doesn't split the different move/etc 
events.

Really I don't see the problems you think there are. Its just simple wrapper 
code. Adding a layer of abstraction (the proxy) makes things slower by adding 
several items to the call stack. And since you were earlier worried about 
doing a dynamic_cast I'd guess this is equally important.

> > 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?
If you read the KWCanvas you'd see at least a paint on the m_tool.

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

If pressed, I'll have no objections to a proxy. I just feel its adding API 
thats confusing for only gaining at max a dozen lines of code each canvas.
But you do this coding, so fee free to ignore this point :)

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

Well, we both have >20 years of programming experience. Chances are we both 
have very good reasons and are both equally right in most cases.
So, lets make sure we respect each others design and follow its lead when 
building on top of, or extending the others code.

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