mime-type icons, a proposal

[Ryan Gammon]

Alexander Larsson wrote:

>I'm hoping we can do it the way Mac does it. Not by making it impossible
>for apps to do branding, but by creating a community of developers/users
>where an app that over-branded the desktop would look alien and ugly, so
>that people would not use it. 
>  
>

A couple of links of interest:
http://developer.apple.com/documentation/Carbon/Conceptual/LaunchServicesConcepts/LSCConcepts/chapter_2_section_8.html
http://developer.apple.com/documentation/MacOSX/Conceptual/SystemOverview/Finder/chapter_9_section_5.html

The mac has quite a sophisticated algorithm for resolving app conflicts, 
taking into account:
- explicitly specified user preference
- 4cc code of media files
- native osx vs classic
- app on boot volume
- app on local volume
- later version number

If two or more candidate applications remain after all of the foregoing 
criteria have been applied, Launch Services chooses one of the remaining 
applications in an unspecified manner.

It looks to me like the mac actually will change document icons based on 
the explicitly specified user preference, and even goes beyond this.

The windows way:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnw2ksrv/html/w2kserve_chapter1.asp
... basically 1 icon per extension specified in the registry, and apps 
fight for it.

>>>When update-mime-database is run after the installation of this file
>>>it generates the new magic file, the extensions file, and a new file
>>>that maps mimetypes to app-specific mimetype icons. If a mimetype is
>>>listed in several files the conflicts is handled in some way
>>>(implementation defined). 
>>>      
>>>
>>We could even potentially define this at a spec level: The current
>>default app gets first crack at the icon at the time update-mime-database is run.
>>    
>>
>
>No, that doesn't work. Default app is per-user, not global, and the mime
>database is global. 
>  
>

True.

I'd like to see the spec be to have the ability to support a osx-like 
conflict resolution system.

I'm actually starting to think that the mime spec may be ok as is, and 
that it might be the icon-theme-spec and .desktop file spec that could 
be changed to accomodate this.

Here's what I'm thinking:
- the app detects the mime type of the file, usually from extension
- looks for mime-audio:x-pn-realaudio.png in the current theme

At this point, there's a "enable fallback icons" option the user can 
select. If the option is unchecked, processing can stop here and a 
generic theme-integrated icon can be used.

If the user/distribution has enabled this option, the app:
- looks up the current app for the mime type (.desktop file info)
- pulls a "icon-prefix" key from the .desktop file
- tries to load realplay-mime-audio:x-pn-realaudio.png from hicolor

So we'd have this sort of thing going on:
1. (MUST) /usr/share/icons/GnomeCrystal/48x48/mimetypes/mime-audio:x-pn-realaudio.png
2. (MAY)  /usr/share/icons/hicolor/48x48/mimetypes/realplay-mime-audio:x-pn-realaudio.png


The spec changes here would be:
- adding a icon-prefix key to the .desktop file spec
- describing this behavior in the icon theme spec.

The advantage to this is that the conflict resolution here is taking 
place at a app/user level instead of a system level, which means that 
we'll know things like the default application, for example. This gives 
us the ability to have more sophisticated conflict resolution 
algorithms, like the mac's.

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