I've made some additions to the Lila theme (http://lila-theme.uni.cc/). Basically, I added some of the icons that existed in the Rodent theme into the respective directories in the Lila tree. However, they are not used in the system menu, nor in the Settings Manager even though that's the icon theme I have selected.
this is going to require changing the McsPlugin struct, as the plugins each give xfce-mcs-manager a GdkPixbuf, not the name of an icon. to do this now, each and every plugin would have to be modified to watch for icon theme changes, and i don't think it's worth it. changing the struct now isn't a good idea; this will have to wait until 4.3. unfortunately, no one left padding in the struct for expansion, so i can't use a reserved member and fall back to the old behavior...
by the way... i looked at your icon set, and it's working for the menu, though maybe it wasn't perfect. i'm messing around with the icon theming code now, and i fixed a couple things. at any rate, there were no icons for the settings panels in your custom theme, so they won't get changed from the Rodent-styled icons.
Really... which icons does the Settings Manager use?
check out the $prefix/share/applications/xfce*settings.desktop files.
Ah, so there's an extra 4 there. So am I to change my theme's icons? Like I said, I just matched Rodent's. And I'm not sure which things you changed since looking at this. (Thanks for doing it, BTW.)
marking as enhancement, since it pretty much is, and i want to get it off my active list =/. andrew: not sure what you mean. you need to provide themed icons with the names in the .desktop files that have the look and feel of your theme, but are "for" the settings panels.
I meant that Rodent seemed to have a lot of xfce-* icons, while the .desktop files asked for xfce4-* ones. I added the latter to the theme I use (actually just symlinks to ones that already exist) and they worked quite well in the menus. One problem though, to get back to the original bug: most of the icons don't show up in the Settings Manager. The panel one does, oddly enough; but the rest of the icons are pulled from the default theme, even when the "proper" icon exists. I'm not sure if I missed something in your comments, Brian, but I can't see how the panel settings manager icon is any different than the rest....
(In reply to comment #7) > I meant that Rodent seemed to have a lot of xfce-* icons, while the .desktop > files asked for xfce4-* ones. I added the latter to the theme I use (actually > just symlinks to ones that already exist) and they worked quite well in the > menus. right, the icons for the settings panels _aren't_ included in Rodent. they're provided by the settings panels themselves, and get installed to the $prefix/share/icons/hicolor theme (hicolor is the default/fallback theme). the xfce-* icons in rodent are fallback icons for the different category icons that the panel uses for launchers. they have nothing to do with the settings manager. > One problem though, to get back to the original bug: most of the icons don't > show up in the Settings Manager. The panel one does, oddly enough; but the rest > of the icons are pulled from the default theme, even when the "proper" icon > exists. I'm not sure if I missed something in your comments, Brian, but I can't > see how the panel settings manager icon is any different than the rest.... ok, to be clear, are we talking about 1) the big dialog with a bunch of buttons that you get when you run 'xfce-setting-show' with no arguments, or 2) the individual settings panels that you get when you click on one of those buttons in the dialog in #1? the icons in #1 will not change when you change the icon theme, unless you restart xfce (well, unless you restart xfce-mcs-manager). if they're not changing even then, _and_ there are icons with the correct names in your new theme, _and_ the index.theme is set up properly to include the locations of those icons, then it's a bug. the icons in the colored frame headers in #2... i'm not sure how they're opened, as i didn't convert the settings panels to use themed icons. frankly, the icon theming in the settings manager is pretty broken, and needs to be redone for 4.4. i'm not surprised that it isn't working properly, but there may not be anything that can be done about it for 4.2. on a side note, are you using gtk 2.2 or 2.4? has it ever been the case that some icons in the settings manager are actually _missing_? that is, that there's no icon at all, and that the button just has text.
(In reply to comment #8) > right, the icons for the settings panels _aren't_ included in Rodent. they're > provided by the settings panels themselves, and get installed to the > $prefix/share/icons/hicolor theme (hicolor is the default/fallback theme). > > the xfce-* icons in rodent are fallback icons for the different category icons > that the panel uses for launchers. they have nothing to do with the settings > manager. OK, that I understood. :) Thanks for the clarification. > ok, to be clear, are we talking about 1) the big dialog with a bunch of buttons > that you get when you run 'xfce-setting-show' with no arguments, or 2) the > individual settings panels that you get when you click on one of those buttons > in the dialog in #1? #1. > the icons in #1 will not change when you change the icon theme, unless you > restart xfce (well, unless you restart xfce-mcs-manager). if they're not > changing even then, _and_ there are icons with the correct names in your new > theme, _and_ the index.theme is set up properly to include the locations of > those icons, then it's a bug. And what I'm saying is that I'm getting _just_ the "Xfce Panel" icon. All work in the menus, but only one works in the Xfce Settings Manager. Thusly, I conclude that I have them setup properly (since they all work for the menu icons) and that the rest are buggy. > on a side note, are you using gtk 2.2 or 2.4? has it ever been the case that > some icons in the settings manager are actually _missing_? that is, that > there's no icon at all, and that the button just has text. 2.4.9. No, I don't think I've ever seen that.
As I left it, the only icon that will change in the Settings Manager is the Panel. Even when I have themed the menu icons (referring to the names in the . desktop files in /usr/share/applications), the icons are not applied to the big buttons in the Settings Manager. Can I get confirmation on this?
i don't have more than one icon theme with the proper names to test this. i think you're the only one that does. the button icons aren't set up to be themed properly, this is known. fixing this requires changing every MCS plugin, and that's not really much of a priority now.
"the button icons aren't set up to be themed properly, this is known. fixing this requires changing every MCS plugin, and that's not really much of a priority now." OK, this is what I was confused about; thanks for the clarification.
I'd really like to see this issue fixed. Is there any Xfce or Gtk documentation that would be able to help pinpoint the issue? What type of changes are we looking at here? Should the plugins listen to some event in order to be able to update the icon? If the issue is easy enough, I'd be willing to help out and updating all the plugins. I'll need some help, however, since I am a virgin at Gtk hacking (well, except for some GTK# stuff)!
Okay, I did some research today. I found some good information here: http://www.advogato.org/person/jamesh/ Here's the run down for getting an icon in GTK (mostly copy & pasted): 1. Find the image file for an icon at size n using gnome_icon_theme_lookup_icon() or gtk_icon_theme_lookup_icon(). 2. Create a GdkPixbuf from the image file using gdk_pixbuf_new_from_file(). 3. Use the pixbuf as an nxn icon. The first problem with this is that gtk_icon_theme_lookup_icon() is not guaranteed to return an image at the desired size. This is quite obvious when you consider that you can pass in an arbitrary size to the lookup function, but the icon theme will only contain a finite number of sizes. However, if you ask for a common sized icon and the icon theme contains that size image, it might appear that the function will always return an image file of the requested size. The fix is to check the size of the loaded pixbuf and scale it if it is of the wrong dimensions. The second problem is to do with SVG image files. They can be rendered at arbitrary sizes, but gdk_pixbuf_new_from_file() doesn't tell the loader backend what size is actually wanted. This means that the SVG will be rendered at whatever size is listed in the file itself, which could be very large or very small. To avoid having to resize the SVG image after rendering it (which could be slow), you can use the gdk_pixbuf_new_from_file_at_size() routine (new in GTK 2.4) which passes the desired size to the backend so that ones like the SVG backend can render at an appropriate size. This function will return a pixbuf that fits into the bounding height/width you pass to it, and will perform scaling if the backend can't load the image at the requested size. If this sounds complicated, there is an easier way. You can just use gtk_icon_theme_load_icon(), which will lookup the image, and load it at the desired size all in one go. I guess there aren't many people using it because there wasn't an equivalent in the older GnomeIconTheme API. http://developer.gnome.org/doc/API/2.0/gtk/GtkIconTheme.html#gtk-icon-theme-load-icon For our refresh problem, couldn't we just grab our current XfceIconTheme on init of each plugin and assign a callback function to handle the "changed" event?
sorry, you did a bit of redundant research. i'm well aware of what needs to be done to fix this bug, but the changes were to large for 4.2, so i was waiting on the 4.3 development tree to fix this. you have the right idea, except for the fact that everything can (and should) be done via XfceIconTheme... which doesn't appear to have online docs at the moment (guess benny hasn't updated them in a while). XfceIconTheme guarantees an icon at the requested size (note that you are incorrect when you say that gtk_icon_theme_load() does as well - at least in gtk 2.4, it can return an icon of a size different than requested). the "changed" signal is indeed what you're looking for, but there's a deeper problem - the MCS plugins all have their icons embedded in the shared library itself, and load them using gdk_pixbuf_from_pixdata() (or maybe it's inline image data, not GdkPixdata, but that's the same idea). anyway, all that needs to be changed, and i haven't decided if i want to continue including a fallback icon in the shared library (probably not).
You are correct. There was a bug in GTK not always getting the correct size of an icon. However, the bug was fixed in October. Perhaps this fixes the gtk_icon_theme_load() not always scaling issue that you mentioned. Bug 154142: gtk_icon_theme_load_icon doesn't always scale http://bugzilla.gnome.org/show_bug.cgi?id=154142 I agree that inline images in the library isn't ideal. Is Rodent the default and fallback theme? If so, as long as that is installed there should be an image in the Rodent theme for the plugin. Therefore, if a user has selected a custom icon theme which does not contain the icon for the plugin then it should default to the one in the Rodent theme. That seems like a logical approach and it doesn't seem like a huge change, IMHO.
(In reply to comment #16) > I agree that inline images in the library isn't ideal. Is Rodent the default > and fallback theme? If so, as long as that is installed there should be an > image in the Rodent theme for the plugin. Therefore, if a user has selected a > custom icon theme which does not contain the icon for the plugin then it > should default to the one in the Rodent theme. nope, the icons are installed to hicolor/. rodent doesn't include them. at any rate, rodent isn't a default fallback; it's just a regular icon theme. > That seems like a logical approach and it doesn't seem like a huge change, > IMHO. perhaps, but that's not the way we're going to do it. it was too large a change for post-beta, which is around when this bug was filed. it'll wait until 4.3; it's a minor cosmetic issue at worst.
I just decided to look into this, and it's not looking good. Each MCS plugin provides a GdkPixbuf to the MCS manager on startup, so changing buttons on the fly is impossible without a pretty big change to the MCS manager and every plugin. I really have no interest in spending the time to make the required changes. It's probably better to wait until we write a new settings manager, but I'll assign it to the default address in case anyone wants to mess with this.
(In reply to comment #18) > I just decided to look into this, and it's not looking good. Each MCS plugin > provides a GdkPixbuf to the MCS manager on startup, so changing buttons on the > fly is impossible without a pretty big change to the MCS manager and every > plugin... I assume that this is fixed in the 4.4 release. If not, please reopen this bug...