mime-type icons, a proposal

[Alexander Larsson]

On Fri, 2004-09-24 at 18:13 -0700, Ryan Gammon wrote: 
> Alexander Larsson wrote: 
> 
> > (By good I mainly mean good for the *user*, perhaps not for companies that want to
> > maximize branding.)
> 
> Ouch.

Don't take it to personal. We've all seen way to much branding when
installing various third party apps on windows. We want to protect
against this happening for the linux desktops too. 

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. 

I mean, could you imagine a Mac applicating putting a load of icon on
the desktop? Thats the users file space! Users would be outraged and
remove the thing immediately.

> > A possible solution:  
> 
> The goals of guys like are generally:
> - Provide one set of mime type (document) icons that look neutral, and
> will fit reasonably well into the theme of any given free desktop -- the
> whole hicolor thing is great.
> - If distros or icon theme creators want to put the work into creating
> branded icons that fit well into a given desktop theme, they can do that
> & run it past the company owning that brand for approval, and all is
> well.
> 
> Everyone wants software looking its best on every desktop at the end of
> the day.
> 
> > My solution is in three parts, each needed to get a satisfactory
> > result to mime icons.
> 
> I'm work through this for our particular app inline below.
> 
> > 1) List-lookup of icon themes
> > 
> > Currently, the only way to look up in icon themes in the spec is to do
> > it one icon name at a time, traversing all inherited themes for each
> > icon name. Any algorithm using this form of lookup will always prefer
> > the more specific mimetype icon, even if it breaks the visual look of
> > the current theme and there is a fallback in the theme.
> > 
> > I'd like to propose a different type of lookup, where you give an
> > ordered list of icon names, and each name in the list is tried in the
> > icon theme before we try the inherited theme. This way you can get
> > fallback icons in the same icon theme before specific icons in
> > inherited themes. 
> 
> So we have something like a generated:
> /usr/share/mime/audio/x-pn-realaudio.xml
> 
> roughly with entries like:
> <mime-type type="audio/x-pn-realaudio">
>   <icon>mime-audio:x-pn-realaudio.png</icon>
>   <icon>realplay-mime-audio:x-pn-realaudio.png</icon>
> </mime-type>

No, more something like:

<mime-type type="audio/x-pn-realaudio">
 <comment>RealAudio broadcast</comment>
 <alias type="audio/vnd.rn-realaudio"/>
 <app-specific-icon>realplay-mime-audio:x-pn-realaudio.png</app-specific-icon>
</mime-type>

The non app-specific icon already has a well-defined icon created from
the mime name.

> > 2) Introduction of "app-specific" icons for mimetypes
> > 
> > If an application installs a mime description xml file for a new type
> > (one that potentially doesn't exist in the mime database and have no
> > icons in common themes), it sets the "app specific mime icon" (better
> > name needed) in the mime description to an icon name that it
> > installs. This icon name should be application specific so that it can
> > be installed into an icon theme without file conflicts. Something like
> > "real-mime-audio-realplay", or "totem-mime-video-x-dirac".
> > 
> > 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. 

> > The freedesktop.xml file won't have any
> > app-specific icons, so there will never be any conflicts with that.
> > 
> > When looking up an icon for a file we do a list-lookup in the current
> > icon theme using the list: [specific mime type icon name, app-specific
> > mime icon name, generic mime type icon name]. This means we'll always
> > use the themes specific icon if it exists, and we prefer the themes
> > generic icon to an inherited specific icons. However, it also allows
> > third party applications to install themed icons in commonly used
> > themes so that they are prefered before the generic icons. And the
> > app-specific icons are not well known filenames, so they can be
> > installed without fear for file conflicts. 
> > 
> > Thus, real could install a mimetype file for realaudio files that adds
> > an app-specific mimetype and then a set of icons for common themes. If
> > these themes already have (or later adds) a specific icon for
> > realaudio files, that icon is prefered, and if a real doesn't provide
> > an icon for the theme you use then the generic icon from your theme
> > will be used.
> 
> 
> So in /usr/share/mime/packages/realplay.xml we'd have an entry roughly like:
> 
> <mime-type type="audio/vnd.rn-realaudio">
>   <comment>RealAudio</comment>
>   <glob pattern="*.ra" />
>   <icon>realplay-audio:vnd.rn-realaudio.png</icon>
> </mime-type>
> 
> ... which gets merged via update-mime-database into the ...
>    <icon>realplay-mime-audio:x-pn-realaudio.png</icon>
> ... line in /usr/share/mime/audio/x-pn-realaudio.xml as seen above
> 
> The order of icons checked would be, for example:
> 1. /usr/share/icons/GnomeCrystal/48x48/mimetypes/mime-audio:x-pn-realaudio.png
> 2. /usr/share/icons/GnomeCrystal/48x48/mimetypes/realplay-mime-audio:x-pn-realaudio.png
> 3. /usr/share/icons/hicolor/48x48/mimetypes/mime-audio:x-pn-realaudio.png
> 4. /usr/share/icons/hicolor/48x48/mimetypes/realplay-mime-audio:x-pn-realaudio.png
> 
> (2) and (3) probably won't be icons that normally get used.
> RealPlayer would provide (4) with its install, and the icon theme would
> provide (1).
> 
> Ideally we could switch the rules for hicolor, and make (4) take
> precedence over (3), or even eliminate (3), as it is something that
> could be fought over. (2) could be eliminated too.
> 
> Looks good to me as is, though.

