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

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

[Attachment #2 (multipart/signed)]


On Thursday 27 April 2006 10:28, Boudewijn Rempt wrote:
> 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.

Ah, didn't know that. Sounds good.

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

Oops; thanks for the heads up.
I don't mean any disrespect, lots of stuff gets designed where later on 
the design patterns emerge (I actually think thats the norm). I assumed 
thats what happened here due to some differences between the design 
pattern and the implementation.

> 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

Ok. Sounds good.
I put the stuff in KoDefaultTool; I think the renaming can wait a little; 
but I'll propose a set of renames later.

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

At what level do they live?  I mean, are they under the KoTool or are they 
always interactionPolicies.  Which is the same as asking; are the 
differences limited to the move/rotate/select actions or are there 
differences for all types of tools.

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

I'll answer briefly as I have been preparing a patch to explain this 
better. Zagge asked me this morning as well and the short short story is;
press -> createCommand(), release -> finishInteraction()

> Oh, and KoDef makes it 
> possible to draw temporary things -- that seems essential to me. 

Yes, i kept that possibility; looks like a nice addition that KWord does 
not really have.

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

Ok, you got me there; you are right :)

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