! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
icons are not reapplied to settings manager icon buttons on theme change
Status:
RESOLVED: FIXED
Severity:
enhancement
Product:
Xfce-mcs
Component:
General

Comments

Description Andrew Conkling 2004-11-04 21:21:38 CET
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.
Comment 1 Brian J. Tarricone (not reading bugmail) 2004-11-05 06:16:11 CET
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...
Comment 2 Brian J. Tarricone (not reading bugmail) 2004-11-06 07:55:08 CET
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.
Comment 3 Andrew Conkling 2004-11-06 18:06:53 CET
Really... which icons does the Settings Manager use?
Comment 4 Brian J. Tarricone (not reading bugmail) 2004-11-07 01:09:05 CET
check out the $prefix/share/applications/xfce*settings.desktop files.
Comment 5 Andrew Conkling 2004-11-07 03:47:53 CET
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.)
Comment 6 Brian J. Tarricone (not reading bugmail) 2004-11-15 20:28:57 CET
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.
Comment 7 Andrew Conkling 2004-11-16 08:27:49 CET
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....
Comment 8 Brian J. Tarricone (not reading bugmail) 2004-11-16 12:08:40 CET
(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.
Comment 9 Andrew Conkling 2004-11-16 17:30:58 CET
(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.
Comment 10 Andrew Conkling 2004-12-11 19:55:58 CET
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?
Comment 11 Brian J. Tarricone (not reading bugmail) 2004-12-11 20:03:58 CET
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.
Comment 12 Andrew Conkling 2004-12-11 20:08:12 CET
"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.
Comment 13 Dave Wolovich 2004-12-31 16:47:45 CET
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)!
Comment 14 Dave Wolovich 2004-12-31 19:58:07 CET
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?  
Comment 15 Brian J. Tarricone (not reading bugmail) 2004-12-31 22:47:31 CET
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).
Comment 16 Dave Wolovich 2005-01-01 03:10:39 CET
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.
Comment 17 Brian J. Tarricone (not reading bugmail) 2005-01-01 12:07:44 CET
(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.
Comment 18 Brian J. Tarricone (not reading bugmail) 2005-10-31 08:26:27 CET
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.
Comment 19 Harold Aling 2007-02-14 23:02:15 CET
(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...

Bug #464

Reported by:
Andrew Conkling
Reported on: 2004-11-04
Last modified on: 2009-07-15

People

Assignee:
Xfce Bug Triage
CC List:
0 users

Version

Attachments

Additional information