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

List:       koffice-devel
Subject:    Re: File filters status...
From:       Pierre <pinaraf () pinaraf ! info>
Date:       2009-01-20 0:11:41
Message-ID: 200901200111.55676.pinaraf () pinaraf ! info
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Monday 19 January 2009 20:27:26 Thomas Zander wrote:
> 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.
I'm not sure it would be wise to just wait for our kwd saving format to come 
back and then rely on it for the filters.

We are now using OpenDocument natively, so it doesn't do as much sense as it 
did. Moreover, we may/will/did implement features that are present in 
OpenDocument and not in our old file formats. What do we do with these ? Make 
it impossible for the file filters to use them ? Modify our old file formats 
to handle these features ?

["signature.asc" (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]