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

List:       koffice-devel
Subject:    Flake [KoDef/commands/threadweaver]
From:       Thomas Zander <zander () kde ! org>
Date:       2006-04-27 5:57:26
Message-ID: 200604270757.30994.zander () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


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

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.

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.


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