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
[email protected]
http://lists.freedesktop.org/mailman/listinfo/xdg
