Version: (using 4.00.80 (KDE 4.0.80 >= (KDE 4.1 Beta1), Debian packages) Compiler: cc OS: Linux (i686) release 2.6.24-1-686 The icons of KDE 3 applications do not show up in kickoff, only a white icon with a question mark in it.
Do other non KDE icons show (like GTK ones)? What Debian packages are those exactly? Did you try a new user? Thanks in advance for investigate more by answering these questions!
I tried a new user, and for both my own account and the new user account the following programs do not have their own icons: smb4k (0.9.4-1) sweeper (4:4.0.80-1) ktimetracker (4:4.0.80-1) kbibtex (0.2.1-1) xgnokii (0.6.25.dfsg-1) knetworkmanager (1:0.2.2-1) lynx (2.8.6-2) When I switch from the Oxygen to the Crystal SGV icon theme, smb4k, sweeper, kbibtex and knetworkmanager have their own icon again. GTK apps, like iceweasel and the GIMP, have their correct icons with both the Oxygen and Crystal icon themes.
imo, looks like bugs in those respective programs to either provide only crystalsvg icons and/or not provide their own fallback (hicolor) icons. Not much kde4 (or kickoff) can do about that.
Or... possibly those apps are using a perfectly legal "standard" icons which oxygen is currently missing. A.M.P., please identify the icons in use by those apps so a determination can be made who's at fault for the icon problems for each app. (look in each app's .desktop file and look for Icon=... ).
smb4k Icon=smb4k Location of the all smb4k icons /usr/share/icons/crystalsvg/16x16/apps/smb4k.png /usr/share/icons/crystalsvg/32x32/apps/smb4k.png /usr/share/icons/crystalsvg/48x48/apps/smb4k.png /usr/share/icons/crystalsvg/64x64/apps/smb4k.png sweeper Icon=trashcan_empty /usr/share/icons/crystalsvg/128x128/filesystems/trashcan_empty.png /usr/share/icons/crystalsvg/16x16/filesystems/trashcan_empty.png /usr/share/icons/crystalsvg/22x22/filesystems/trashcan_empty.png /usr/share/icons/crystalsvg/32x32/filesystems/trashcan_empty.png /usr/share/icons/crystalsvg/48x48/filesystems/trashcan_empty.png /usr/share/icons/crystalsvg/64x64/filesystems/trashcan_empty.png /usr/share/icons/crystalsvg/scalable/filesystems/trashcan_empty.svgz ktimetracker Icon=karm No icons named karm kbibtex Icon=kbibtex /usr/share/icons/crystalsvg/128x128/apps/kbibtex.png /usr/share/icons/crystalsvg/16x16/apps/kbibtex.png /usr/share/icons/crystalsvg/22x22/apps/kbibtex.png /usr/share/icons/crystalsvg/32x32/apps/kbibtex.png /usr/share/icons/crystalsvg/48x48/apps/kbibtex.png /usr/share/icons/crystalsvg/64x64/apps/kbibtex.png xgnokii Icon=cellphone No icons named cellphone knetworkmanager Icon=knetworkmanager /usr/share/icons/crystalsvg/16x16/apps/knetworkmanager.png /usr/share/icons/crystalsvg/32x32/apps/knetworkmanager.png /usr/share/icons/crystalsvg/48x48/apps/knetworkmanager.png lynx Icon=web-browser No icons named web-browser, only internet-web-browser.
OK, notabug here then, blame each app for using *only crystalsvg or not providing/using a valid icon.
well... see the ApplicationModelPrivate::iconNameMap() method at the bottom of http://websvn.kde.org/trunk/KDE/kdebase/workspace/plasma/applets/kickoff/core/applicationmodel.cpp?view=markup So, we already work around the same prob for some GNOME apps. Probably we should do the same for other apps?!
Introduce work-arounds instead of fixing the real bugs? *shrug* I prefer the latter.
Re: Comment #7 This workaround is not the solution. Also, it should not be necessary as the GNOME module: gnome-icon-theme-2.20.0 is using the new names. So, if there is a problem it is that Kubuntu 7.04 we shouldn't worry about it since Kubuntu is now releasing 8.0.x.
Since KDE had not supported a HiColor icon theme, this is a bug and it needs to be fixed. See posting to KFM-Devel for solution to the problem.
which posting?
Rex's analysis was indeed correct.
re comment #8 nah, that's not "instead of" but "additional too" since to fix it each of the apps named at comment #5 (and probably more not named yet?!) need to push out a new release and distributors need to pick them up and users need to pick up the new distribution. Sounds for me like a long time job (which needs to be done for sure) but short-time we could get right of it by extending the workaround we already have in place... btw, why is the report marked invalid? wouldn't it be more wise to at least try to get the long time thing started by letting the projects named in comment #5 know about it (or did someone already did send some mails around)?!
For the above mentioned apps I filed bug reports for Debian. I just received an email that for xgnokii the problem has been solved in the latest version.
ah, so it's a distributor-issue rather then a project-issue. Ok, then it's for sure logical to don't work around. Thanks for the hint :)