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

[Bastian, Waldo]

KDE uses 
$KDE_PREFIX/share/apps/<app_name>/icons/<theme>/<size>/<type>
for application specific icons.

It doesn't use XDG_PREFIX and neither should it as long as
$XDG_DATA_DIR/apps is not part of any XDG specification.

Waldo Bastian
Linux Client Architect - Client Linux Foundation Technology
Channel Platform Solutions Group
Intel Corporation - http://www.intel.com/go/linux
OSDL DTL Tech Board Chairman

>-----Original Message-----
>From: xdg-bounces at lists.freedesktop.org [mailto:xdg-
>bounces at lists.freedesktop.org] On Behalf Of James Richard Tyrer
>Sent: Friday, June 23, 2006 9:59 PM
>To: Shaun McCance
>Cc: xdg at lists.freedesktop.org
>Subject: Re: Multiple DeskTops, HiColor theme, standardized icon names,
&
>menu icons
>
>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
>_______________________________________________
>xdg mailing list
>xdg at lists.freedesktop.org
>http://lists.freedesktop.org/mailman/listinfo/xdg