Bug 80839

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. ***