Icon theme spec & inheritance

[Oswald Buddenhagen]

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
  - the icon naming spec deals with those
  - nobody installs any such icon into hicolor
  - some themes are intentionally incomplete, as they are modifications
    of other themes. they explicitly specify their parent, so they are
    fine
  - incompleteness is supposed to be no issue. BUT this is an impossible
    goal: suppose i have the newest version of K. but i despise K's
    default icon theme. but i like G's icons, so i use that. but G made
    no release meeting the newest icon naming spec extensions, yet. so
    some of K's icons will show up. i guess other situations can be
    constructed for incomplete themes without anybody making a mistake.
    this is where auto-injecting some "neutral" theme into the search
    path becomes interesting.
- 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
  - if you have a clash here, you probably have bigger problems
    elsewhere anyway
  - themes providing overrides is possible, but sort of rude
    branding-wise
- 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.
  - 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.

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.

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
--
Chaos, panic, and disorder - my work here is done.