Icon theme spec & inheritance
Aaron J. Seigo
aseigo at kde.org
Sun Jun 3 11:30:51 PDT 2007
On Sunday 03 June 2007, James Richard Tyrer wrote:
> 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.
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
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
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
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
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xdg/attachments/20070603/ccb30617/attachment-0001.pgp
More information about the xdg