From kde-core-devel  Wed Mar 28 22:03:10 2001
From: Rik Hemsley <rik () kde ! org>
Date: Wed, 28 Mar 2001 22:03:10 +0000
To: kde-core-devel
Subject: Re: Part loading where mimetype won't work and KIO filters.
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=98582200005700

#if Alexander Neundorf

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

It certainly would, yes.

I was thinking that instead of this 'default' mechanism, we could simply
allow querying for a 'layer' that supports conversion from one mimetype
to another, so when a file with type 'text/x-man' (or whatever it's
called) is activated, konqy looks for the layer which gives the 'best'
rendering of the file. Say you have a layer that converts text/x-man to
text/plain and one from text-man to text/html, konqy would pick
text/html because it gives the most useful rendering.

We would also need a list of default priorities to let konqy make
the 'best' choice when possible.

This would be an extension to the filetype mechanism, which currently
allows setting priority order and specifying whether embedding is
desired.

Perhaps the RMB menu could have extra items, so that if you copy
a .wav file, you get 'Copy Here/Copy here as Vorbis/Copy here as
MP3/Move/Link' ?

Rik - just thinking aloud