Multiple DeskTops, HiColor theme, standardized icon names, & menu icons
James Richard Tyrer
tyrerj at acm.org
Sat Jun 24 07:58:43 EEST 2006
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 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.
More information about the xdg