mime-type icons, a proposal

[Alexander Larsson]

On Mon, 2004-09-27 at 17:29 -0400, Rodney Dawes wrote:
> 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.

Sure, we have to specify a standard for mime icons. But even if we
continue using the gnome method of "gnome-mime-..." for now the rest of
the proposals in this mail can still be used by gnome and things will
work fine. So, thats an ortogonal thing to how this is handled.

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

Of course you can't have "neutral" icons that matches all icon themes. I
don't see why forcing app authors to draw multiple icons for what
happens to be the current default for various desktops helps with this.
If we force people to do this, its extremely likely they'd just copy the
same icons into these themes anyway.

hicolor is currently the only thing actually shared between desktops. If
you remove this, then the icon theme "standard" will be even more of a
joke, actually sharing nothing at all between desktops. It'd be nothing
at all different from gnome and kde having totally different systems.
For instance, an installed kde app wouldn't get an icon in the gnome
panel menu unless the kde app specially installed a gnome icon (which is
unlikely).

We *must* have a common location that *both* kde and gnome and any other
implementation of things like the desktop file spec look for icons, or
apps won't be able to install app icons that work on all
implementations. This is non-negotiable. 

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

Sure, we do allow aliases in the current spec. But that is very
different from making up things mimetypes like "category/document" that
has been proposed in this thread.

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

Ehhhhh? I think you missed the point about this rule.

This rule is to avoid a huge performance penalty. See e.g. rmls recent
text about why reading many small files is extremely bad. Just because
it is wrapped in a library doesn't mean the app doesn't actually do it. 

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

I don't see the conflict. It allows the third-party app to install
themed icons in specific themes. That icon will be used if there is no
mimetype icon already in the theme, but before the fallback icon in the
theme. And it allows apps to do this without fighting over a filename.

This:
a) Doesn't break theming (as long as there are fallback icons)
b) Lets third party install (themed) icons for new mimetypes
c) Doesn't cause file conflicts
d) Uses the themes built-in mimetype icon if it exists instead of the
app-specific icon

The only thing it doesn't allow is for third party apps to install
unthemed icons that override themed fallback icons. But this is a
deliberate limitation.

> > 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
>
> This sounds interesting. Perhaps we should allow both methods though?

Well. Its really just an extension of the old method. By using a list of
one item you get the old algorithm. So, allowing "both" is really
inherent in the algorithm.
 
> > 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?

In fact, its failing in the exact manner you're describing. Its picking
the same icon (gnome-mime-application) for application/illustrator and
application/x-arj, which is clearly not what any user would want.

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

Adding "mime" to the filename does make it avoid conflicts with other
icons in an icon theme that e.g. apps use in a desktop file or whatever.
The fact that mime icons are in a subdirectory has no affect whatsoever
on the way icons are looked up. Its merely a way for theme authors to
have some structure on their files. The icon namespace is a global non-
hierarchical namespace. 

I think a user would prefer a generic spreadsheet icon for a gnumeric
file instead of a "category-unknown" icon. This is not some contrived
situation either! A new theme would start by doing the generic type
icons, such as spreadsheet, and this would immediately cause all
spreadsheet type mimetypes to use that icon. One could later add a
gnumeric-specific one, but many theme authors probably wouldn't add
specific icons for all sorts of mimetypes.

I'm aware of your list of icon names. However, by now all the desktops
using the icon theme spec already has lots of apps using their current
icon names, and lots of themes using them. Changing this is gonna be
very very hard. Thats just the way things are. Deciding on the list of
common icon names to use is just a small part of doing a change like
this.

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

I won't be at the gnome summit. Neither will the kde people, or the
other desktops that need to agree on this.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl at redhat.com    alla at lysator.liu.se 
He's an oversexed small-town shaman with a passion for fast cars. She's a 
cynical red-headed bodyguard on the trail of a serial killer. They fight 
crime!