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

List:       koffice
Subject:    Re: More thoughts about the filter architecture
From:       Werner Trobin <wtrobin () carinthia ! com>
Date:       2000-03-07 17:14:11
[Download RAW message or body]

David Faure wrote:
> 
> > > 2 - The filter doesn't need an XML file as an input, but can instead
> > > use KSpread's data structures directly (something like: the filter
> > > gets a pointer to the KSpreadTable to export).
> > > Pro: it can directly get hold of the values to export.
> >
> > If we decide to do this, it should work for importing, too!
> 
> Sure, I even thought that this was already what was planned for
> KIS's import filter, but it seems it's not yet decided.

Well... I suggested the passing-the-QDomDocument hack but Matthias
said that it won't help him writing *binary* data.

> > KoFilter:
> > We change the filter() method to:
> >
> > virtual const bool filter(const KURL &file, QList<QObject *> data,
> >                           const QCString &from, const QCString &to,
> >                           const QString &config=QString::null);
> >
> > return: success/no success
> > file: the URL of the file (IMHO this is better than a simple QString)
> > data: This is a list of pointers to classes which are derived from
> >       QObject. More on that later :)
> 
> Nitpicking: you mean QList<QObject>
> QList _is_ already a list of pointers, you don't want a list
> of pointers to pointers :-)

:)

> > This list of QObject-ptrs represents pointers to all data-objects (all
> > the objects containing data of the document) in the part. (for KSpread
> > this would be the document, the map, and the table - IIRC).
> I don't think KSpread even needs a list. The map contains tables,
> which contain the cells (and you don't need the document in the filter
> since everything is defined in the map - well, AFAIK).
> 
> I would have suggested a simple QObject *, but I guess you're right,
> better put a QList in the API for the cases where we might
> need more than one object (and to avoid having to create a
> container object with all the stuff we want to pass). We'll see.

I don't know the overhead of that list CTOR/DTOR and so on, but IMHO
we should make it flexible. If we can assure that we need KoDocument
only, we should pass KoDocument* :)

> > The filter gets pointers to all the objects it needs and can modify the
> > "document." (which is quite nasty, btw :)
> 
> Well, yes indeed, but the document is empty at that point
> (for an import filter) and should be read-only (const) for export filters.
> 
> Wouldn't that be a better solution (to prevent export filters
> from ruining your data) ? Passing a const KoDocument * to
> export filters, and a (non-const) KoDocument * to import filters ?

This is the moment when the interface class enters the scene. This
is a small class which accesses the private KoDocument data (friend)
and assures that everything remains Ok (reading & writing). Just
imagine us adding all kind of data access methods (setXYZ(), xyz(),...)
to the (crowded) KoDocument-derived class interface.

> Would require two methods, though, and would put the notion of
> import and export in that filter() call, don't know if
> that's a problem...

This is no problem. We simply have to adapt the KoFilter class
(e.g. add a second method and make both of them virtual (not pure
virtual as it is now). The default implementation would simply return
"false."
Each filter has to reimplement the appropriate method (e.g. import()
or export___no_builtin_names_please()), of course. (If it does not -
it won't be called :)

> > KoDocument:
> > There we have to add a virtual method. The default impl. simply
> > returns a QList<QObject *> containing a this-ptr. Each part which
> > reimplements the method has to return a list (QList<QObject *>)
> > of all the important objects (including the ptr to the KoDocument).
> Note that this goes away if you directly pass the object's document pointer.

Of course. But then we have to ensure that each filter only needs the
KoDocument data of its part. We could even go for a "mixed" solution
(partly direct acces (KoDocument) for critical stuff, partly XML
(all the rest))...

> > Then we should add a method which returns a Q(C)String containing
> > the XML file.
> The file _name_, right ? Seems strange to write to a buffer and then
> put it into a file (and I think KoStore doesn't support that).
> 
> > This one would be needed for all the "old-style"
> > filters (or for very simple filters which don't want to write the
> > data directly). The filter manager would call this method and
> > create a tmp-file containing the XML. The old filter method would
> > be called (of course with a string "pointing" to this file).
> 
> > Each part:
> > Has to reimplement the list-method. Maybe it would be better to
> > create some data-interface-classes to handle all the data accesses
> > of our filters. (I don't feel like declaring a filter my friend :)
> > This kind of proxy class could also be used to check the input...
> This is the 'security' problem again, right ?
> I think it goes away with the fact that the document
> is const (export) or empty (import).

See above.

> > The parts also have to initialize an empty document before calling
> > the filter!
> Right.

There is this initDoc() method, IIRC.

> > Misc. Thoughts:
> > - Do we want to use QObject&moc or do we use RTTI? If we decide
> >   to use the Qt-way each data-class has to inherit QObject.
> Definitely QObject, I'd say - and documents are QObjects ;-)

It seems that we can use QObject* instead of QList<QObject>. Or
we use KoDocument* directly :)

> > - We have to change the compilation order and link the parts to
> >   the filters. Do we really want that?
> Had the same worry. It's a change, but I don't see a problem there.
> Build the apps first, then build the filter for the apps
> using some of the apps' code. Makes sense.

Does this bloat the filter libs? I'm no linker freak, but I think
this shouldn't be a huge problem.

> > - All this feels a little bit strange. Do we want to let the filter
> >   change the data of the part directly? Ok - it's fast, for sure,
> >   but this is also dangerous! Just imagine a crashing filter. It
> >   would crash the part, too. The filter might also invalidate the
> >   part's data and so on. I have to admit that I'm not very happy
> >   with this new stuff. Maybe I can come up with a better design.
> See above.

I'm looking for something totally different :))) Just kidding.

> > - Another solution for the KSpread problem: Use XML :)
> >   IMHO the formula AND the current value should be stored...
> Yeah, I thought about this. But I don't know KSpread enough
> to that (yet) :)
> It would probably save time when opening an existing document, too.
> Laurent ?
> 
> > - Another solution for the KImageShop problem: Let KIS open the
> >   image files directly (without filters, directly in the part).
> The monolithic way ? ;-)

There is no big difference to our "new" solution anymore. It's
quite "monolithic," too. I know that it's not exactly the same,
but there are some similar effects (e.g. it has to know a lot
of implementation details,...).

> Hmm, sure, that could be the reasoning here:
> * filters are external because all they need is the XML file,
> as an input (export) or as the output (import)

This is what I thought, too. But I totally forgot that it's in
the same process since we use kparts. Therefore this argument is
void from the "let's crash the part" point of view :)
Sure it's easier for the filter programmer to handle two files
instead of data structures (monolithic way) in a huge program
she/he didn't write. This abstraction is quite "expensive" in
terms of speed and direct accessability, of course...

> * for advanced stuff (KIS import/export, as well as
> loading images in all KOffice apps, in fact), do it in the app itself.
> 
> Filters were external processes at some point, and we're trying
> to take advantage of the fact that they're in-process to pass
> some pointers around ... not very clean indeed ;-)

It's a nasty hack, but since it's no separate process we should
try to use the new possibilities.

> Hmmm... Don't know what to decide, I guess it will take a few
> more e-mail rounds :)

Pheew... this one's quite long. What about a 
<normally I don't like it>IRC session</normally I don't like it>???

I simply assume that you read this mail soon and suggest meeting
at 20:00 CET (should be 19:00 GMT???) on #kde. If you miss this
"deadline" I'll be on #kde every hour till we meet or I fall
asleep :)))

If there is anyone else who wants to discuss this topic - you know
where to find us.

Werner, doesn't like IRC, but well...

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