Icon-mime type associations

[Ryan Gammon]

Hi all,

I thought I'd try to summarize here the discussion that's taken place so 
far:

The problem:
RealPlayer wants to install fallback icons for datatypes that the 
desktop may not have covered in its icon theme. The specs roughly say 
that these icons should go in /usr/share/icons/hicolor/48x48/mimetypes.

The specs also (roughly) fixes the name of the icon for the new 
datatype. audio/foo -> mime-audio:foo.png for example.

If two apps want to install a fallback icon for a given mime type, they 
will conflict.

There's some debate as to whether or not this is a problem.

I feel the desktop icon theme should get first crack at the document 
icons -- what we're talking about here are the hicolor fallback icons only.

The solutions:
1. Apps don't install icons for new mime types. If a user goes to 
Nautilus, they'll see their .foo files with a generic icon. In the case 
of audio/* and video/*, one could create a fallback type of 
mime-audio.png, but this doesn't solve the general problem -- 
application/smil for an example that's relevant to us.

2. Apps fight for the hicolor icon. Whoever gets to the /usr/share/icons 
hicolor directory first/last gets the icon.

3. mime type fallback icons are per-app. The default app for a datatype 
gets to define the fallback icon.

I think (3) is best for the user. The app supporting the datatype has 
the best chance of being able to display something meaningful to the 
user about what that document type is. With (1), we'd display either 
nothing, or something very generic. With 2, behavior would be random. 
There's potential for an app to be default for the type, but for the 
icon to come from a different app. This is confusing. The potential 
conflicts here also complicates packaging.

The implementations:

There are a couple of ways 3 could be implemented. I've listed a few here:

A. Apps install their document icons to 
/usr/share/icons/hicolor/48x48/mimetypes/<app name>, where app name is 
something like hxplay. Alternatively, apps prefix their icons in 
/usr/share/icons/hicolor/48x48/mimetypes with hxplay, so the hxplay 
fallback icon would be hxplay-mime-audio:foo.png

Either apps like nautilus can look for these alternative fallback icons 
when trying to associate an icon with a datatype, or another app can 
update mime-audio:foo.png to point to hxplay-mime-audio:foo.png when 
hxplay is the default app for a given datatype.

This is based on a suggestion from Thomas Leonard.

B. Icon/app associations can be declared in the .desktop file, where the 
mime types supported by the app are declared ... my original suggestion.

C. Add support to the .xml files in /usr/share/mime/packages for setting 
the "fallback" icon name, similar to the way .keys files worked.

One of the criticisms of per-app document icons is that it would consume 
excessive memory and cpu time.

With (A), we are either
i. introducing a fixed overhead of setting symlinks in mimetypes 
whenever the default app for a datatype changes or
ii. introducing the overhead of an icon lookup when a datatype is 
unknown. If nautilus needs an icon for audio/foo, it has to do a default 
app lookup for audio/foo, and then an icon lookup based on that app 
name. This is an additional default app name lookup. I believe this 
information comes from a hash table lookup in gnome-vfs.

With (B), we're in a similar situation as (A) -- an extra lookup of the 
default app & .desktop info for audio/foo, from which we could extract 
an icon name.

With (C), it's unclear how the app-specified icon would get 
propagated... maybe this would be a update-mime-database, which would 
mean that update-mime-database would get run everytime a default app 
changes. Awkward.

I'm sure there're plenty of other options I've missed here -- feel free 
to add to the list.

-- 
Ryan Gammon
rgammon at real.com
Developer for Helix Player
https://player.helixcommunity.org