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

[Shaun McCance]

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.  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.  It has nothing to do with Gnome.

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.

I could track the user's current theme and switch the directory
I append to the search path (hack hack hack!) if I find one of
HighContrast, HighContrastInverse, or LowContrast, but then I'm
coding specifically for Gnome's accessibility themes.  That would
be Gnome-specific, and that's a problem.

What I'm talking about is having base icon themes for certain
common accessibility requirements.  They don't even have to have
any icons.  They just need to have actual themes inherit from
them.  Couple that with a more intelligent way to add directories
for application-specific icons, and we'd probably have a working
solution.  And it's not a Gnome solution.

--
Shaun