Icon-mime type associations

[Allan Sandfeld Jensen]

On Thursday 16 September 2004 11:46, David Faure wrote:
> On Thursday 16 September 2004 09:50, Alexander Larsson wrote:
> > On Wed, 2004-09-15 at 18:48 -0700, Ryan Gammon wrote:
> > > Ideally, we'd like to see the icon lookup code:
> > > - look for an appropriate document icon in the current icon theme under
> > > a standardized name
> > > - if none is available, look to .desktop file for the default app for
> > > that mime type for a icon filename
> > > - search icon themes & hicolor as ususal
> > >
> > > One possible way to do this would be to add a line to the .desktop file
> > > like:
> > >
> > > MimeType=audio/x-pn-real-audio
> > > MimeIcon=realplay-audio-ra.png
> > >
> > > ... where the order of the mime types matches the order of the icons.
> > >
> > > Some logic would also have to be added to gnome-vfs and the kde
> > > equivalent to do a .desktop file lookup for mime type icon names.
> > >
> > > What do you folks think?
> >
> > But desktop files are per-app. Not per type. You will have several
> > desktop files supporting each mime type. Not to mention that this
> > requires all apps that show icons for files to read and parse all
> > desktop files, which is slow and uses lots of memory.
>
> Yeah. Didn't we decide on mimetype_name == icon_name, like Gnome currently
> does?

I think there was arguements for it but no final conclusion. Anyway I would 
like to object to the idea. The fall-back system for lacking icons is mostly 
useless, and only works for video and audio. The application-group of 
mimetypes is way too broad to make for a usefull fallback. It will make it 
unfeasable to make new icon-themes and makes it harder for applications to 
add new mimetypes to a system without breaking icon-themes. 

I would still advocate for a more detailed content based hierachy.  Besides 
being used for selecting icons, it could also be used in file-managers to 
list all wordprocessing files or executables, without tying the file-manager 
to a limited and quickly outdated list of predefined mimetypes.

To be a bit more specific. We currently have inheritence based on _format_, 
WAVE is also RIFF, Ogg/Vorbis is also generic Ogg, etc. 
I would like to have a parallel system based on _type_ (or usage). MSWORD-doc 
is also a type of wordprocessing-document, shellscripts is also a type of 
executables, Type1 is also a type of Font, etc.

With all this said if mimetype_name==icon_name is decided upon, it would mean 
that introducing the shared-mimetypes system to KDE, would be a even bigger 
step backwards feature- and usability-wise.

`Allan