Version: unspecified OS: Linux After commit 979064331f7d6fe7841a3de789ae232fac68782f icon themes no longer work correctly. For some people, their icon themes don't apply, for others some icons are no longer located, resulting in no icon or unknown icon in places where correct ones used to be in 1.1.2. The most strange thing in this is that if i comment everything from that commit except of gtk_icon_theme_get_search_path() call, the problem still remains. I suspect a GTK bug, but am not sure. Reproducible: Always Steps to Reproduce: Start e.g. xfce4-panel, see lack of icons in its xfce-menu. Or start pidgin, see unknown icon in system tray instead of pidgin one. Or start chromium, press Ctrl+S, and see wrong icon theme being used for some elements. Expected Results: Icon themes should work correctly.
Confirmed. Same here, after the upgrade to oxygen-gtk 1.1.3
@Ruslan, then maybe you can try do it the other way around: not call gtk_icon_theme_get_search_path() and prepend all kde path without check (which is what the call above is for). Does that fix the issue ? Also, did you try without the gfree call ? (maybe this effectivly clears the previous seach path. Not sure.) Anyway, 1/ sorry for the trouble. Its quite serious. 2/ feel free to revert the commit from the 1.1 branch until it gets fixed (and keep it in master 3/ I'll give it a shot myself as soon as I get some spare time, Hugo
> Also, did you try without the gfree call ? (maybe this effectivly clears the > previous seach path. Not sure.) This was one of the first things I tried, but it doesn't change anything. I've even tried to just duplicate the first item in search path list via prepend_search_path(), to check if it changes anything - and it does break things in the same way. So, basically, every GTK call with gtk_icon_theme_{get,prepend}* appears to break things. This really looks like GTK bug.
Ruslan, thanks for the info. I'll try to debug from inside gtk (tomorrow). What surprises me is that the DEBUG call in the same chunk of code shows the correct icon path list. Anyway will keep you posted.
sadly enough, Can't reproduce. My pidgin looks good (under kde) whether I use oxygen (the default) or Faenza icon theme (installed locally, for my user account only, under $HOME/.kde4/share/icons. What do I miss if I want to reproduce the problem ? Also, my gtk version is: 2.24.5 What are people experiencing the bug using ? And can someone (Ruslan) give a shot to the above version, if different from yours). Thx, Hugo
@Andrea, could you get the oxygen-gtk sources (git clone -b 1.1 git://anongit.kde.org/oxygen-gtk), compile in debug mode (cmake -DOXYGEN_DEBUG=1) and post here the output when you run an application which exhibits the bug ? I'd like to check the printouts, notably icon search path. Thx, hugo
Sure, here it's: http://paste.kde.org/123793/
@Andrea Thanks for the pastebin. From the following path: Oxygen::QtSettings::loadKdeIcons - icon theme search path: /home/bash/.kde4/share/icons Oxygen::QtSettings::loadKdeIcons - icon theme search path: /home/bash/.icons Oxygen::QtSettings::loadKdeIcons - icon theme search path: /home/bash/.local/share/icons Oxygen::QtSettings::loadKdeIcons - icon theme search path: /usr/share/icons Oxygen::QtSettings::loadKdeIcons - icon theme search path: /usr/local/share/icons Oxygen::QtSettings::loadKdeIcons - icon theme search path: /usr/share/pixmaps Oxygen::QtSettings::loadKdeIcons - icon theme search path: /usr/local/share/pixmaps Can you tell me which one contains the theme named "ALLGREY" on your system ? (if any) (I am confused, from the "Oxygen::GtkIcons::generate - adding path:" lines below, that there is no line there either that contains the ALLGREY theme, and that only Gnome is found and used ...) Thanks for helping me tackling down.
Note, still in the backtrace, pixmap_path "/usr/share/icons/gnome" This also is bad. Apparently your icon theme is not in any path that oxygen looks for (neither internally or via gtk). :(
Hi Hugo, the icon theme is installed in ~/.kde4/share/icons/ by KDE, I symlinked the folder in ~/.icons. Note, the folder is named ALLGREY UniQ Edition, but KDE calls the theme ALLGREY- UniQ Edition. In effect in the index.theme there is this line: Name=ALLGREY- UniQ Edition I tried both names in my gtkrc-2.0, but only the oxygen-gtk downgrade fixed it.
ok. With ALLGREY theme I can reproduce the issue. Good news. I can probably fix :)
Git commit 5e5c82f3e2e01b3a5458dd39e36cd13a70486e97 by Hugo Pereira Da Costa. Committed on 22/09/2011 at 13:49. Pushed by hpereiradacosta into branch '1.1'. Allow loading of icon themes that contain blank space in names. CCBUG: 282264 M +1 -1 src/oxygenqtsettings.cpp http://commits.kde.org/oxygen-gtk/5e5c82f3e2e01b3a5458dd39e36cd13a70486e97
To me, comment #12 fixes it for the ALLGREY theme. Andrea, if you get a chance to compile oxygen-gtk from sources (and I can provide instructions), could you confirm ? Cheers, Hugo
Confirmed! Icons are fine now!! Symlinks in ~/.icons are no more needed. Thank you Hugo!!
Well, as for the the problem with prepend_search_path(), it appears that the problem reproduces with a single gtk_icon_theme_get_default() call by oxygen-gtk and nothing else. This function in fact _creates!_ a new icon theme, fills it, and stops all _real_defaults_ from working. So, now I even don't know whose fault this all is. It's either GTK which works inconsistently (defaults appear to not be applied by default), or my icons installation is messed up. It could also be that both problems are present :)
I confirm this bug present as I reported in: https://bugs.kde.org/show_bug.cgi?id=330136 This report entirely describes what I have.
@JoseLuisT I dont think this has anything to do with the bug your report, and this one was fixed anyway. re-closing.
Thank you for the bug report. As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists. If this bug is no longer persisting or relevant please change the status to resolved.
I don't reproduce this anymore.