Icon theme spec & inheritance
ossi at kde.org
Mon Jun 18 08:35:39 PDT 2007
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
- 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
- themes providing overrides is possible, but sort of rude
- 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.
- 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
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
Chaos, panic, and disorder - my work here is done.
More information about the xdg