Re: Fwd: [gnome-love] Participate to the GNOME Goals and feel the love!
- From: Shaun McCance <shaunm gnome org>
- To: Rodney Dawes <dobey novell com>
- Cc: GNOME Desktop Hackers <desktop-devel-list gnome org>
- Subject: Re: Fwd: [gnome-love] Participate to the GNOME Goals and feel the love!
- Date: Wed, 12 Apr 2006 13:22:29 -0500
On Tue, 2006-04-11 at 23:14 -0400, Rodney Dawes wrote:
> On Sun, 2006-04-09 at 16:37 -0500, Jonathon Jongsma wrote:
> > On 4/9/06, Vincent Untz <vuntz gnome org> wrote:
> > > We currently have two goals:
> > >
> > > + http://live.gnome.org/GnomeGoals/AppIcon
> > > This is about correctly installing and using application icons so
> > > that we're theme-friendly.
> >
> > Can I ask for a little bit of clarification on this goal? Is this
> > only supposed to apply to the application icon? What about apps that
> > provide different icons (toolbar icons, etc.)? Are these expected to
> > still be installed to $datadir/pixmaps? or should they follow the
> > same pattern described for app icons?
>
> The Icon Theme Specification was designed mainly with the purpose of
> making it easy to theme and install application icons in a canonical
> location (or set of locations). Icons for toolbars/etc... really should
> not be installed to theme directories by applications. And applications
> should only install the application icon (at the various sizes), into
> the hicolor/$size/apps/ directories.
>
> If there are specific toolbar icons in question, please bring them up
> on gnome-themes-list, so that we can appropriately determine how they
> should be dealt with. In general, application-specific icons should be
> installed into that application's private datadir.
Just to clear things up for people who don't understand
how this works (and then I'll ask a question that I still
haven't gotten a satisfactory answer for):
Yelp installs a number of icons for its own use. A number
of these could probably be standard icons (like admonition
graphics), but some of them shouldn't (like watermarks).
Yelp puts these icons into $(DATADIR)/yelp/icons, and then
makes this call in yelp-settings.c:
icon_theme = gtk_icon_theme_get_default ();
gtk_icon_theme_append_search_path (icon_theme,
DATADIR "/yelp/icons");
Basically, this means that icons are looked up as normal,
except that if GTK+ still hasn't found the icon when it
got to hicolor, it checks $(DATADIR)/yelp/icons as well.
Easy as pie, works like a charm.
Yelp also names all its icons with the "yelp-" prefix.
Since the icons are in an application-specific directory,
there's no worry about conflicting with other applications'
custom icons. But this naming helps future-proof the icons
against standard icons that might be added at some point.
Now the question: Everybody generally agrees that the
only sustainable solution with respect to HighContrast
and HighContrastInverse is for applications to install
high-contrast (inverse) versions of any custom icons
they provide. Yelp *should* install such version for
the admonition graphics and watermarks.
But now, where's Yelp supposed to put those? If I'm
not supposed to install the base icons into hicolor,
then it doesn't seem right for me to install into
the HighContrast(Inverse) theme directories either.
So here's one idea, which might have problems that
I haven't thought of: Rather than appending to the
search path, set an explicit application-specific
directory. This directory would have a layout like
one of $(XDG_DATA_DIRS)/icons. That is, it would
contain "icon themes".
gtk_icon_theme_set_appdir (icon_theme,
DATADIR "/yelp/icons");
$ ls /usr/share/yelp/icons
hicolor/ HighContrast/ HighContrastInverse/
The icon theme implementation would look for the icon
with its normal algorithm first, including looking for
icons in inherited themes. Only after it fails to find
an icon anywhere else, it would look at the directory
provided by the application as if it were just another
element in $(XDG_DATA_DIRS)/icons.
Maybe this has problems I haven't thought of, or maybe
it's an over-engineered solution. I'm just throwing
out some ideas in the hope that we can find a solution
that developers will actually use.
--
Shaun
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]