Icon-mime type associations

[Thomas Leonard]

On Mon, Sep 20, 2004 at 02:48:23PM -0700, Ryan Gammon wrote:
> 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.
[...]
> 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:

[ option 1 -- no icon -- doesn't sound useful ]

> 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 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.

This is the key decision to make. (2) is simpler for packaging, since each
app just drops its icon in a unique folder, although we'd have to have so
rules so that looking up the icon always got the same icon for any
particular set up (eg, sort the hicolor/* directories alphabetically).

I think icons shouldn't be program-specific, except for native formats.
Eg, image/png shouldn't have a gimp logo on it just because gimp provided
the icon, while image/x-xcf (Gimp's native format) should have a gimp logo
on it, even if eog provides it.

With (3), the icon will change when the user changes the default app. If
icons aren't app-specific, this means that the users see different icons
for their files, even though the files haven't changed. I think this is
confusing.

This is the opposite of your conclusion, so I guess it depends on what we
expect the user's model to be. Do users expect the icon to indicate the
program that will be used to open it, or does the icon just represent the
data type itself?

Until that's decided, we can't choose between the methods...


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