Multiple DeskTops, HiColor theme, standardized icon names, & menu icons
waldo.bastian at intel.com
Sat Jun 24 08:44:52 EEST 2006
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.
Linux Client Architect - Client Linux Foundation Technology
Channel Platform Solutions Group
Intel Corporation - http://www.intel.com/go/linux
OSDL DTL Tech Board Chairman
>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,
>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:
>>>>> 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.
>>> 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:
>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
>> 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.
>xdg mailing list
>xdg at lists.freedesktop.org
More information about the xdg