See this for visual description: https://imgur.com/a/JyU7DK5 SOFTWARE/OS VERSIONS Arch Linux KDE Plasma Version: 5.14.5 KDE Frameworks Version: 5.54 Qt Version: 5.12.0
The icon view is also affected
Does the problem go away if you clear your icon cache with `rm ~/.cache/icon-cache.kcache` and then reboot?
(In reply to Nate Graham from comment #2) > Does the problem go away if you clear your icon cache with `rm > ~/.cache/icon-cache.kcache` and then reboot? Yes, that did help. Couldn't it had been done automatically? Or would also changing icon pack to something else and back solve this?
Good question. Ideally this would have happened automatically. I'll look into whether this is something on our end, or the package manager should have done it.
Filed some downstream bug reports for distros to adjust their packaging: - https://bugs.archlinux.org/task/61632 - https://bugzilla.opensuse.org/show_bug.cgi?id=1124243 - https://bugs.launchpad.net/ubuntu/+source/breeze-icons/+bug/1814612
I see no reason for Arch Linux to violate policy by having a package manager modify something that isn't a package. We don't modify $HOME in our packaging, and even mentioning the idea traditionally provokes a hair-trigger response "only the worst ever packages would ever dare touch $HOME, what is this package and can we have it deleted". Why doesn't Breeze figure out based on hashes or timestamps, that the original files have changed and an update is needed?
Gotcha, we'll try to take care of it ourselves. My ignorance of packaging best practices is definitely showing. :)
It's anyway the wrong level to try implementing this -- how do you robustly log into every user on the system regardless of their home directory, then execute their bashrc, .pam_environment, and .config/environment.d (this one is a bit of circular logic) in order to find out whether $XDG_CACHE_HOME has been set, and finally delete `${XDG_CACHE_HOME:-$HOME/.cache}/icon-cache.kcache`? I mean... you "could" do so, but it begins to become somewhat uncomfortable, and the #1 place to find an overridden variable also introduces arbitrary code execution. Even run as the user, there may be things there that users don't want to be executed unless they are the ones logging in.
This bug to me begs the question why Plasma caches so much in the first place. Some of its caches seem so large that I'd expect less overall overhead reading directly from disk into RAM rather than handling its multiple big caches, create, read, store and include amongst other settings getting backed up from the homedir.
Cache files are mmap'ed for maximum performance. Since mmap's cannot easily get resized, they are created with a large size. Icon caches are still faster to use than to traverse XDG icon paths to check for icons. This is especially true for SVG icons (and SVG Plasma themes), because the cache stores readily rendered bitmaps, instead of SVG.
Christoph, with your experience here, do you have any ideas for how we can resolve this? Is there any way the breeze icons package can hook in the pre-existing cache invalidation-on-upgrade mechanism?
*** Bug 419919 has been marked as a duplicate of this bug. ***