Proposal for better handling of mimetype icon themeing

[Alexander Larsson]

On Tue, 2006-01-03 at 12:14 -0500, Rodney Dawes wrote:
> On Mon, 2005-12-19 at 18:46 +0100, Alexander Larsson wrote:
> > I propose the following approach to fix this:
> > 1) To fix the inheritance problem, add a way to the icon theme spec to
> >    find the right icon from a list of icons, looking on each of the
> >    icons in the list before moving on to its inherited theme.
> > 2) Add to the mimetype database a generic-icons field. This allows us
> >    to give a list of generic icons to use for a mimetype if the normal
> >    mimetype is not found.
> > 
> > For example, say we add this to the jpeg mime type:
> >     <generic-icons>
> >         <icon name="image-photo"/>
> >         <icon name="image"/>
> >     </generic-icons>
> 
> For these examples and in your patch, can we use the generic icons as
> specified in the Icon Naming Specification? We should anyway. If there
> are issues with the naming, I am happy to discuss them and see if we
> can't come up with something better to use.

Sure, i don't care what names we use in the examples, and using the ones
from the spec makes sense.

> > Now, when we look up the icon for image/jpeg with this we first create a
> > list: image-jpeg, image-photo, image, image-x-generic
> > Then we use the new icon theme spec feature to find the fist match of
> > the list in the theme (such that if image-photo is in the current theme,
> > but image-jpeg in hicolor, image-photo from the current theme will still
> > be used).
> 
> Hrmm. Or is it that we look for MIME type icon, list of icons in the
> XMl, and then the generic icon specified in the naming spec? I'm not
> sure that I like that idea. It promotes the use of arbitrary names that
> get defined outside the specification. Is there some way that we can
> specify the method, such that it doesn't get used to subvert the names
> within the naming spec? It's only really a major problem with all of the
> stuff under application/ for the MIME types. It currently works for
> audio, text, images, and video, albeit not optimally, due to searching
> all themes in the inheritence tree, as a single theme. Very rare is it a
> case where we should need to do this for things that aren't under
> application/ I think.

Isn't image-x-generic what the naming spec specifies in this case?

The main idea was to put icon names from the naming spec into the
freedesktop mime database, so the "list of icons in the XML" is the same
as the ones specified in the naming spec. I don't understand how you
could look up "the generic icon specified in the naming spec" in any
other way (except hardcoding it in each implementation).

Also, while its true that its mostly application/* and text/* that are a
problem its could be nice to have some sort of files in image/* use
different icons. For instance in my example jpegs can use image-photo if
it exists. This could be done for e.g. jpeg and tiff, but not for png
and gif. Wouldn't that be useful? In the same way i think there are
subclasses in video/* and audio/*.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl at redhat.com    alla at lysator.liu.se 
He's an uncontrollable native American shaman on a search for his missing 
sister. She's a cynical French-Canadian soap star who don't take no shit from 
nobody. They fight crime!