Multiple DeskTops, HiColor theme, standardized icon names, & menu icons

[James Richard Tyrer]

Shaun McCance wrote:
> On Thu, 2006-06-22 at 17:02 -0400, Rodney Dawes wrote:
>> The real problem here is that we need a good way to deal with
>> action/status/etc... icons provided by the applications themselves,
>> which are not part of the base set of icons, or are specific to the
>> application itself, and are required by its UI. Application icons
>> themselves shouldn't be an issue, as they should be installed to
>> hicolor. 
>>
>> We really need some way for apps to install icons into a private theme
>> directory, and specify that lookups should be made within it, as a
>> fallback. One hacky way to do this currently, is to install icons into
>> a private data directory, in the "hicolor" theme, such as:
>>
>> /usr/share/application/icons/hicolor/
>>
>> One can then alter the XDG_DATA_DIRS variable internally to the
>> application, to include /usr/share/application/ within the path. This
>> will cause this instance of icons in hicolor to only be used within the
>> application in question, and avoid file conflicts with other
>> applications which may want to install an icon of the same name.
>>
>> Having a somewhat more sane method to do this, would be much better
>> though, I think. And, we certainly need one.
> 
> Just to "me too" and provide added complexity (which I know I've
> talked with you about, Rodney, but maybe not other people here
> who make shit happen):
> 
> With my application developer hat on, I've had to deal with this
> exact problem.  Yelp installs some custom icons it uses in its
> DocBook renderings.  I'll bet we could manage to make a few of
> them standard icons, but not all of them.
> 
> So trying to be a good icon theme citizen, Yelp puts its custom
> icons in its own DATADIR subdirectory, and tells GTK+ about that
> for icon lookups.  But in Gnome, we've come to the conclusion
> that it just isn't feasible for our accessibility themes to be
> constantly chasing application-specific icons.  We need to be
> able to ship accessibility versions of the icons with Yelp, but
> our current mechanism leaves us no way of doing that without
> installing directly into those themes' directories.  And if I'm
> not supposed to install to hicolor, it's certainly no less evil
> to install to HighContrastInverse.
> 
> I suspect we could probably solve this with an explicit idea
> of an application icon directory, coupled with a few standard
> base themes for accessibility.

Shaun:

What we need is not just a GNOME solution for the GNOME DeskTop.  We 
need a solution that works for a GNOME application running on any 
Desktop.  That is why the Icon Theme spec was drawn up and installing 
icons in a DATADIR doesn't follow the spec.

I proceed on the presumption that in the near future that there will be 
an XDG way to select icon themes that all desktops will access to 
determine their default icon theme (all apps running with a DeskTop will 
be using the same default icon theme -- to make any other assumption is 
simply not a good idea.

The only workable way that I see is to do exactly what RD said is a 
hack.  You should install your private icons in the proper location:

	$XDG_PREFIX/share/apps/<app_name>/icons/<theme>/<size>/<type>

And you need to install HiColor icons.  If your icons are not HiColor, 
you should install a link: hicolor -> <your_theme>.  Then the icon 
search is always going to find your private icons unless there are 
global icons with the same name.  Note that it would be best if you had 
some generic icons installed as HiColor since strongly themed icons 
might not look too good with a theme that was quite different.

You shouldn't have to tell the system about this since this is where it 
is supposed to look for private icons.  KDE will find icons installed there.

Naturally, it is OK to install icons of several themes (e.g. the 
accessibility themes) in your app's private icon space as long as you 
have something designated as HiColor for a fall back; I don't like to 
see other themes installed as HiColor, but it is better to have some 
icon of whatever theme rather than get the "unknown" icon.

It appears obvious that this was the intention when the Icon Theme spec 
was originally drawn up.  But, now a few developers appear to have 
decided to change HiColor without bothering to rewrite the spec -- that 
HiColor is just a "namespace" to install application icons in an 
assortment of icon styles.  It appears to me that if this is really 
needed -- if applications can't supply HiColor icons, that what is 
needed is not to change the purpose of the HiColor theme (which would 
leave us with a lot of new issues to resolve that now work) but rather 
to make a new icon theme: "Applications" that is inherited by HiColor 
and contains ONLY apps icons.  This shouldn't create any compatibility 
issues since systems that don't support it yet only need a link: 
applications -> hicolor.

-- 
JRT