Icon-mime type associations

[Thomas Leonard]

On Wed, Sep 15, 2004 at 06:48:09PM -0700, Ryan Gammon wrote:
> Hi all,
> 
> I'm a developer on the Helix Player for Linux, and the RealPlayer 10 for 
> Linux, which is based on the RealPlayer.
[...]
> One way to solve this would be to create the icon name programatically, 
> instead of pulling it from something like gnome-vfs.keys, so if 
> RealPlayer wanted to support a new .foo file format, we would add:
> 
> <mime-type type="audio/foo">
>    <glob pattern="*.foo" />
> </mime-type>
> 
> ... to our realplay.xml, and "know" that the name desktops will come up 
> with for this type will be mime-audio:foo.png.
> 
> The problem with this arises when more than one app wants to support 
> audio/foo. There's no guarantee that a desktop will provide a 
> mime-audio:foo.png, so 3rd party apps will in general want to provide 
> one. If two apps support audio/foo, we have a filename collision.

This does seem to be a problem. The ideal solution would be to install an
icon as hicolor/HelixPlayer/mime-audio:foo.png. This won't conflict with
anything. If several applications install foo icons, any one of them might
get used (which isn't too bad), but themes can still override them.

However, I don't see how the installer can easily get the new HelixPlayer
directory listed in hicolor's index.theme. Is there an accepted mechanism
for doing this?


-- 
Thomas Leonard			http://rox.sourceforge.net
tal00r at ecs.soton.ac.uk	tal197 at users.sourceforge.net
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1