On Wednesday 28 March 2001 00:59, Rik Hemsley wrote:
> #if David Faure
> > Currently the filter mechanism is never applied automatically.
> > It's only used by kio_tar at the moment.
> > So if you associate a filter with audio/wav, it won't do anything
> > to normal konqueror usage - for the moment. We'll simply have
> > to take into account, when integrating filters into konqueror, the
> > fact that some filters should be automatically applied (gunzip/bunzip2)
> > and some not. Probably a flag in the filter desktop file would do ?
> 
> Yes, that would probably do it. I would have preferred to make
> KFilterBase more abstract and put stuff like compression logic
> into a derived class (e.g. KCodecFilter), but I don't know if
> radically altering that part of KIO's API is a good plan at
> this point in time.

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 ?

-- 
David FAURE, david@mandrakesoft.com, faure@kde.org
http://perso.mandrakesoft.com/~david/, http://www.konqueror.org/
KDE, Making The Future of Computing Available Today