Discovered this one when upgrading from 4.9.5 to 4.10.1 in Fedora 17. The problem I have is that now in several menus I have an Oxygen "applications-other.png" icon ovverridden by XFCE's exo icon. $ rpm -q exo exo-0.6.2-4.fc17.x86_64 $ rpm -ql exo | grep applications-other /usr/share/icons/hicolor/48x48/apps/applications-other.png $ rpm -q oxygen-icon-theme oxygen-icon-theme-4.10.1-1.fc17.noarch $ rpm -ql oxygen-icon-theme | grep applications-other /usr/share/icons/oxygen/128x128/categories/applications-other.png /usr/share/icons/oxygen/16x16/categories/applications-other.png /usr/share/icons/oxygen/22x22/categories/applications-other.png /usr/share/icons/oxygen/256x256/categories/applications-other.png /usr/share/icons/oxygen/32x32/categories/applications-other.png /usr/share/icons/oxygen/48x48/categories/applications-other.png /usr/share/icons/oxygen/64x64/categories/applications-other.png Take a look at this image to see what happens: http://imgur.com/pVmoPk8 Same goes for the "Software management" icon in "System settings" which has the same menu. This is a discussion about the issue i had in #fedora-kde. Users are reporting the problem also in Arch. As rdieter says: "default is to use oxygen icons, it's only supposed to use fallback (like hicolor) if a native oxygen one cannot be found", so the fallback mechanism should be checked. [17:06] * rdieter searches for where the displayed icon is coming from [17:06] <rdieter> ah! [17:07] * panda84kde stops typing in bugs.kde.org [17:07] <rdieter> it's coming from hicolor icon provided by 'exo' package [17:07] <rdieter> panda84kde: do you happen to have exo installed too? [17:07] <rdieter> odd though, the oxygen icon *should* have precedence over hicolor [17:08] * panda84kde "rpm -q"ing [17:08] <panda84kde> I do. exo-0.6.2-4.fc17.x86_64 [17:08] <rdieter> so, we now have a icon theme priority bug on our hands [17:09] <panda84kde> There it is: /usr/share/icons/hicolor/48x48/apps/applications-other.png [17:09] * panda84kde turns to bz.redhat [17:09] <rdieter> still may be an upstream issue [17:09] * panda84kde holds on :) [17:10] <rdieter> default is to use oxygen icons, it's only supposed to use fallback (like hicolor) if a native oxygen one cannot be found [17:11] <rdieter> panda84kde: go ahead @ upstream [17:12] <panda84kde> ok. brb [17:17] --> ninan_ è entrato nel canale (~ninan@tmo-097-161.customers.d1-online.com). [17:20] <mkyral> panda84kde: i'm observing weird application-other icon in KDE 4.10 on several arch[linux|bang] installations Reproducible: Always Steps to Reproduce: On Fedora 17/18 with KDE install the "exo" package (yum install exo). Actual Results: Exo icon gets displayed. Expected Results: Select Oxygen icon first rather than looking to other files in other packages.
Confirming. I observed this issue on several Archlinux installations (not sure about exo, Arch may have the icon in other package) and on Fedora 18 (with exo installed) after update to 4.10.
confirmed too
Probably a regression caused by: https://projects.kde.org/projects/kde/kdelibs/repository/revisions/613c951a1157df0d8a907a155a5eaa706816d5f9
(In reply to comment #3) > Probably a regression caused by: > https://projects.kde.org/projects/kde/kdelibs/repository/revisions/ > 613c951a1157df0d8a907a155a5eaa706816d5f9 CCing the author then.
The problem is that someone installed an icon in apps/ and then expected it to be overridden. See: http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html On the Applications context in apps/: "Icons that describe what an application is, for use in the Programs menu, window decorations, and the task list. These may or may not be generic depending on the application and its purpose. Applications which are to be considered part of the base desktop, such as the calculator or terminal, should use the generic icons specified in this specification, while more advanced applications such as web browsers and office applications should use branded icons which still give the user an idea of what function the application provides." And from the documentation on resolving via fallbacks: "The “Applications” context should not use this method of falling back to more generic icons. An application must either use a generic application icon name provided by this specification, or install an icon named the same as the executable for running the application. A generic desktop application included with the desktop suite, such as the calculator or terminal application, should use the generic names provided by this specification, as described above in the “Applications” context description." I'm not a huge fan of that specification and think it could have been done a lot better, but that's an academic discussion since this is what is in use. When an icon is requested by kdelibs, it only knows the name of the icon being requested. It has not other information to go by; in theory we could require than any time an icon is being requested that will be used to represent an application that some different call is made (e.g. by adding some Context enum somewhere). That would also be fragile as it would require patching every use in any place that uses such icons .. meh. Anyways, fix the installation and don't pollute the apps/ directory. :)
Ugh, that is a bit weird. learn something new every day, thanks. off to file bugs elsewhere :) (downstream at least, https://bugzilla.redhat.com/show_bug.cgi?id=951557 )
> I'm not a huge fan of that specification and think it could have been done a lot better, > but that's an academic discussion since this is what is in use. The specification is what is purely academic. What is in use is the icon in hicolor/*/apps which should NOT be preferred to the Oxygen one. Your change breaks things. It needs to be reverted.