| Summary: | Icon precendence error/regression: hicolor icons loaded before native oxygen | ||
|---|---|---|---|
| Product: | [Unmaintained] kdelibs | Reporter: | Diego <diego.ml> |
| Component: | kdeui | Assignee: | kdelibs bugs <kdelibs-bugs> |
| Status: | RESOLVED UNMAINTAINED | ||
| Severity: | normal | CC: | adaptee, aseigo, cfeck, kevin.kofler, rdieter, sine.nomine, yaohan.chen |
| Priority: | NOR | ||
| Version: | 4.10.1 | ||
| Target Milestone: | --- | ||
| Platform: | Fedora RPMs | ||
| OS: | Linux | ||
| URL: | http://imgur.com/pVmoPk8 | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Diego
2013-03-21 16:27:45 UTC
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.
Hi, kdelibs (version 4 and earlier) is no longer maintained since a few years. KDE Frameworks 5 or 6 might already have resolved this bug. If not, please re-open against the matching framework if feasible or against the application that shows the issue. We then can still dispatch it to the right Bugzilla product or component. Greetings Christoph Cullmann |