Red Hat Bugzilla – Bug 964019
Ugly icons when running from KDE live images
Last modified: 2013-05-24 15:16:07 EDT
I've been trying to pin this one down, but it's slippery. The symptom's obvious enough, though. When you run anaconda from a KDE live image, it uses really ugly icons in various places, for no apparent reason. Easiest to see this on the Installation Destination spoke: just boot a KDE live (F18, F19, doesn't really matter) and go there. A very low resolution disk icon, massively scaled up, is used for all disks (at least all disks I have) on that screen. I think I've seen ugly icons in other places in other KDE install tests, but I can't find any right now. Both the 'oxygen' and 'gnome' icon themes are present in the KDE live, and they both have fairly nice, high-resolution drive-harddisk icons, so it's not at all obvious why. (From the source, it's clear the icon asked for is 'drive-harddisk'). An interesting wrinkle: if you call 'anaconda' directly from a console in the KDE live environment, instead of running 'liveinst', much better-looking icons are used. So it looks like, somehow, the environment 'liveinst' sets up breaks access to or loading of the proper icons? I've looked and looked, but I cannot figure where the horrible icons that are actually used come from. If I could it might help pin down what the problem is here, but I just couldn't. Logs don't seem to have anything relevant. ~/.xsession-errors logs a few "(anaconda:1708): Gtk-CRITICAL **:gtk_icon_info_load_icon: assertion `icon_info != NULL' failed" lines, but I'm not sure if they relate to this at all.
Created attachment 750804 [details] ugly icon in question
The offending icon seems to be the "stock icon" built directly into GTK+: http://python-gtk-3-tutorial.readthedocs.org/en/latest/stock.html#Gtk.STOCK_HARDDISK I guess the Gtk-CRITICAL lines are indeed related and we end up with the builtin fallback in GTK+ because it fails to load the themed version.
You were right, guys: clumens just nailed a fix for 965365, and it does indeed fix this too :) So we can mark this as a dupe of that, or just ask clumens to mark the patch as fixing both bugs, whatever.
eh, let's just call it a dupe. it basically is. *** This bug has been marked as a duplicate of bug 965365 ***
Uhm, the thing is, it shouldn't be necessary to set that, xsettings-kde already sets the fallback icon theme. :-/ I think this is a GTK+ bug, really. I guess this bug also affects other gtk3 (and maybe gtk2) apps.
yeah, there probably is an underlying bug there, but this change at least masks it, and is a correct change in terms of what anaconda really wants. of course, the underlying bug could cause other problems, I guess, but I filed this bug on the specific symptom, and that'll go away now...
No, this is not what Anaconda really wants. Setting the icon theme globally affects ALL icons, e.g. the icons on dialog buttons. (Yes, those icons are enabled by default under KDE, even for GTK+ apps thanks to xsettings-kde.) Changing the icon theme globally for all of Anaconda WILL make it look poorly integrated.
well, first thing we tried was explicitly adding the GNOME icon path to the search path, but that didn't work, so there don't seem to be a lot of options for fixing the MATE case, except the long-term plan of having anaconda carry its own icons.
This is a GTK+ issue, it needs to actually honor the fallback theme. This needs to be fixed in GTK+, it cannot be fixed in Anaconda.