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: [EMAIL PROTECTED] [mailto:xdg- >[EMAIL PROTECTED] On Behalf Of James Richard Tyrer >Sent: Friday, June 23, 2006 9:59 PM >To: Shaun McCance >Cc: xdg@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@lists.freedesktop.org >http://lists.freedesktop.org/mailman/listinfo/xdg _______________________________________________ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
