Jonathan Riddell wrote: > On Sun, May 14, 2006 at 12:05:38PM -0700, James Richard Tyrer wrote: >> The clear message is: "NO HELP WANTED". If there is no useful >> discussion, that is the way I am going to take this and simply stop >> making icons. > > If you want to help make new kdeclassic icons put them in kdeclassic. > > > > I am not talking about making "new kdeclassic icon", I am talking about making NEW icons. Icon such as: tab_remove_other.png view_fit_height.png view_fit_width.png view_fit_window.png which didn't exist before I made them. And, I am not making KDEClassic icons for these *new* icons, I am making generic HiColor icons. >> The icon theme support remains a mess which I am willing to help >> straighten out. The attitude appears to be that nobody cares if >> icon themes don't work correctly since there is no problem as long >> as you use the Default (CrystalSVG). If that is the case, why not >> simply delete all other icon themes since they don't work >> correctly. I have a major kludge installed on my system as a work >> around in order to get HiColor/KDEClassic to work correctly. > > You are mixing hicolour and kdeclassic again. Not sure what you mean. I use my icon them on my system (USR_HiColor) and if an icon is missing I want fall back to HiColor,KDEClassic if they exist. I do NOT want CrystalSVG to show up as the fall back unless it is the only icon available. > Icon themes work fine, I presume that you mean except for *the* bug which means that they don't work correctly. If you use a theme other than CrystalSVG, you get CrystalSVG icons if the needed *size* of the icon is missing. This is a serious bug and a violation of the spec. Denial does not make bugs go away. :-) > if there are missing icons in a theme such as kdeclassic feel free to > fill them in. My concern is not filling in the missing icons in KDEClassic. I am willing to do that. My concern is what happens with *new* icons that are missing in other icon themes. This is why we have a fall back icon theme. >> Basically, what JR has said is the KDE will NOT support the HiColor >> icon theme. > > I never said that, i said we won't ship icons in hicolour because > that is incorect (hicolour being for third party apps). Then why does GNOME support HiColor and ship a HiColor theme. Supporting HiColor means having a HiColor theme -- shipping a HiColor theme like GNOME does. >> Was it up to him to make that decision? Yes, there are some issues >> that need to be considered, but GNOME supports HiColor and >> FreeDesktop.org standards require it. > > Our support for hicolour is exactly the same as Gnome's support for > it. Have you used GNOME lately? If so, you would know that what you say is not correct. > We both ship with hidden=true in the file This question is not about that. > so you can not select hicolour as your theme Very strange! On my GNOME installation, I *can* select HiColor as the icon theme. Apparently, GNOME simply ignores the "Hidden=true" in the "index.theme" file. > because it is not an icon theme but is a fallback namespace for use > by third party applications. It is there where you are wrong. The spec refers to HiColor as a theme, but that isn't the question. If HiColor is only a fall back icon theme, then it needs to be used as such. It needs to be supported and it needs to have generic icons in it. > You can find the definitive index.theme file for hicolour in > freedesktop.org's CVS, and you'll find it also has Hidden=true in it. > > We are not discussing that issue here. I accepted Frans Englich's suggestion on that (having a wrapper theme for using HiColor) except that it doesn't work because of *the* bug in the KDE icon search code. I have issues with the spec, but there is no point in discussing them first. >> I have made new icons for KDE Standard Actions and Konqueror >> functions. We need to have HiColor icons for these since KDEArtWork >> installs several icons themes that don't have them. And there are >> many other icon themes available on KDE-Look that don't have them >> yet. Not having them violates the intent of the spec and causes >> problems for anyone that doesn't use CrystalSVG. > > Then fill in the gaps in those themes, I am not going to make icons for every icon theme that exists to avoid installing new generic icons in HiColor so that they can be used as a fall back. > don't clutter up the hicolour namespace. I am (or was) using the HiColor "name space" (icon theme) as the spec states it is to be used, as a fall back icon theme (yes the spec says "icon theme"). For it to be used as a fall back icon theme, it needs to have icons in it. You appear to have ignored my point which is that if you are using an icon theme other than CrystalSVG or KDEClassic and you need the icon (for example): "view_fit_width" what should happen? Should you get the: "unknown" icon, or should you get the HiColor icon? Isn't that what the fall back theme is supposed to be used for: fall back? If the generic HiColor icon is installed in KDEClassic and HiColor doesn't inherit KDEClassic, then what happens -- what should happen? Also note that there are two possible solutions here. If HiColor inherits KDEClassic, then in many cases the new icons could be installed as KDEClassic although I really don't see what is accomplished by installing the new generic icons as KDEClassic rather than HiColor. If KDEClassic is a dead and unmaintained theme, then the only changes made to it should be to add missing sizes. -- JRT