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

List:       koffice-devel
Subject:    Plans for the port of KPresenter to the new QRT stuff
From:       David Faure <david () mandrakesoft ! com>
Date:       2001-07-01 17:43:17
[Download RAW message or body]

> 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?]
 
- 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 ?
- 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.
 
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 ;)

-- 
David FAURE, david@mandrakesoft.com, faure@kde.org
http://perso.mandrakesoft.com/~david/, http://www.konqueror.org/
KDE, Making The Future of Computing Available Today
_______________________________________________
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]