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)
pgp0bVCcWVbZX.pgp
Description: PGP signature
_______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
