Icon theme spec & inheritance

[Shaun McCance]

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

[snip]

> - 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

http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html

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

/usr/share/icons/hicolor/apps/32x32/help-browser.png

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
>     branding-wise

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
>     irrelevant
>   - 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
> installed/upgraded.

Can't we just get it right?  I don't want to see this in
our desktop preferences dialogs:

    Icon lookup search order:
      (*) Forward
      ( ) Reverse
      ( ) WTF?!

--
Shaun