mime-type icons, a proposal
rgammon at real.com
Tue Sep 28 00:19:37 EEST 2004
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:
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:
... 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
>>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.
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.
rgammon at real.com
Developer for Helix Player
More information about the xdg