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

List:       koffice-devel
Subject:    Re: Plans for the port of KPresenter to the new QRT stuff
From:       Werner Trobin <trobin () kde ! org>
Date:       2001-07-01 19:17:24
[Download RAW message or body]

David Faure wrote:
> 
> > Hmm, I think I'll start creating a base class
> > out of KWTextFrameSet (and KWTextFrameSetEdit), for sharing this with KPresenter.
> > It would be stupid to reimplement all this again, or duplicate it.
> 
> Ok, here's the plan, about how I suggest to do this:
> 
> - KoZoomHandler (kword's KWZoomHandler, untouched)
> - KoTextParag (everything except custom items and styles,
>  kword derives KWTextParag from it for those 2 things).
>  This means, kpresenter paragraphs will get linespacing, counters,
>  margins (the 5 of them, including first-line margin), borders and
>  tabulators (and all this with undo/redo and zoom support).
>  If we want, it can even get the "formatting characters" feature.
>  [I assume we don't want paragraph styles in kpresenter, correct?]

Hehe, I think we don't need that, no.

> - This includes sharing Counter and KoParagLayout (we may have to leave the
>  KWStyle *, and the page-breaking flags in it, unused in kpr, in order to share the same
>  undo/redo info structure & code. A bit dirty but I see no other simple way.
>  If we derive from those two, with a virtual method ("factory method") to build them,
>  then we can't have a non-pointer member var anymore. Doable, but I want
>  to make sure this is worth the change.)
>  Also, I guess loading and saving are going to remain different in
>  both apps (for compat) - or do we break kpr's format completely ?

If we can avoid it I'd say better not break KPresenter's format.

> - KoTextDocument (associates to zoomhandler, creates kotextparags,
>  kword derives KWTextDocument from it for association with frameset)
> - KoTextFormat: if we want StrikeOut support in kpresenter.
> (but this would also help using the same format class in KoTextObject)
> 
> and the big one: KoTextObject, most code coming from the current
> KWTextFrameSet (with associated KoTextObjectEdit for editing
> in a given view, code coming from KWTextFrameSetEdit).
> 
> KWTextFrameSet will have a KoTextObject member var (and will have
> to forward the calls to it), because it needs to still inherit
> KWFrameSet - and to add all the page-breaking stuff etc.
> 
> Maybe KoTextObject doesn't need the formatting-in-the-background stuff,
> kpr text object are usually quite small.
> 
> I suggest to put all those classes, together with the QRT classes,
> into a new koffice library called libkofficetext or something like that.

Yes, good idea.

> Oh, and if we make a KoViewMode from KWViewMode, it would help factorizing more
> code and having support for multiple viewmodes in kpr later.
> 
> Well, I have started splitting the basic classes (still in kword/ currently to avoid
> merging problems, but I'll create the kofficetext lib soon, moving that stuff into it),
> but I don't want to break KWord before 1.1, so touching kwtextframeset is for later.
> (the difference is that for that one it's not just about splitting, it needs to actually
> use a member textobject - unless someone has a better idea ;-)
> 
> Comments are more than welcome ;)

I think this is a great idea and I hope I can join hacking
pretty soon :)

Ciao,
Werner

-- 
Werner Trobin - trobin@kde.org
_______________________________________________
Koffice-devel mailing list
Koffice-devel@master.kde.org
http://master.kde.org/mailman/listinfo/koffice-devel

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