mime-type icons, a proposal

[Ryan Gammon]

Alexander Larsson wrote: 

> (By good I mainly mean good for the *user*, perhaps not for companies that want to
> maximize branding.)

Ouch.

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


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


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


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

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


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