[no subject]

	 The lookup is done first in the current theme, and then recursively in
each of the themes inherited the current theme, and finally in the theme
called "default". As soon as there is an icon of any size that matches
in a theme the search is stopped. Even if there may be an icon with a
size closer to the correct one in an inherited theme we don't want to
use it. Doing so may generate an inconsistant change in an icon when you
change icon sizes (e.g. zoom in). 

That still leaves a lot of room for interpretation of how icon sets are
merged and put together on a working implementation, doesn't it? Given
the parent post's suggestion, this could be rather easy since we can
have a base set of icons that can be required. For example, GNOME could
depend on a base icon package, which could be replaced by the brushed
metal base icon package. Other programs like AbiWord or Gimp could
depend on their own icon packages. On a system like Debian, one could
easily write a script to check to see what brushed metal icon theme
packs were available (they'd probably have very similar package names),
and query to see which of those apps are installed (easy since the icon
pack would depend on the program) and download the apropriate icon packs
for brushed metal. This, of course, is not to say that users wouldn't be
able to over ride the default mapping for an application icon and pick
an icon for gimp from the abiword icon pack. However, that raises
another interesting question - what happens when Abiword is removed from
the system? Maybe we need fall back on user overridden icons more than
we do on icon theme selection?

I am kind of sick of the big icon pool concept, and would rather have it
organized in a useful way. Windows did it by embedding icons in programs
- that's lame - let's do it better :)

These are just ideas - feel free to shoot them down with better ones :)

Mathew Johnston