Icon theme spec & inheritance

[Oswald Buddenhagen]

moin,

kde's default theme is currently crystalsvg. consequently almost
everything in kde is shipping only crystalsvg icons. means no hicolor.
the logical consequence is that any application that is part of the kde
releases will have no icon in any other desktop than kde if an icon
theme other than crystalsvg or one of its descendants is selected, as
the other icon loaders have no fallback on crystalsvg hardwired.
correct so far?

based on the current spec, i see these possibilities for solving the
problem:
- have complete themes. this is a nice pipe dream. in particular, it is
  sort of unreasonable to expect gnome's default theme to ship icons for
  kde core apps.
- have the icon loaders know other desktops' fallbacks. that's simply
  ridiculous.
- have kde core apps install hicolor icons:
  - have the requirement to create a real hicolor icon along with the
    default theme icon for everything. this meets massive resistance
    from the artists, understandably. also, i don't think we really
    *want* to ship two complete themes with the minimal install of kde.
  - copy crystalsvg icons to hicolor. this solves the artist effort
    problem, but not the "double size problem", is a maintenance
    nightmare in svn and is pretty poor from an engineering pov.
  - move crystalsvg icons to hicolor. this solves the "double size
    problem", but not the maintenance problem and makes packaging the
    theme standalone a total nightmare.
  it must be noted that desktops cannot install non-application icons
  into hicolor anyway, as this would cause clashes.

obviously, none of these "solutions" is really workable.
i think the fundamental flaw here is this sentence in the spec:
  (implementations may add more default themes before "hicolor", but
  "hicolor" must be last)
this says two things:
- the responsibility for the fallback is with the icon loader.
  this leads to the problem i pointed out above.
- hicolor comes last.
  however, that means that themed icons (the ones from the default
  theme) will be preferred over "unthemed" (*) icons (the ones from
  hicolor). this looks Just Bad if the current theme is not derived from
  the default theme (otherwise it would inherit from it anyway).

as noted above, desktops cannot install non-app icons to hicolor. still,
they might want to provide neutral (*) fallback icons. for practical
reasons, the neutral app icons would be in this theme as well, probably.
such a theme is kdeclassic.

now some examples how sensible inheritance graphs look like:
1) kde default: crystalsvg -> hicolor [ -> kdeclassic ]
2) crystal extension: shinycrystal -> crystalsvg -> hicolor [ -> kdeclassic ]
3) kde classic: kdeclassic -> hicolor -> crystalsvg
4) 3rd party theme: crystalsux -> hicolor [ -> kdeclassic ] -> crystalsvg

observations:
3rd party apps provide icons in hicolor, so the inheritance line
always ends there. however, for the desktops, hicolor is only a
namespace that needs to be implemented by some particular theme.
this implementation should be preferably "unthemed". only if it does not
cointain the wanted icon, a fallback on the default theme (which might
have a very particular style) should be done.
this mechanism should not be hard-wired into the icon loader.
we can't have "crystal-hating" themes explicitly inherit from all more
neutral themes, as this would require a crystal ball (haha, what a pun).
the order of hicolor and the kdeclassic is irrelevant, as no icon should
be in both of them under normal circumstancesa.

ideas:
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.

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.

now let the flames come. ;)


(*) ok, so there is no neutral art. but you have to agree that some is
way less "specific" than other. think pop vs. death metal.

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