No. Thats not quite what I meant. First of all, I'm not sure we have
actually agreed on the whole "mime-foo:bar" thing. I know it was listed
somewhere, but I'm not sure anyone implements that yet, and I know
people had a problem with the colon, since thats not allowed in windows
filenames. For this example, assume we use it, and we use "mime-
category-audio" as the standard fallback for all "audio/*" mimetypes.
We'll do that for video/* too, and for all other mimetypes we'll define
a category in the xml and use that for the fallback (like "mime-
category-presentation".

Then this happens:
/usr/share/mime/packages/realplay.xml has

<mime-type type="audio/vnd.rn-realaudio">
  <comment>RealAudio</comment>
  <glob pattern="*.ra" />
  <app-specific-icon>realplay-audio:vnd.rn-realaudio.png</app-specifc-icon>
</mime-type>

... which gets merged via update-mime-database into the ...
   <app-specific-icon>realplay-mime-audio:x-pn-realaudio.png</app-specific-icon>
... line in /usr/share/mime/audio/x-pn-realaudio.xml as seen above

The order of icons checked would be, for example:
1. /usr/share/icons/GnomeCrystal/48x48/mimetypes/mime-audio:x-pn-realaudio.png
2. /usr/share/icons/GnomeCrystal/48x48/mimetypes/realplay-mime-audio:x-pn-realaudio.png
3. /usr/share/icons/GnomeCrystal/48x48/mimetypes/mime-category-audio.png
4. /usr/share/icons/hicolor/48x48/mimetypes/mime-audio:x-pn-realaudio.png
5. /usr/share/icons/hicolor/48x48/mimetypes/realplay-mime-audio:x-pn-realaudio.png
6. /usr/share/icons/hicolor/48x48/mimetypes/mime-category-audio.png

> > 3) Better support for generic icons
> > 
> > The way gnome handles generic icons by falling back from "foo/bar" to
> > "foo" works well for audio and video, so we should probably continue
> > with that. However, for "application/bar" types it fails miserably, so
> > many common forms of types don't get sane default icons, leading to
> > lots of symlinks in themes, or ugly inheritance from default themes.
> > 
> > I propose we make up a list of common generic type of the form
> > "mime-category-presentation", and "mime-category-spreadsheet". Then we
> > add a new entry to the mime database where each mimetype can specify
> > the generic mimetype icon to use. If none is specified we fall back to
> > the old way. update-mime-database will extract this and put in the
> > same file as the app-specific icon is stored in. (In the case of the
> > old-style fallback we don't even put this in the file, to save memory.)
> 
> 
> So we could have something like:
> 
> roughly with entries like:
> <mime-type type="audio/x-amr">
>     <mime-category>media</mime-category>
> </mime-type>
> 
> in /usr/share/mime/audio/x-pn-realaudio.xml, which adds a
> mime-category-media.png icon name as a (1) in the hypothetical search
> above.   

Something like that. We'd have to make a list of standard category names
so people would know what to use and what icons a theme needs.

> > Some people will not like this proposal. In particular, people from
> > real will probably not like that they have to provide many themed icons,
> 
> 
> With this proposal, it looks like we have to provide the set of
> fallback icons corresponding to (4), and distributions/icon theme
> maintainers can work with us to provide icons for (1). Seems reasonable
> to me.
> 
> 
> > and that they can't get a real-specific icons into all themes
> > automatically. 
> 
> 
> If all themes don't support foo/bar and we provide a
> realplay-foo:bar.png icon for hicolor, it would seem that we do get
> into all themes automatically, which is all that we're really after
> here.

That won't happen though. If a theme doesn't have a specific icon for
foo/bar, then it'll fallback to the more "generic" item for that type,
calculated from its category.

Of course, if the mimetype in not in the freedesktop database, the type
won't have a category. Then the xml file describing the mimetype could
fail to specify a category (or specify a wrong category if the type is
audio/* or video/*), thus forcing themes to fall back to the hicolor
icons rather than the generic icons. Thats life though, and we'll have
to hope that apps won't misuse the system like that.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl at redhat.com    alla at lysator.liu.se 
He's a deeply religious guerilla filmmaker with a mysterious suitcase 
handcuffed to his arm. She's a mentally unstable nymphomaniac fairy princess 
who can talk to animals. They fight crime!