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

List:       koffice-devel
Subject:    Re: Flake [KoDef/commands/threadweaver]
From:       Boudewijn Rempt <boud () valdyas ! org>
Date:       2006-04-27 8:28:32
Message-ID: Pine.LNX.4.63.0604270936590.16935 () calcifer ! valdyas ! org
[Download RAW message or body]

On Thu, 27 Apr 2006, Thomas Zander wrote:

> On Wednesday 26 April 2006 21:33, Boudewijn Rempt wrote:
> > > I added kcommand as a stripped version of the KDELibs one to avoid
> > > depending on that for now.
> >
> > Is this the place to start thinking about the integration of commands,
> > undo/redo and threadweaver?
> 
> Almost (doesn't threadweaver give me a dependency on kdelibs?)

I don't think so, actually, but I should check. Note that it's still 
in kdenonbeta, and Mirko advised me to temporarily copy it into our own 
tree.

> First;
> I've been reading through the KoTool and KoDef, and related classes and I 
> recognize the design. Probably without knowing it you guys implemented 
> (somewhat) the Strategy (aka policy) design pattern in using KoDef as an 
> interface-like class.

(You know... Expressions like "probably without knowing it" aren't really giving
the impression that you're taking people seriously. That's bound to create
resistance.)

Note that KoDef (or KoToolInteractionPolicy if you think this class is going to
be useful outside the default tool) is not linked directly with the KoTool
interface since there will be tools, like the painting tools in Krita that
don't have much use for interaction policies. So, while "KoDef" is likely not
a good name, we need something to express a hierarchy like:

KoTool
	KoTool that uses KoInteractionPolicy
	KoOtherTool that doesn't use it

(As an side note for future reference, we should have a stack of current tools 
_per_ input device.) 


> I'd like to change the interface of KoDef to that of the KWords 
> equivalent; the InteractionPolicy[1]
> Its a bit more mature and moves more logic to the policies than the 
> current KoDefaultTool implementation does.

One question: why only mousemove, and not press and release in your interface?
Wouldn't they be useful, too? Oh, and KoDef makes it possible to draw temporary
things -- that seems essential to me. Does KWord do that through the pointer
to KWCanvas? This may be the place where the tentative canvas interface I added
to svn a while ago comes in.

> 
> 1) 
> http://www.englishbreakfastnetwork.org/apidocs/apidox-koffice/kword-apidocs/classInteractionPolicy.html
> 
> ps. Now I've seen the default format of doxygen created in the flake 
> project I have to say that the format KDE chose for its api-docs is the 
> worst and most annoying format to use as a resource I have ever seen...
> Sorry for linking to the ebn and not koffice.org, for some reason 
> koffice.org does list this class.

As far as I'm concerned, the Qt4 documentation layout tops everything in
terms of horribleness...
_______________________________________________
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]