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

[James Richard Tyrer]

Shaun McCance wrote:
> On Fri, 2006-06-23 at 16:13 -0700, James Richard Tyrer wrote:
>> 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.
> 
> There is nothing GNOME-specific about anything I just said.  I am 
> installing my application-specific icons into my application's data 
> directory, commonly /usr/share/yelp/icons.

That isn't how you would do it with KDE.  In KDE you would install them
where I said:

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

and you can install multiple themes and KDE will (is supposed to --
there are some bugs) load the icons for the theme you are using or fall
back to HiColor.

> I am then adding this directory to the icon search path within my 
> application, which is perfectly suitable because my application is 
> the only application that needs to access them.

With KDE you don't have to add this path to anything, the KDE Icon
Loader knows to look there first.

> It has nothing to do with Gnome.

So, yes this is a GNOME specific issue -- at least a non-KDE specific issue.

> And that's exactly the hack Rodney referred to.  The problem with it
>  (and one reason it's just a hack) is that I can't provide my own 
> versions of icons for other themes without installing into those 
> themes' directories, which is evil.

You can with the system KDE uses and I thought that it was part of the
standard.  If it isn't then it needs to be.

-- 
JRT