GNOME Bugzilla – Bug 325546
[PATCH] GtkIconTheme should list "gnome" as the lowest fallback above "hicolor"
Last modified: 2006-01-11 06:30:55 UTC
In order to respect the icon theme spec, the lowest possible fallback should always be hicolor. In order for many of the applications that use GTK+ and GNOME to work though, the "gnome" icon theme needs to be listed in the tree, so that it may be used, without having it install much of the icon set into the hicolor theme tree. The attached patch implements this functionality.
Created attachment 56683 [details] [review] Patch to always look in the gnome icon theme, before hicolor
And this is documented in the icon theme spec, where?
Which part? GTK+ already respects the hicolor fallback. The problem is going to be gnome icon theme for applications. The icon theme spec doesn't say anything about the fallback tree, above hicolor. It only states that hicolor must be the root of the tree. The icon theme spec, was also designed around theming application icons, and not entire sets of icons across the desktop. It doesn't clarify what icons should be installed to hicolor, and what shouldn't be, either. However, with the Icon Naming Specification, installing non-application icons into hicolor is a bigger problem, as we don't want to set a precedent that action/mimetype/etc... icons go there, and certainly shouldn't be installed there by some other icon theme. If we do, it means that gnome and icon themes for other desktops, could be installing conflicting icons into hicolor. This would be bad for all the desktops involved. Falling back to "gnome" before "hicolor" is the best solution, as it allows us to retain control of the icons on our desktop, and to let applications easily require their presense, and still lets ISVs provide their application icons, through the hicolor theme.
If an icon theme wants to fall back to gnome, it can certainly do that, without any gtk patches...
Yes, of course icon themes can specify that they inherit from "gnome". Although, all of them don't, and probably shouldn't. However, this is not the problem. The problem is that if some of those icons are not available, applications will fail. I will be committing a change to gnome-icon-theme later today, that will fix it to no longer install icons in hicolor. GTK+ itself, also needs some of these icons, so it seems odd to me that it doesn't already do this. Although, I understand that it does, as gnome-icon-theme is broken, and it expects that brokenness to be valid.
You are not making yourself particularly clear here.
Not particularly clear how? GTK+ and GNOME both depend on icons that are only provided by "gnome-icon-theme" right? What should happen if those icons are not provided by a theme in use, that does not inherit from gnome? GTK+ needs to always look in "gnome" to find these icons, then, if they are not provided by other themes in use, no?
How does GTK+ depend on icons that are only provided by the "gnome" icon theme ? Until you broke hicolor by refusing to install icons there, I mean. Oh, and btw. you also broke the file chooser again by making the mime type icons "Fixed". They were changed to scalable for a reason...
ok, sorry. I'm having a not particularly good day... Anyway, hardcoding the 'gnome' icon theme in gtk is out of the question. What could be debated is a setting to specify one or more fallback icon themes.
The MIME type icons that show up in the filechooser are only provided by gnome-icon-theme. Having them installed to hicolor was broken in the first place. A theme should not be installing part of its icons to another theme. That is just asking for problems. As for the Fixed vs. Scalable, problem, I understand that some of the icons may be oversized. However, the problem is missing icons, not the type of the icon directories. Bitmap icons shouldn't be set as Scalable, as they are specifically not scalable. This will be fixed shortly when I go ravage through the icons and remove/rename/replace a bunch of them, so that the default theme can be more generic, and comply with the naming spec. As soon as Alex L. gets back from vacation early next week, we should be able to work toward improving generic icons for MIME types all over the place, as well. I don't see why hardcoding a particular fallback for the desktop is out of the question. But, if a setting is preferred, I'm sure we can do that. How should that be implemented? As a GtkSetting on the display?
How about adding scaled-down versions of the bitmaps then, until we can get properly drawn small versions, or real scalable versions ? Its always nice to avoid regressions, when it is easy to do so... Hardcoding "gnome" inside GTK+ is inappropriate, since GTK+ is used in other environments, like Hildon or ROX, just to name 2. Do you propose everybody who uses GTK+ should be required to install gnome-icon-them ?
Here is a patch which adds a gtk-fallback-icon-theme setting, and backs it by the Net/FallbackIconTheme setting. Owen, does this look good to you ?
Created attachment 57105 [details] [review] fallback icon theme support Note that we will probably have to put this in the stable branch as well, considering the changes happening in gnome-icon-theme. Otherwise gnome 2.14 will be rather icon-deprived...
Well, there is serious conceptual breakage here in terms of the icon theme spec. But considering that it seems unlikely that GNOME (or KDE for that matter) is going to be reasonable and sort that out, this seems like a decent way of handling this. It should allow fallback to KDE-default-icon-theme-of-the-week within KDE as well. (If KDE supported XSETTINGS, anyways.)
The patch looks ok to me. I'll fix gnome-settings-daemon to handle the setting as well, as soon as this is in the branch. Owen: How exactly is there serious conceptual breakage in terms of the icon theme spec? Please point to where any of this is breaking the spec.
Ok, I'll probably do a stable GTK+ release with this patch later this week
2006-01-11 Matthias Clasen <mclasen@redhat.com> Allow falling back to another icon theme before hicolor. (#325546, Rodney Dawes) * gtk/gtksettings.c: Add a gtk-fallback-icon-theme setting. * gdk/x11/gdkevents-x11.c: Map it to the XSetting Net/FallbackIconTheme. * gtk/gtkicontheme.c: Consult the fallback icon theme before looking in hicolor.