Proposal for better handling of mimetype icon themeing

[Rodney Dawes]

On Wed, 2006-01-11 at 11:41 +0100, Alexander Larsson wrote:
> On Tue, 2006-01-03 at 12:14 -0500, Rodney Dawes wrote:
> > On Mon, 2005-12-19 at 18:46 +0100, Alexander Larsson wrote:
> > > 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?

Yes, but "image-photo", "image" and others aren't. 

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

True. Let's get this in and start with the icons that are in the spec,
and we can discuss expanding things later, to cover your next point.

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

I'm not sure how useful that would be really. The number of types that
don't satisfy that assumption is too great, I think. We can probably do
something like this for some other, better defined types, but doing it
with images and audio might be difficult. For video, technically
everything is a video, so we probably don't need to do anything there
either. Trying to guess if something is a feature length film vs. a
short vs. a commercial or something, is probably too complex to do.

But my consensus is, let's get this going so we can make things suck
much much less. :)

-- dobey

PS: Sorry for the slow reply. Very busy the last few weeks with all the
freeze action going on.