Icon theme spec & inheritance
James Richard Tyrer
tyrerj at acm.org
Sun Jun 3 10:26:25 PDT 2007
Oswald Buddenhagen wrote:
> 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.
More information about the xdg