Icon theme spec & inheritance

[James Richard Tyrer]

Aaron J. Seigo wrote:
> On Sunday 03 June 2007, James Richard Tyrer wrote:
>> 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.
> 
> it doesn't.

What doesn't do what?

> if this is about app icons, we should IMO all be using the hicolor 
> them dir for the default icon theme as defined by the people 
> responsible for the application logo icon. all other icons, including
>  third-party app icons and 'native' non-app-logo icons, can go into 
> their respective theme directories.

This about missing icons.  It doesn't matter if they are app icons or
some other type.

> non-app-logo icons are always loaded by the native icon loader in the
>  toolkit so that is a non-issue. there is no reason, rhyme or purpose
>  to change inheritance of hicolor,

This is about missing icons.  I am an engineer, therefore, you will
never convince me that the answer to the question of what to do when an
icon is missing is solved by presuming that there will NEVER be a
missing icon.  You will never convince me of that.  I will always
presume that there will be missing icons.

So, if we are using the Ikons icon theme and it doesn't contain the
needed icon.  We fall back to HiColor (perhaps after trying other
themes, but that doesn't matter as long as it failed).  The question is,
now what do we do?  What should we fall back to?  The answer is not:
this will never happen.

> and there is no reason, rhyme or purpose to insisting on a given 
> style for application logo icons.

No, there isn't.  However, there is a reason for requesting that, if
possible, the icons installed as HiColor are a generic style.  And that,
then, after installing a generic style icon as HiColor that an app
should also install icons in other themes.  Specifically, what I have
suggested is that when apps discarded their HiColor icons and replaced
them with CrystalSVG icons installed as HiColor that this was a serious
mistake.  As contrasted with ADDING CrystalSVG icons installed as
CrystalSVG which I thing is a good thing for apps to do.  My informal
and uncontrolled research indicates that 60% of users want "cool" icons
and 40% want more usable icons.  So, we need (or needed) to supply
CrystalSVG icons.

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

To emphasize what I said: I am talking about what happens when the icon
loader has fallen back to HiColor and it doesn't find an icon in HiColor.

>> 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.
> 
> for non-app-logo icons, this isn't an issue. for app logo icons, this
>  is so much more complex than it needs to be. simply install the 
> default app "logo" icon, regardless of it's style, to hicolor and 
> we're done.

Again, this is about what to do when an icon is missing.  Your use of
the word 'install' clearly indicates that you don't understand this.
There is no place that you can install an icon that doesn't exist.

> the default app icon is easily defined as "the icon which ships with
>  the application itself, as decided by the project responsible for 
> that application".

I'm not sure about that definition.  That would certainly apply for an
application's private icons (even if themeable) which would either be
unthemed or installed as HiColor.  But, again, this is about missing
icons not about where to install icons that do exist.

> so adobe would ship their icons for acroread and whatnot, kde would 
> install the default icons for kopete/kontact/yadda yadda into hicolor
>  and gnome would do similarly for evolution, etc. the adobe icons 
> would obviously follow the adobe corporate icon definitions; the kde 
> icons would be oxygen style; the gnome ones would be tango style; 
> etc...
> 
> themes can override these icons easily (we already have a means for 
> doing so in the form of the icon theme spec).
> 
> and then we have no issues. yes, it means that there would be 
> different styles of icons in the application menu unless the icon 
> theme in use provided icons for all apps installed. well, welcome to 
> the world of branding.
> 
> cut/copy/paste/print/folder/hardware/etc icons are a completely 
> different matter and not relevant to this discussion.
> 
>>> 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.
> 
> i think you are confusing app logo icons (which appear in the 
> application launcher menus as defined in the menu specification) with
>  other icons (actions, folders, hardware icons, etc). those icons 
> indeed should be installed elsewhere other than hicolor and there is 
> no issue there because each toolkit loads icons for the application; 
> there is no shared implementation (meaning our fallbacks can be 
> different, among other things)

And what happens if I choose a GNOME theme (but not the them called
"Gnome") for my KDE desktop?  Or, if I install a third party icon theme
such as Tango and choose it for both KDE and GTK apps.  Then it doesn't
matter that each toolkit uses its own icon loader (or if as some time in
the future there is a cross platform icon loader from the Philadelphia
project).  Actually, it makes it worse since you are quite correct that
the fallback can be different -- actually, if they are hard coded, they
will have to be different -- this is one of the issues.

> so there is no problem with collision

If two pieces of software try to install an icon with the same name in
the same icon theme, we have a collision.  Yes coordination can address
some of this, but not all of it.

> or incompleteness for 'native' icons inside applications.

There is simply no point in stating that incompleteness won't occur.  In
this limited case, you are probably correct that an app won't be missing
private icons.  But, all icons installed by apps are not private icons
and there are a lot of icon themes on KDELook.

> if apps are having a hard time getting all their icons together, 
> that's a problem in the icon loader implementation of their toolkit.
> 
Yes, that is true with KDE.

> there is no point in trying to solve that by modifying how icon 
> themes work; that too would require modifying each icon loader 
> implementation. so either way we'd end up modifying icon loaders, 
> only in your solution we'd have to modify all of them (even the ones 
> that are working just fine) and add greater complexity to them all 
> (the last thing we need, if you've ever looked at the code for icon 
> loaders)

Yes, I have looked at the code for icon loader.  I had to do so to fix a
bug in the KDE Icon Loader.  I have tried to propose only solutions that
wouldn't have to be implemented for an icon loader to work.  Don't
confuse being able to add this extra feature with having to do so.
> 
> the problem is the application menu, and the solution is simple. i'm 
> not sure why such a simple problem (application menu incompleteness) 
> with such an obvious solution (use a common dir for default app 
> icons) requires so much conversatio =)

This is not about the application menu.  It is about what to do when
icons are missing.  Yes, it is unlikely that an application wouldn't
have an icon for the menu.  But, it does happen.  Yes, there are minor
KDE apps that don't have menu icons.

Yes, we have a requirement that if an app has only one style for its
menu icon that it must install that as HiColor no matter what style it
is.  But, that doesn't prevent an application from not installing a menu
icon.

To sum up, this is all about what to do about missing icons in the
context of cross platform use of icon themes.  And, it is really about
the future after DeskTops and applications are using icons with names
that conform to the XDG Icon Naming spec.

I also note that I probably agree with much of what you said except that
I presume that there will always be some missing icons.  Your proposed
solution appears to be not to have missing icons.  This is simply not a
practical solution.

You protest that my ideas are too complex.  It is quite possible that
there are solutions to the problem that are not as complex.  I noticed
that you didn't propose any such solutions.  I would be happy to hear
about them.  But, why trouble me with the Ostrich Algorithm?

-- 
JRT