[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 22:22:11
Message-ID: 200901191722.11449.zander () kde ! org
[Download RAW message or body]

On Monday 19 January 2009 16:59:47 Cyrille Berger wrote:
> On Monday 19 January 2009, Thomas Zander wrote:
> > > > 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 ?
> >
> > (...)
>
> That doesn't really answer the question :) You just explain why you prefer
> not to use kword internal API, and not why or if that would prevents the
> filter chaining and use with koconverter like the last sentence of David
> let me believe it could be the case.

We may have a different usage of the technology; the fact is that if I want to 
convert from txt to rtf I need to find a set of filters that can do this.
I get a txt to kwd filter. Then a kwd to rtf filter. For example.

You never instantiate a KoDocument in that process.

To me its obvious that this implies the claim david made; tying a filter to 
having an KoDocument and the filter then reading or writing to the kword-
internal data structures means I can't use it in KoConverter. KoConverter 
doesn't use KoDocument.

I can imagine this is not explaining it to you; but I'm not sure how you think 
you can have a filter query the app-internal document when you never start the 
app.
Can you explain the process how you think this could work?

-- 
Thomas Zander from the sunny beach.
_______________________________________________
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]