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

List:       koffice-devel
Subject:    Re: File filters status...
From:       Thomas Zander <zander () kde ! org>
Date:       2009-01-19 19:27:26
Message-ID: 200901191427.26593.zander () kde ! org
[Download RAW message or body]

On Monday 19 January 2009 11:14:29 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.

Convenient, sure.
And in the case of krita you can actually do this due to krita having 2 
libraries that don't change all that often.
For all other apps its not worth the convenience.  I never touched the rtf 
filter and I certainly appreciate that any changes in KWord never affect the 
filter because I don't use anything from KWord.

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

If in KSpread I change the way the data is stored (which has happened various 
times) then the filter will stop compiling. This has happened in Krita various 
times too; filters that depend on Krita API naturally need to follow any 
changes in internal krita datastructures.

In the KWord or KPresenter case we would have to rewrite everything since the 
API for the text we store is totaly changed.  So a strategy of not using 
anything from the app (just kofficelibs) makes things more stable and easier to 
maintain.

If the krita guys think they gain much more by using the krita datastructures 
instead of just the things like pigment and libpng, then sure, than this stuff 
doesn't directly apply to you. (and I agree with boud that such filters should 
actually be moved under the app dir)

For KWord the question of relying on the kwd file-format saved rewrites many 
times already. Just this one time things actually do break because of me never 
having re-implemented the kwd saving.

If someone knows how to  register that kword is no longer capable of *writing* 
the old fileformat then please tell me.  The effect I'm after is that the filters 
that require a kwd fileformat are no longer shown in the saving dialog.

-- 
Thomas Zander

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