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

List:       koffice-devel
Subject:    Re: RFD: loading/pasting/DnD in Flake?
From:       Thomas Zander <zander () kde ! org>
Date:       2006-09-13 8:17:17
Message-ID: 200609131017.17648.zander () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Tuesday 12 September 2006 20:52, Benjamin K. Stuhl wrote:
> On Sun, September 10, 2006 05:37, Thomas Zander wrote:
> > I just wanted to hear what the status is for this project? Are you
> > making progress? Want any feedback?
>
> Well, I've been somewhat preoccupied with the start of classes here,
> but I am still slowly trying to put together a nice design. I actually
> have a few points that could use some input from other people,
> especially Flake gurus:
>
>   1. document loading, especially styles: it seems to me that while a
> shape should know how to load its own content, it should _not_ be
> responsble for constructing an entire document. 
Agreed.

>      So, the question is: should there be something like a KoXXXLoader
> for every _file_ type XXX, where the Loaders would be in the library
> with their associated Shapes? 

We will support only one fileformat, the ODF one, which also is called the 
OASIS fileformat.  Just one format.
If you look at classes with OASIS in the name [1] you will find some hints 
that what you propose has actually already been coded :)



> (This would, incidentally, make 
> compatibility with the old XXX->KOffice filters easier, since the
> Text, Presentation, and Spreadsheet Shapes could each provide two
> loaders, one for KOffice legacy and one for OASIS...) 

No we should really keep legacy fileformats out of flake.
In KWord I have a KWDLoader which is the only class that knows about the 
old fileformat. It will construct the shapes and everything from outside 
and not use the loading mechanisms that you are designing.
Basically legacy formats should have zero effect on the design and 
implementation of the rest of the app.
We can't get away from a little work in the KoDocument inheriting class, 
but outside that I do believe we can make it work.

So loading / saving in flake will only have to support one fileformat. No 
more.

> OTOH, 
> paste/drop loading would still have to be delegated to the shape by
> the KoDropTool, since that has to be able to deal with the concept of
> an insertion point. (The shapes are, of course, free to delegate to
> an associated Loader if they so choose...)

Realisticly there are only a very limited amount of formats we will find 
on the clipboard. 80% of them are textbased and we should extend the 
KoTextTool to handle those instead of designing the framework to 
accommodate that.

So, the KoDropTool should allow sending different formats to the tool, but 
only in a very limited capacity. I surely want to avoid to 
have 'mimetypes' or other things to accommodate multiple-formats in the 
KoTool. Just in the KoTextTool.

>   2. Who owns text styles? It sort of looks like style loading should
> be associated with the KoStyleManager, but I'm not really clear on the
> design there... should there be a KoOasisTextStyle that handles loading
> and simply registers the styles with the KoStyleManager?

Style loading definitely is associated with KoStyleManager. It holds all 
user-created styles in the forms of KoCharacterStyle/KoParagraphStyle and 
KoListStyle.

In KWord I currently have the KoStyleManager to be a member of KWDocument. 
Which is a very logical place to put it as styles are shared by different 
texts.

I find your question a good one in that I have not thought long about it 
and I am leaning to placing the KoStyleManager instance in either each 
KoDocument inheriting class, or just plainly inside KoDocument.
Placing texts in, for example, Karbon or Krita then can reuse the style 
manager.
On the other hand I am not sure if we would need styles in those apps as 
the textShape works fine without and if this just makes things more 
complex. Memory consideration is not a big issue, an empty StyleManager 
doesn't take a lot.

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