Version: (using KDE KDE 3.2.2) Installed from: Debian testing/unstable Packages OS: Linux I get this console-message repeatedly from all kinds of kde-programs. Konqueror is one of them. I get 100+ lines of these warnings from Konqueror. Reproduce by starting Konqueror from a terminal.
Even if this should turn out to be a Debian-bug, I think the programs should do something more useful than output lots and lots of these warnings.
Confirmed 06 may 2004 kde@lentus.sk I have the same after change (Debian testing) from 3.1.5 to 3.2.1. Also I have this in .Xsession-errors
yes, this is annoying. as a workaround, you can turn off the warning by running "kdebugdialog --fullmode". Look for debug area 264, and change the combobox for the warning to "None"
More info is here - maybe its Debian bugs. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=241283 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=245470 AT
It's not limited to just Debian, seeing as how I use Gentoo.
AFAIK those warnings happen because of errors in the index.theme files. There were some cvs commits lately that should fix some of the warnings: http://lists.kde.org/?l=kde-cvs&m=108419230104329&w=2 http://lists.kde.org/?l=kde-cvs&m=108110138010123&w=2
On gentoo, the package "x11-themes/hicolor-icon-theme" is responsible for this. This package is not a dep of kde, so it can be unmerged. It is a dependancy of gnome and gnome apps however. Any chance of making KIconLoader ignore the "stock" options in index.theme?
I emailed Alexander Larrson who made the default hicolor icon theme about this a while ago, and he said that he added the stock directories for because gnome needed them. So I think that KDE should handle them as well. As a starter to get rid of these ugly error messages, why not make stock a valid context. An initial piece of code would be added around line 514 in kicontheme.cpp else if (tmp == "Stock") mContext = KIcon::Stock; then the new mContext would have to be dealt with properly I suppose. mContext isn't used anywhere else in that file except to return its value, so somebody more familiar with the code will have to know how to deal with a new mContext. Mark As a longer term solution, the KDE and gnome folks should work together on the icon theme specs. Mark
This is not only a problem of the hicolor-icon-theme: I have the same warnings in Gentoo with the packages gnome-themes, gnome-themes-extra and gnome-icon-theme. These packages have, as well, icon themes.
CVS commit by waba: kdWarning -> kdDebug CCMAIL: 80839@bugs.kde.org M +2 -2 kicontheme.cpp 1.63 --- kdelibs/kdecore/kicontheme.cpp #1.62:1.63 @@ -168,5 +168,5 @@ KIconTheme::KIconTheme(const QString& na if (!dir->isValid()) { - kdWarning(264) << "Icon directory " << *itDir << " group " << *it << " not valid.\n"; + kdDebug(264) << "Icon directory " << *itDir << " group " << *it << " not valid.\n"; delete dir; }
It unfortunately looks like KDE things it owns /usr/share/icons. That is: If you remove all your Gnome icons things work fine. Obviously, that is terrible programming and needless logging: since the icon in question is _found_. But, after all, it is just a warning and has no impact on functionality. Infact, when I installed I *did* have corrupt icons (no one's fault) and KDE simply opens the applications with blank ones in place.
I use Gentoo and have had this problem. I unmerged gnome-icon-theme and it went away. It seems to still be a bug, of course, but I'm also not sure why I had that theme installed in the first place - I didn't want it and I don't remember telling anthing to install it.
Using kdevelop and a simple C++ hello world program really annoys me, because it takes 15 seconds just to print all those stupid icon warnings in the kdevelop console, since it is using konsole to show the output of the compiled program.
I had the same problem, which I "fixed" by changing all lines Context=Emblems or Context=Stock into, say, Context=Applications. This was in files index.theme in directories (debian) /usr/share/icons/gnome and usr/share/icons/hicolor so this is really a bug "kde -- gnome" as far as I understand
I haven't seen this bug for a while. Are there any objections if I just resolve this?
Yay! Seems like this isn't a problem anymore. :)
*** Bug 92761 has been marked as a duplicate of this bug. ***