Created attachment 785343 [details] Missed icons in Evince Seems like the current version of kcm-gtk tunes just a GTK2 applications. To apply the oxygen theme for a GTK3 apps one shall execute instructions from oxygen-gtk3 README file. That isn't an expected behaviour, as for me. Related issue: https://bugzilla.redhat.com/show_bug.cgi?id=753535#c2 Not sure why it's marked as duplicate and closed. #769029 seems a bit different thing. Besides that, after enabling oxygen-gtk3 some icons are still missing, screenshot of Evince attached. Some icon package might be missed on my system.. SW: kdelibs-4.10.5-1.fc19.x86_64 kcm-gtk-0.5.3-12.fc19.x86_64 oxygen-gtk3-1.1.4-1.fc19.x86_64 oxygen-gtk2-1.3.4-1.fc19.x86_64 oxygen-gtk-1.2.0-4.fc19.noarch oxygen-icon-theme-4.10.5-1.fc19.noarch
Do you have xsettings-kde installed? You should. That is what applies the GTK+ theme setting to GTK+ 3 and also automatically applies the KDE icon theme setting to GTK+ 2 and 3 applications.
(In reply to Kevin Kofler from comment #1) It wasn't installed. "yum check" and "package-cleanup -q --problems" show no problems. Shall xsettings-kde package be linked with kcm-gtk as some type of dependency in this case? Anyway I've installed xsettings-kde and restarted X. xsettings-kde process is running but icons state in Evince and some other apps is same. Tried to switch GTK theme in kcm-gtk to another one and back to oxygen-gtk, but it changed nothing.
To be more specific, under "changed nothing" I mean that it didn't help to fix oxygen-gtk icons. Theme switching had an visible effect as itself.
> Shall xsettings-kde package be linked with kcm-gtk as some type of dependency > in this case? xsettings-kde is part of the @kde-desktop group which is expected to be the minimum package set to install if you want to use a KDE Plasma Workspace. > xsettings-kde process is running but icons state in Evince and some other apps > is same. What icon theme do you have set in KDE System Settings? Are you using the default Oxygen or something different? Icon themes are separate from GTK+ or Qt themes.
Oh, and also, do you have gnome-icon-theme installed? That's the fallback icon theme all GNOME applications fall back to when the icon is not available in the selected icon theme. (Well, to be precise, the applications don't automatically fall back to it, there's a GTK+ XSetting for the fallback theme which can and must be set by the desktop environment, but xsettings-kde sets it to gnome-icon-theme as gnome-settings-daemon does, because that's the only theme actually guaranteed to contain the icons.) It's possible that Evince is trying to use some icons which are not in Oxygen.
(In reply to Kevin Kofler from comment #4) > What icon theme do you have set in KDE System Settings? Are you using the > default Oxygen or something different? Icon themes are separate from GTK+ or > Qt themes. Both icons theme and widget style is Oxygen. KDE applications and some of GTK (firefox) seem to have no problems. Currently some icons are missed in Evince and pavucontrol (GTK3?). > do you have gnome-icon-theme installed? Yes, I have: gnome-icon-theme-3.8.3-1.fc19.noarch
I think this is the same GTK+ 3 icon loader bug with fallback themes as in bug #965365. That bug was "fixed" for Anaconda by forcing the Anaconda icon theme to always be the GNOME theme, which is of course a broken hack, not a fix. I told people so back on May 23, and again on May 30 when the "fix" was pushed through despite my explanations of why it's not the correct fix. As I clearly said back in May, bug #965365 should have been reassigned to and fixed in gtk3, not anaconda. The real bug is still not fixed (almost 3 months later), as evidenced from this report.
And to be clear, xsettings-kde does set "Net/FallbackIconTheme" to "gnome", so gtk3 is expected to actually fall back to that if it can't find the icon in the selected theme (which is "oxygen" by default).
Created attachment 785670 [details] evince on plasma, no missing icons(?) I cannot reproduce the problem described here.
Andrew, mind you, you'll need to restart your session after installing xsettings-kde and/or oxygen-gtk3 to take full effect. Is it still reproducible?
(In reply to Rex Dieter from comment #10) Yes, it was restarted and still reproducible, mentioned in comment #2 and #3. However I have another machine with same SW and it isn't reproducible there. xsettings-kde was present there initially. Evince has all the icons like your example shows. Pavucontrol still misses the "lock channels together" icon (placeholder looks same with my Evince screenshot), but this might be a separate case. Some another packages depending on gtk3 seem fine after a quick look ("good" machine): dia, inkscape, usbview. I'll try to compare package lists for both machines. First one was upgraded between releases several times (since F13?) using yum, so it might have a setup problem (the package DB is fine). In this case the subject issue can be closed, I think. As for the deps, I still would like to have xsettings-kde required for (kcm-gtk && oxygen-gtk3), but you decide.
Solved it with installation of gnome-icon-theme-symbolic.noarch Now Evince icons look a bit inconsistent since main toolbar uses symbolic gnome icons and the setting submenu uses oxygen icons, for example. However that isn't a problem for me. Package deps topic still remains as for me, and with the new point maybe—should Evince or xsettings-kde depend on the gnome-icon-theme-symbolic? Although now all issues are solved and this bug may be closed.
Thanks Andrew. I've added to kcm-gtk: Requires: xsettings-kde Given your findings, let's bounce this over to evince to consider adding a dep on gnome-icon-theme-symbolic too. A few other things already depend on it, $ sudo repoquery --whatrequires gnome-icon-theme-symbolic anaconda-0:19.30.13-1.fc19.x86_64 control-center-1:3.8.3-2.fc19.x86_64 epiphany-1:3.8.2-1.fc19.x86_64 gdm-1:3.8.3-2.fc19.x86_64 gnome-disk-utility-0:3.8.2-1.fc19.x86_64 gnome-media-0:3.4.0-5.fc19.x86_64 presence-0:0.4.8-6.fc19.x86_64
> Now Evince icons look a bit inconsistent since main toolbar uses symbolic gnome > icons and the setting submenu uses oxygen icons, for example. However that > isn't a problem for me. And that isn't anything we can do anything about, either. GNOME should be using a symbolic theme if they want symbolic icons (and allow other desktops to use their normal theme instead) rather than using non-fd.o icon names to force the monochromatic ugliness (which doesn't look like any normal application) on everyone.
*** This bug has been marked as a duplicate of bug 980751 ***