Version: (using KDE 4.3.0) OS: Linux Installed from: Ubuntu Packages It appears that plasma stores current user desktop data, such as current wallpaper, widgets, widget configurations, etc., in /var/tmp/kdecache-* rather than in the /home folder. Changing or restoring the /home folder from backup between boots results in a mixture of old and new desktop configurations, or a broken configuration. Unlike other KDE apps, plasma does not treat the data in /var/tmp as temporary, and it does not check it against /home configuration files. This poor handling of user configuration data by plasma means that backing up and restoring the /home folder no longer backs up and restores the user's desktop. As this is contrary to the design of linux and KDE, this should be corrected. Specifically, if /var/tmp is used at all, on a new login plasma should read its configuration from /home, not from /var/tmp.
I just asked at #plasma@freenode and they confirmed my thoughts about this: Plasma is not saving its *data/configuration* in that location, but just a cache. The real problem is that when a different configuration is loaded, sometimes the cache isn't invalidated properly, and therefore, some old values are mixed with the new loaded ones; leading to your impression. Backuping /home will in fact, backup Plasma configuration as well. I'm renaming the report to clear the confusion Thanks
Thanks for the info. I'm not convinced that is entirely so. In one case I moved a user's /home folder to a freshly installed system. When I logged in, some of the widgets had lost their configuration and simply had a "configure" button on them. I had to set them up from scratch, as if they had just been added. I don't know if this was the widget or plasma's responsibility. I think one of them was a comic strip. In another case, I changed a /home folder, and when I logged in (after a reboot), the desktop had the old user's wallpaper on it, and apparently was configured so. Also, on one system with an SSD I have /var/tmp and other folders on a ramdisk to minimize disk writes. On this system, the second xinerama screen always loses its wallpaper after a reboot. I simply click Desktop Settings, then click OK, and it is restored. (This problem is more in line with the cache not being invalidated as you said, because the configuration is present, it's just ignored.) Anyway, there are definitely problems with trying to maintain user's configs the way plasma is handling its data - it does not behave as if /home contains the configuration. I think it should discard its cache every login - otherwise there are bound to be problems with it not catching configuration changes which occur between logins or boots.
I confirm that the mixup occurs also in openSUSE (KDE SC 4.3.4).
all configuration is kept in `kde4-config --localprefix`/share/config/. no settings are kept in any temporary directories. the only thing kept there are rendered pixmaps (e.g. for wallpapers, etc) and those are checked on _every start_ of plasma-desktop.
They are checked, but plasma caching (or general image caching mechanism) is apparently suboptimal. Still it sometimes happens (although I haven't reproduced it since 4.4.2) that /var/tmp/kdecache-${username}/kpc needs to be purged in order to fix "plasma kickoff menu occassionally renders messed up application icons after kde update and restart does not help" bugs which are related to "plasma analog clock is not rendered properly". Therefore bug is perfectly valid - but should be most likely reassigned to mpyne. Closing bug with 60 votes as invalid is a bit insulting.
Created attachment 43677 [details] icon cache problem KDE SC 4.4.3 (4.4 svn branch), Qt-4.6.2 Restart does not help. Unless kpc/ forlder is purged manually, kopete icon will have look randomly chosen from image cache.
Created attachment 43678 [details] A bit later
Created attachment 43679 [details] After restart (you can notice wallpaper change...)
I'm sorry but the fact that I fixed some bugs in KPixmapCache does not mean I have the time to take them all on. :( Plasma will not use KPixmapCache anymore in KDE SC 4.5, and although the replacement (KSharedDataCache) should be more resilient in theory to corrupt data, neither one is completely resilient without heavy validation. I will be investigating ways to flag the cache as corrupt or possibly corrupt but that doesn't belong to this bug, as clearing a KSharedDataCache is much more trivial than was true for KPixmapCache.
Similar, maybe related bug 198770 is still present in 4.4.81.
Still present in 4.5 svn branch. Consider wiping out corresponding entries from /var/tmp/kdecache-${user} on startup entirely if it's too hard to be solved other way.