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

List:       koffice-devel
Subject:    Re: File filters status...
From:       David Faure <faure () kde ! org>
Date:       2009-01-20 13:24:50
Message-ID: 200901201424.51016.faure () kde ! org
[Download RAW message or body]

On Monday 19 January 2009, Cyrille Berger wrote:
> On Monday 19 January 2009, David Faure wrote:
> > Right now it may seem stupid, but if you look at it from a longer
> > perspective, relying on the internals of the applications means that any
> > refactoring breaks all filters. This has happened MANY times with the
> > kspread csv filter for instance.
> Except that sometime, the internals of an applications gives convenient way to 
> manipulate the XML/Data (I wouldn't want to build by hand, for each krita 
> filter, the layer stack ;) ). That said, libkoodf should give a good enough 
> high level API for manipulating an odf file and transforming to/from it.
> 
> > Also, converting from file to file allows automating the conversion using
> > koconverter, and allows chaining. Accessing application internals breaks
> > all that.
> how so ? if at the end the filter give something that can be saved ? (or 
> something that is saved), it should still work right ?

What if the _input_ of a filter is a file on disk? I think you're narrowing your
thinking to "saving from the app using in-memory structures".
But there are plenty of other cases, like
 - using all the koffice-1.x kwd-to-whatever (e.g. RTF) filters without rewriting \
                them to use libkotext stuff (QTextDocument) as input
 - my kpresenter-to-kword filter which, because it works with file input and file \
output, can be used BOTH  as "save as kword" in kpresenter and "open a kpresenter \
file" in kword. This wouldn't work if it relied on the kpresenter internals since \
                it's not running in the second use case.
 - more generally, in any filter chain, the filters other than the first one need a \
file, or at least XML  in memory (QDomDocument) as input.
 - same for koconverter, it needs a file as input, it doesn't dlopen the application \
to let it load the input file :)

All this being said, I totally agree that in some cases, for performance reasons
or for coding simplicity reasons, it's better or simpler to work with the application
data structures as input. Your example of krita layers complexity can indeed
be a strong enough reason to accept all the previously mentionned drawbacks
of not working with a xml as input. But for word processing I think working with
xml as input is the better solution, to benefit from filter chaining in particular.

-- 
David Faure, faure@kde.org, sponsored by Qt Software @ Nokia to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
_______________________________________________
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]