mime-type icons, a proposal

[Alexander Larsson]

On Mon, 2004-09-27 at 14:19 -0700, Ryan Gammon wrote:
> 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.

Are you sure thats what happens?
Its sort of hard to figure out. Most of the doc describes how to present
icons for folders and applications/application launchers, then it says:

* Display the document appropriately.
The Finder consults the application database and locates the icon to
display next to the filename. If no such icon exists, it displays the
default document icon.

It does say "application database", but its not very explicit about how
this is done. Any heavy OSX users here that know?

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

Fooood fiiight!

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

Any solution that includes a global option on how to handle something as
core as how to show icons for files strikes me as very bad. We should
just specify something fully, or if we're unable to reach consensus,
leave it up to implementations to decide.

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

This solution is at the core very similar to my proposal. Its just that
the conflict resolution is handled by using the default app instead of
some random way to do the mime info merging. However, it also means that
for each mimetype icon lookup we must do default app lookups which will
cause a larger performance hit. It also complicates how to cache mime
icons. Any change to a desktop file or application default file could
potentially invalidate the icon cache. 

Doing default app lookup operations involves loading several
default.list files and parsing different desktop files for each mimetype
seen. However, at least we don't need to read *all* desktop files, so
app startup might not be too badly affected and with good use of caching
this won't be a performance issue either. (Its not like icon themes
aren't a really bad performance problem already, but lets try to not
make it worse.)

Its a performance tradeoff really, most desktop files won't have the
icon-prefix (probably no files shipped in a distro would), so for many
the extra work is unnecessary, but it does give a nicer way to handle
conflicts for third-party apps.

I'd probably be for an approach like this, but i'd still want sane
fallback icons for most mimetypes so that themes can easily get themed
icons for most mimetypes without having an icon per mimetype.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl at redhat.com    alla at lysator.liu.se 
He's an unconventional vegetarian romance novelist moving from town to town, 
helping folk in trouble. She's a provocative junkie Valkyrie with the soul of 
a mighty warrior. They fight crime!