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