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

List:       koffice
Subject:    Koffice Filter API - update
From:       Werner Trobin <wtrobin () carinthia ! com>
Date:       2000-03-16 21:18:20
[Download RAW message or body]

Hi!

In the last days I spent some time implementing the new
filter API. Just to give you some basic info before I
write some "real" documentation I'll give you a brief
introduction:

The new API provides three kinds of import and two kinds 
of export filters:

Import: (i.e. convert a txt file to a kwd (KWord) file)

1) File -> File: You get a filename, open the file, read
   the contents, convert it, and write it back to a file
   (you get this filename, too). As you only have to
   write a file you can do whatever you want to - you
   just have to write a correct file :)
   There are two possibilities I recommend:
       - Use a QDomDocument and convert it to a QString
         when writing to the file.
       - Use a Ko(Tar)Store (file). This can be used to
         create "combined" documents (XML and binary data).
         Hint for debugging: It's a plain tar.gz file :)

2) File -> QDomDocument*: As you can see, you get a file
   (better: a filename) and you have to return a pointer
   to a QDomDocument (David: What to do about this 
   potential mem-leak?). This should be used for filters
   which won't have to write binary data, but only XML.

3) File -> KoDocument*: You open/read a file and get direct(!)
   access to the document of the part. This is not very save,
   but as we use an empty document it should be ok. This is
   the fastest possibility available, but you have to know
   the internals of the part and you have to link it to the
   filter. For small toy filters this might be overkill, but
   think of an import filter for KIS which transfer enormous
   amounts of data.


Export:

1) File -> File: see above
2) KoDocument* -> File: It's just the other way round, but
   here we use a "const KoDocument * const"...

Note: There is no possibility for QDomDocument* -> File export,
because this would have to be implemented in every part and it's
not worth the trouble, IMHO. If you volunteer to implement it in
every part, I'll add it :)))


About the OLEFilters:
I'll change the OLEFilter class to handle all the API stuff so
that the subfilter won't have to be changed dramatically.

I hope this was at least a little bit interesting,
Werner

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