Icon theme spec & inheritance
shaunm at gnome.org
Mon Jun 18 10:15:11 PDT 2007
On Mon, 2007-06-18 at 17:35 +0200, Oswald Buddenhagen wrote:
> On Sun, Jun 17, 2007 at 05:56:52PM -0700, James Richard Tyrer wrote:
> > Aaron J. Seigo wrote:
> > > On Sunday 03 June 2007, James Richard Tyrer wrote:
> > >> As you said, HiColor needs to inherit KDEClassic, but in GNOME,
> > >> HiColor probably needs to inherit Gnome.
> > >
> > > it doesn't.
> > What doesn't do what?
> oh, c'mon, it's clear that this referred to the last sentence. you are
> unable to state a problem in a few words and aaron is unable to
> split/cut quotes - so what? ;)
> this is my summary of the topic. there are three categories of icons
> that need to be considered separately:
> - generic icons
> - application menu icons
> - consensus seems to be that every application *has* to ship a hicolor
> icon. yes, even if it is part of a desktop's core module. an
> application that does not provide an icon here does not deserve
> better than being shown as a question mark
When did that consensus come about? Any application that just
uses an icon from Table 2: Standard Application Icons in
should not be required to ship its own icon. In fact, they should
not ship their own version. Otherwise, Yelp and khelpcenter will
both try to install
And that would be bad.
> - if you have a clash here, you probably have bigger problems
> elsewhere anyway
> - themes providing overrides is possible, but sort of rude
I suppose it sort of depends on the application. I certainly
don't mind Yelp being rebranded by an icon theme. But then,
Yelp shouldn't have a strong independent identity. If you
don't want your application icon overridden by themes, then
IIRC you can give an absolute path for the Icon key in your
application's .desktop file.
> - private application icons
> - where the app installs its native private icons is completely
> - if it does not provide private icons it requires it does not deserve
> better than question marks
> - to be able to theme the app's private icons, the app needs to look
> for icons from the configured theme(s) in some standard locations,
> like share/icons/<theme>/apps/<app> or whatever - some ideas were
> brought up in the discussion a year ago.
My recollection is that developers should not install these
anywhere under share/themes. The recommended place for them
is under share/<app>/icons/<theme>. Since these icons only
ever need to be loaded inside your application, it's sufficient
to add this directory to the icon search path within your code.
In GTK+, this is done with gtk_icon_theme_append_search_path.
I'm sure KDE/QT has something equivalent.
> - theming the app's private icons may be rude, too, but otoh the app
> will probably mix standard icons with own icons, so precluding
> theming the private icons makes no sense - unless the app completely
> ignores theming preferences and requires a particular theme.
And if applications really do not want their private icons
overridden by themes, then they shouldn't load those icons
through the icon theme. Developers have the choice here.
> imo, the complete search order of icons should be configurable through
> the theme choice xsetting. the algorithm to calculate this setting from
> the themes explicitly chosen by the user could be the "forward/reverse
> inheritance" i suggested in this thread originally. that way tango (or
> any other theme that claims to be neutral and complete) could simply
> plug the holes in an older desktop's default theme by simply being
Can't we just get it right? I don't want to see this in
our desktop preferences dialogs:
Icon lookup search order:
( ) Reverse
( ) WTF?!
More information about the xdg