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

List:       kde-core-devel
Subject:    Re: Part loading where mimetype won't work and KIO filters.
From:       aleXXX <alexander.neundorf () rz ! tu-ilmenau ! de>
Date:       2001-03-28 15:42:03
[Download RAW message or body]

On Wednesday 28 March 2001 03:26, David Faure wrote:
>
> Oh I see what you mean. That was quite an oversight from me, making
> the KFilterBase API so tied with the compression stuff.
> But in fact, this is just playing on words. We can still put together a
> generic solution for KIO "filters", or any other name we can find so
> that it's not the same as what's already used by kfilterbase.
> Let's say I call this "layer", lacking any better name.
> We could make a base "layer" class, and
> associate layers to mimetypes, add some configuration for whether
> to use a given layer automatically or not, etc.
> The compression stuff (KFilterBase/KFilterDev) is only one case of
> layer - the one between compressed data and uncompressed data.
>
> In fact if you agree that QIODevice is a nice API for such things,
> then that's our base class. KIO could plug any QIODevice on top of
> data read from the network-transparency stuff (including kio_file),
> allowing any kind of conversion on top of that. That's why KFilterDev
> is a QIODevice too. Would the wav<->audio stuff fit in a QIODevice ?

We still are not able to view man/info pages directly (i.e by browsing file:/ 
and clicking on them). Would a conversion from man/info to html also fit into 
this layer scheme ? I.e. if I try to open a file with a special mimetype, 
would then the appropriate filter be invoked ?  (man page -> man2html -> 
khtml part)

Bye
Alex

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