[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:       Rik Hemsley <rik () kde ! org>
Date:       2001-03-28 22:03:10
[Download RAW message or body]

#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

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