Bug 256856

Still happening in kde-4.10-rc1, at least for folder icons. Reboot does not help, I have to manually clear /var/tmp/kdecache-$USER.

Oops, just saw the original report was targeted on windows - I use gentoo linux, Qt-4.8.4, so this seems to be a general problem. -> please reassign.

A way to workaround this issue:
* start dolphin
* change icontheme
* activate the dolphin window and reload the view (e.g. F5)
-> icons change to the new theme and stay!

I have the same problem, and I had it for a long time, since 4.1 or 4.2 I don't remember. Now I am on 4.10 on Arch Linux with qt 4.8.4 and the problem persists.

The problem however is not only on dolphin. Sometimes happens on context menus (the window menu and the desktop menu for example). In that case you see one icon theme (I think is always oxygen) on some items, and when you hover it changes to the icon theme you choose.

Franz's workaround seems to work. However is just a workaround.

I would like to help, I can download the code, however I don't know where to start.

reassign to the dolphin product, since the problem doesn't seem to be windows specific per recent comments.

Thanks for the report, but I'm not sure if I understand what this report is about.

Is the problem that Dolphin does not react to icon theme changes at runtime? This is what comment 3 seems to suggest, but comment 1 sounds like that the problem is that wrong items stay after rebooting?

If there are wrong items after rebooting, then I'm pretty sure that this is not a Dolphin bug. Dolphin does not keep a private cache of icons after closing.

Note that there is another (slightly different) report about icon theme changes: bug 311636.

I would need to get access to a system running kde. But AFAIR dolphin did not react (entirely) on icon theme changes. If you missed F5 in #c3 icon theme would persist, even after reboot (deleting the cache is the only help). AFAIK the last time I checked only folder icons did not change, file icons actually did change - but as said I would need to check this again, may take some days.
Frank, are you not able to reproduce this issue?

I tried it in KDE 4.10.3 (Opensuse) and my 4.10 branch and master builds. In my source builds, it seems to work fine (new Dolphin instances always use the new icon theme, old instances get their icons replaced as soon as these are hovered, or the view is reloaded).

In 4.10.3, I do see some strange effects (like changing the zoom level will switch between old and new icon themes). At first sight, one might think that this could be related to

https://git.reviewboard.kde.org/r/107039/

But then the QPixmapCache is per-process and not kept when closing the app, so this should not affect new Dolphin instances.

I can't really do any further analysis because I cannot reproduce the problem in a source build. However, if the QPixmapCache is not the problem (and I can't see how it could cause such a problem), then the problem is probably in KIcon/KIconLoad/KIconEngine.

I meant KIconLoader, not KIconLoad. BTW, the fact that clearing the icon cache in /var/tmp helps could be another hint that the problem is in kdelibs. But I'm not really familiar with the KIcon* classes.

I'll reassign to kdelibs/kdeui because I still think that the problem is most likely somewhere in KDE's KIcon* classes and that we cannot do anything about this in Dolphin.

*** Bug 325892 has been marked as a duplicate of this bug. ***

Now using 4.11.2 and the problem appears to be fixed

Pity I didn't see this one earlier (I wrote the KSharedDataCache that the current KIconLoader uses).

As long as you are using the SystemSettings / KControl Module to change the icon theme then the icon cache held in /var/kdecache-$USER should be cleared (though in fairness, that was only fixed since May 2010).

However applications which are still running possibly need to listen for the KGlobalSettings::emitChange message regarding a new icon theme (though this might be handled by KIconLoader directly now). Otherwise the application would have to be restarted to guarantee picking up the new theme.

Glad to hear it seems fixed, please reopen if that's not the case.

Unfortunately, the problem still happened for me on Mageia 4 with KDE 4.11.4.
Even after logout / login, I still saw Oxygen icons in dolphin, while other KDE applications (for example amarok) used the new Mak-Lion Taste icon theme I chose.
Same behaviour as it was said :  if I zoomed in or out, the proper theme was displayed, but as soon as I come back to 48x48 icons, oxygen theme was back again.
It was fixed by clearing /var/tmp/kdecache-denis.

