Icon-mime type associations
rgammon at real.com
Tue Sep 21 00:48:23 EEST 2004
I thought I'd try to summarize here the discussion that's taken place so
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
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.
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.
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
I'm sure there're plenty of other options I've missed here -- feel free
to add to the list.
rgammon at real.com
Developer for Helix Player
More information about the xdg