mime-type icons, a proposal

[Alexander Larsson]

I've read all the mails in the mimetype icon thread, and I'd like to
summarize what I think about this and give a possible solution to
these issues. 

First, let me give a list of base rules that I think most people
here (although perhaps not all) will agree are good. (By good I mainly
mean good for the *user*, perhaps not for companies that want to
maximize branding.)

* Icons are a way of showing the type of the icon, thus they are a
  graphical manifestation of the mimetype. They are not mainly related
  to the application which at the moment handles them. This means for
  instance that its fine for a realplayer audio clip to have a real
  logo on it, but if real currently handles mp3s (or some new type
  not yet in the shared database) then that icon should not have a
  real logo.

* We (and the specs) have to acknowledge the fact that applications
  will introduce new mimetypes that are not yet in the shared mime
  specification, and that until they are common enough to be in there,
  and have icons in widely used icon themes we must allow third party
  applications to specify icons for these file types, as well as the
  other mime type descriptions that the shared mime spec allows. 

* We cannot have applications fighting over installing icons as
  well-known filenames. That makes packages conflict and makes
  installation of apps order-dependent.

* We should strive to avoid adding new "false" mimetypes. I know we
  often add non-standard mimetypes to the database, but at least
  these are real types of real files. We shouldn't add mimetypes to
  the database, or in any way create them, if they aren't a possible
  type of an actual real world file or stream.

* Having some form of icon fallback for specific mimetype to generic
  ones is very useful. The current way this is handled in gnome works
  for audio and video, but little else. We would like a better way to
  handle this.

* Basically all applications will need to be able to show icons for
  files, since the file selector must do this. Currently such an
  application only needs to read the mime magic table and the
  extension/filename mapping table to be able to show icons. A
  solution to the mime icon problem must not force applications to
  read the whole mime database, because that would mean a lot of
  memory wasted in *all* running applications. We can however
  introduce another small file for this specific purpose if we need
  to.

If you start thinking about mime types, file icons and icon themes
you'll very soon bump into the core problem in this area. The conflict
between theme consistancy and type-specific icons. At its most
rudimentary form, it goes like this:

A user has selected a theme "A", which has a very specific look. He
views a file of some type (say its some type of sound encoding). That
specific type has no icon in theme "A", but there is a generic type
that the type belongs to (the sound type), and that has an icon in
"A". However, there is also a fallback theme for "A" in use, and this 
theme has an icon for the specific type, but it doesn't match the
visual look of theme "A". Which icon do we use?   

This problem has appears in many places. A common one is if you make
an icon theme for Gnome that has a very distinct look, and you don't
want the default specific icons to be used instead of the fallback
icons. The way this is currently handled is by making lots of symlinks
from the specific mime names to the generic one. However, when the
base gnome icon theme adds a new specific icon this approach breaks.

Another example of this is adding a new mime type that is not
yet in any theme. If this is added to hicolor, currently all themes
will inherit it, breaking their visual look. However, the other
approach of using the general icon from the same theme instead of the
inherited one makes it impossible for third party apps to add
icons.

Many people dislike third party applications installing icons that
break the look of their theme, but clearly from the last example we
cannot just always prefer the generic icon over inherited
ones. However, we also can't allow apps to just install themed
versions of their icons, because this would break the rule above about
fighting over well-known filenames. So, this is a complicated issue to
solve.

There is another issue related to this problem. We already have
conflicts with mimetypes today. Several applications can install a
mime description file according to the spec, and they will be
"merged". However, some of the entries in a <mime-type> entry cannot
really be merged, such as "comment", or a potential "icon" one. This
means, that each system that implements this already have some form of
conflict resolution (even if only by coincidency due to the way the
code implemented conflicts). So, if someone installs a description of
a mimetype that is already in the freedesktop database, or in another
apps file, which one is used as the source for the type description,
and if we go that way, for the icon? 

A possible solution:

My solution is in three parts, each needed to get a satisfactory
result to mime icons.

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. 

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

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


Some people will not like this proposal. In particular, people from
real will probably not like that they have to provide many themed icons,
and that they can't get a real-specific icons into all themes
automatically. However, I think its a pretty good compromise that
allows real to install real-specific icons while still allowing theme
designers some level of control of how their themes look.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl at redhat.com    alla at lysator.liu.se 
He's a witless drug-addicted master criminal looking for a cure to the poison 
coursing through his veins. She's a sarcastic impetuous Valkyrie operating on 
the wrong side of the law. They fight crime!