Version: unspecified (using KDE 4.7.1) OS: Linux I recently moved my KDE cache and temp dirs onto tmpfs because I had switched from HDD to SSD and was looking to minimise disk I/O. The first time I tried to switch and customise my plasma desktop theme, I found the machine's RAM quickly got exhausted. This I tracked down to the creation of multiple 81MB binary files in the pattern /var/tmp/kdecache-$USER/plasma_theme_<theme-name>.kcache Switching themes causes creation of a cache file for each theme tried, as well as a plasma_theme_default.kcache (I assume this is for the purpose of reverting to original settings?), and plasma_theme_internal-system-colors.kcache (purpose unknown). Customising adds additional files in the form plasma_theme_.custom*.kcache. None of these files (each one 81MB) are deleted after the dialog is completed, and the "custom" themes were *not* deleted when I removed them in the UI. In my case, the whole cache had swelled from <100MB to 425MB just through this operation. You might argue that most systems will not worry about such ballooning of the cache, but as KDE doesn't (to my knowledge) offer any advice about required size of the cache, or programmatic methods of managing/limiting/clearing most parts of it (the http cache being the only exception that springs to mind), the user has only observation to go on when considering how much space the cache will require. Under those circumstances, I feel it's unhelpful that one innocuous settings change (trying a few different themes, customising one aspect of that selected) can swell the cache by an order of magnitude. Furthermore, I wonder if there's as much value in retaining all these files after the operation as there would be in reclaiming the space. On a small SSD or RAM-backed system (tablets spring to mind, as well as the configuration of my netbook), this could be critical. If the present system is really considered optimal, I'd really like to see some consideration to adding cache management tools to systemsettings, including a limiter (as with the Strigi database size), though I acknowledge that would be quite a wide-ranging task. Reproducible: Always Steps to Reproduce: 1) Enter System Settings > Workspace Appearance > Desktop Theme 2) Select and apply one alternate theme 3) Revert to original theme and change one sub-item of it 4) Remove "(Customised)" theme and revert to original Actual Results: Five-fold permanent increase in overall cache size. Expected Results: Small increase in cache or temp size, some of it perhaps cleaned-up after the operation.
I can confirm this for the current 4.10.1. Some additional points: - this isn't specific to desktoptheme, I also have a "plasma_theme_internal-system-colors.kcache" (81MiB) - these cache files are even kept after logging in/out, rebooting - I have two cache files for the oxygen theme: "plasma_theme_oxygen.kcache" "plasma_theme_Oxygen.kcache"
I can confirm this for the current KDE version in Fedora repository kde-runtime-4.12.4-1.fc20.x86_64 kde-workspace-4.11.8-1.fc20.x86_64 The temporary folder can go to several gigabytes and crash KWin after there is no more free disk space. .kcache files are over 80 MiB $ ls -l /var/tmp/kdecache-user/plasma*.kcache 84377704 /var/tmp/kdecache-user/plasma_theme_internal-system-colors.kcache 84377704 /var/tmp/kdecache-user/plasma_theme_win-classic_v0.1.kcache
*** This bug has been confirmed by popular vote. ***
This KCM has been effectively replaced with plasmathemeexplorer in plasma-sdk. If your bug still remains please roepen it there.