Description of problem:
The Echo icon theme fails to display a number of icons on the KDE desktop.
This can be avoided by having the theme inherit crystalsvg (or the Oxygen icon
theme in the future) by adding crystalsvg to the list of inheritances:
in the same manner as the Tango icon theme.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install Echo: yum --enablerepo=development install echo-icon-theme
2. Login to a KDE session and select the Echo theme using the KDE Control
Many icons are represented with the default 'blank sheet' icon.
Echo should inherit the default icon theme for the selected desktop
environment. Under GNOME, it's the Gnome icon theme. Under KDE, it's the
Crystal (crystalsvg) icon theme.
Disclaimer - I did the initial work to allow the Tango icon theme to work as
well as possible with KDE.
I don't think that is right in general. I admit that we currently do inherit
clearlooks and gnome in Echo. But if every icon theme inherits every other just
because the other may have a few more icons, we end up with a totally
unmaintainable mess. What should happen instead is that there needs to be a
way to specify a fallback icon theme that is consulted as a last fallback before
hicolor. In fact, GKT+ already supports this.
Is gtk's "last fallback" a global or per-theme thing (or either)?
The Gnome (gnome) icon theme is the default theme on GNOME. The Crystal
(crystalsvg) is the default icon theme on KDE. Neither should inherit
anything, and anything 'below' them (i.e. Echo or Tango) should ideally
inherit both. As I understand it, no icon theme should inherit hicolor
explicitly as hicolor is intended to hold app icons (I realize crystalsvg
inherits hicolor wrongly, but that's historical and upstream's choice). I'm
not advocating 'every icon theme inherits every other' at all. I'm suggesting:
Your icon.theme is obviously derived from Tango's, so I'm not sure why
crystalsvg was removed and Clearlooks added to begin with.
Matthias, this notion of "last fallback" makes a whole lot of good sense. I'll
see who I can poke (or do it myself if I find the time) to get this
notion/feature into kde.
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'.
Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.
Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:
The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Not an echo problem, CLOSING->NOTABUG.
If anything, kde will have to come up with something akin to gtk's last-fallback.