mime-type icons, a proposal

[Rodney Dawes]

On Fri, 2004-09-24 at 12:22 +0200, Alexander Larsson wrote:
> 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.)

> * 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 should specify style for naming of such icons, rather than relying
on the applications to provide custom names, for the general mime type
case anyway. For the "app-specific icon" tag you mention below,
specifying style is still good, but can allow a little more free form.

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

Right. I'd like to rethink this part of the spec after some of the
other things get fixed, like standardizing naming styles and fixing
the lookup method to allow lists. It seems like we need to make the
fallback be desktop-specific, since the "hicolor" theme can't really
have "neutral" icons installed to it, since the "default" for various
desktops may vary wildly. The "gnome" and "Crystal" themes are a good
example. But this belongs in another thread in the future I think.

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

While I agree that we should strive to maintain a sane standard, I still
think we need aliasing to be able to force those mime types when we get
the "false" ones from a web server or other source.

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

Better comments below, but it seems to work fine for me in gnome.

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

I think the solution for gnome would be to have gnome_vfs_mime_get_icon
() do the right thing. I don't think there's any reason an appliction
on the desktop level should need to do any more than make such a call.
The file chooser in GTK+ handles this independently anyway, and doesn't
need any extra application support for it.

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

Your proposal below seems to conflict with what you want here, and just
favors the fallback icon in the current them, if it is available, before
falling back to lower themes in the tree and getting the third-party
icons that were installed by the app into "hicolor" or whatever.

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

This sounds interesting. Perhaps we should allow both methods though?

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

This is sounds like an implementation/lack of specification issue, more
than one where we need to design some new trickery to magically solve
our problems. It looks like application/ has a fallback icon in the
gnome theme, so it should theoretically work. It seems to work just fine
for me, in fact. How is it failing exactly?

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

I made up a rather large list of icon names and sent a proposal a while
back, but never really got any feedback other than "cool" from a couple
artist-type peoples. Anyway, I don't think we need to have "mime" be in
the actual filename for the icon. It's redundant and doesn't add
anything to the process. We already put all of the mime icons in a mime
subdirectory. Where we don't know have a specific icon, we can just fall
back to "category-unknown" for the icon I think. I don't really see what
adding another tag to allow the mime entry to specify the fallback
generic icon, gains us.

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

I think it's a pretty solid proposal, but needs a little bit of thinking
in some respects. I'm sure the artists will love it when we can give
them a standard definition of icon names and such. Maybe myself, you,
and others can get together at the Gnome Summit and hash this out
better? I really want to get the icon name standardizing done this
cycle.

-- dobey