Icon theme spec & inheritance

[James Richard Tyrer]

Oswald Buddenhagen wrote:
<SNIP>
> my first idea was to have hicolor "Inherits: kdeclassic, crystalsvg".
> however, this leads to desktop-specific versions of hicolor.
> so i would suggest "inverse inheritance": once we arrive at hicolor
> (possibly through auto-add) and the icon is not found there, we start
> looking at a new "Succeeds" fields in the themes. kdeclassic would
> "Succeeds: hicolor", crystalsvg "Succeeds: kdeclassic, hicolor"
> (crystalsvg can explicitly name kdeclassic, as it is the kde default and
> consequently also knows about kde's neutral theme). the successor graph
> would have to be first resolved like a dependency graph (omiting any
> themes that were already part of the inheritance graph) and then be
> traversed from the root. i'm not entirely sure what to do when branches
> appear (which will happen if both the gnome and kde default themes are
> installed). one could hard-wire some priorization into the icon loader
> (eek) or interpret some Preferred-In: field. however, in the end, this
> is a static preference of the user.

Having given this some thought, I have personally come to the conclusion 
that "before" is the problem.  If the purpose of using additional themes 
is to plug holes in HiColor, then these need to come after.  As you 
said, HiColor needs to inherit KDEClassic, but in GNOME, HiColor 
probably needs to inherit Gnome.  These might need to be backed up by 
other themes.  As I have said elsewhere, the only answer that I can see, 
no matter that it isn't too good, is to have a file with a list of 
themes to be used in order as secondary backups when the fall back to 
HiColor still doesn't find an icon. This file could have [tags] for the 
different desktops in use, or we could have different files with an 
extension indicating the desktop.  This would be done on the theory that 
some icon is better than the "?" icon no matter that it clashes with the 
current icon them.

> two more things to consider later:
> - we need a desktop-agnostic way of configuring the current icon theme.
>   3rd-party apps that do not use any of the desktop frameworks are
>   pretty screwed these days.
> - it would be advantageous if a user would be able to combine multiple
>   themes and even override the inheritance graph (without hacking the
>   theme files, that is): the 3rd party theme market is very fragmented,
>   thus many similar and incomplete themes that don't know anything
>   about each other exist.

I would hope that apps would start installing icons according to the 
standard.  But, then we have the same issue as these icons (if not 
private icons) would have themes and they wouldn't have many icons in 
the theme.  Or, they would install the icons as HiColor and we would 
have the collision problem as outlined in the next thread.

-- 
JRT