(In reply to comment #14)
> Unfortunately, the problem still happened for me on Mageia 4 with KDE 4.11.4.
> Even after logout / login, I still saw Oxygen icons in dolphin, while other
> KDE applications (for example amarok) used the new Mak-Lion Taste icon theme
> I chose.
> Same behaviour as it was said :  if I zoomed in or out, the proper theme was
> displayed, but as soon as I come back to 48x48 icons, oxygen theme was back
> again.
> It was fixed by clearing /var/tmp/kdecache-denis.

Thanks Denis, I am experiencing the problem now on KDE 4.12.2 just tried your solution (in my own KDE cache) and this works for me too

Still a problem here on Linux Manjaro 0.8.9 with KDE 4.12.3.
I believe the problem is not only in Dolphin, as I had problems also in Kate toolbar. The only workaround is to manually clear the icon cache in /var/tmp/kdecache-$USER.

I have this problem on Archlinux with kde 4.13.2. Please, after four years can we fix this?

now on openSUSE with KDE 4.13.3 and problem persists

ARCH Linux with plasma 5.2 the problem still exists, ??

Yep, them bug is still here. After I installed Unity next to KDE5, it messed up icons in KDE (and other graphical-related things).

Based on the comments that the bug is still present, and fixed by removing the icon cache, I've tried to reproduce but still cannot. I've also tried adding some debugging code to the base KSharedDataCache class, which is what uses the 'icon-theme.kcache' file.

What I have seen is that sometimes changing the icon theme (from "kcmshell5 icons" or through System Settings) results in a new icon-theme.kcache which duplicates a previous theme's inode number. E.g. if I run "ls -i ~/.cache/icon-cache.kcache" (where ~/.cache is the modern location for the icon caches), I get 4589980 as the inode, then 4587597 (after changing the icon theme from System Settings), then back to 4589980. But the kernel is allowed to reuse inode numbers, and in fact reusing existing entries is even quicker than creating new inodes, which implies that we can expect this happen, as long as the kernel is satisfied there won't be mixed references into the file by accident.

The debugging code I added assigns a unique ID when creating a new cache, and this unique ID *is* different each time I change the icon theme, even when the inode number is duplicated. So if you're still seeing this bug, after using System Settings to change the icon theme, then I'd have to look into something else (e.g. maybe it works on some file systems but not on others).

Michael, should kbuildsycoca5 update ~/.cache/icon-cache.kcache? It actually doesn't, but I don't know if it's a bug. Something is Plasma 5 creates broken icon-cache.kcache file after icons theme change from System Settings. Usually I need to switch to new theme twice to make it fully applied. Otherwise I get mixed icons (some from current theme, some from previous).

(In reply to Pulfer from comment #22)
> Michael, should kbuildsycoca5 update ~/.cache/icon-cache.kcache? It actually
> doesn't, but I don't know if it's a bug. Something is Plasma 5 creates
> broken icon-cache.kcache file after icons theme change from System Settings.
> Usually I need to switch to new theme twice to make it fully applied.
> Otherwise I get mixed icons (some from current theme, some from previous).

Well, it seems to be another bug: https://bugs.kde.org/show_bug.cgi?id=365363

Thank you for reporting this bug in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version?

If you can reproduce the issue, please change the status to "CONFIRMED" when replying. Thank you!

Sorry, Justin, but I have stopped using KDE / Plasma . I now only have GNOME or macOS Monterey.

> On 22 Oct 2022, at 00:59, Justin Zobel <bugzilla_noreply@kde.org> wrote:
> 
> https://bugs.kde.org/show_bug.cgi?id=256856
> 
> Justin Zobel <justin.zobel@gmail.com> changed:
> 
>           What    |Removed                     |Added
> ----------------------------------------------------------------------------
>         Resolution|---                         |WAITINGFORINFO
>             Status|REPORTED                    |NEEDSINFO
> 
> --- Comment #24 from Justin Zobel <justin.zobel@gmail.com> ---
> Thank you for reporting this bug in KDE software. As it has been a while since
> this issue was reported, can we please ask you to see if you can reproduce the
> issue with a recent software version?
> 
> If you can reproduce the issue, please change the status to "CONFIRMED" when
> replying. Thank you!
> 
> -- 
> You are receiving this mail because:
> You are on the CC list for the bug.

Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!

This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!