Proposal for better handling of mimetype icon themeing

[Rodney Dawes]

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.

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

> I think its about time we got this solved. When we get this in the icon
> name spec people can decide on the core set of generic icons we should
> use in the freedesktop.xml database.

Agreed. Let's get this moving forward.

-- dobey