Icon-mime type associations

[Ryan Gammon]

Frans Englich wrote:

>On Thursday 16 September 2004 01:48, Ryan Gammon wrote:
>
>A common use of mimetype icons is to follow up the document/context centric 
>model; an icon tries to resemble what it represents as close as possible in 
>order to make the user's association steps as short as possible. Functional 
>names is another example. If cases like this(3rd party branding, I guess) is 
>the major reason for the usage of such an mechanism, it would be a step 
>backwards in terms of usability, AFAICT.
>  
>

I think it's a step forwards.

Let's say the desktop alone controls document icons. I'd argue that 
there's no way the desktop can both know about all media types, and have 
icons representing all of them. New types get introduced all the time, 
not all icon theme maintainers have the time to write icons for all 
document types, etc.

If the icon theme does not have a suitable icon, there are two things 
the desktop could do:
- Show a generic file icon
- Let the app provide an icon

If we show the user a generic icon, it provides no information to the user.

If we show a vendor-provided document, that at least tells the user 
"this is content I can play with the Helix Player." They can recognise 
that this file is a media file, and that it will open in Helix Player. I 
think this is a step forward.

Now, the vendor icon is a neutral hicolor icon, so it might not match 
the surrounding icons, but that's more of a "should hicolor exist" kind 
of argument. It seems to have been decided that hicolor is a good idea, 
much to our satisfaction, or we'd be stuck trying to provide individual 
icons for every icon theme -- not practical.

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