Icon theme spec & inheritance

Sun Jun 3 11:30:51 PDT 2007

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. 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. 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, and there is no reason, rhyme or purpose to 
insisting on a given style for application logo icons.

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

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

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 define 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) 
so there is no problem with collision or incompleteness for 'native' icons 
inside applications.

if apps are having a hard time getting all their icons together, that's a 
problem in the icon loader implementation of their toolkit. 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)

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 =)

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xdg/attachments/20070603/ccb30617/attachment-0001.pgp 