Running a Live-System in RAM, plasma-desktop may process too fast so that settings of plasma-desktop are not correctly loaded. A forum thread I started before (see URL) may give some additional information. Reproducible: Sometimes Steps to Reproduce: 1. Setup a Live-System (in my case booting it from PXE (network) for a standard x86-64 Desktop PC. 2. (Use unionfs to create another Layer over the /home Directory and mount it via Xstartup script of KDE - This step might be optional as i didn't find any influence of unionfs in this error) 3. Boot it completely to RAM (no post-loading of files/libraries at runtime) 4. Start KDE via KDM Actual Results: After KDE start process (within plasma-desktop initialization) a standard Desktop without any components (except of KDE task bar) is shown. The (in my case 4) Desktops are obliverated ("desktop=-1") in the config files plasma-desktoprc and plasma-desktop-appletsrc and new (default and empty) desktop components are created instead. This behavior occurs about 19 of 20 times starting KDE - about every 20th time, plasma-desktop manages to parse the config without altering it. Then, the correct Desktops with all components are loaded. Expected Results: The customized Desktop should show after KDE launch. Several components (widgets) should be shown, as like as a customized Desktop background. If setting the plasma-desktoprc and plasma-desktop-appletsrc file to read-only, kdialog shows an error message (executed by plasma-desktop) at KDE startup. After clicking it away, the correct Desktops are loaded (enough time for some parallel process to finish?). Replacing /usr/bin/kdialog with an empty bash script, the bug occurs (default desktops are created) (NOT enough time for some parallel process to finish?). Replacing /usr/bin/kdialog with a bash script that sleeps 1 second (or longer), the bug does not occur (the correct, customized desktops are shown) (enough time for some parallel process to finish?). This was reliably reproducable. Installing the Live-System to HDD, I can't reproduce the bug either (enough time for some parallel process to finish? Loading from Disk slows down the Process good enough?). KDE and Plasma-Desktop might be unusable on some (fast) Live-Systems, but as long as the bug does not occur on installed Systems, the bug may not be grave.
Hi, I experience a very similar bug on my new computers, with kde 4.11 from the last mageia distribution. To clone updates in config files of kde4, I copy the whole .kde4/share/config folder on the destination computers. At first login, it is quite long, but the plasma desktop is correct (defined wallpaper and shortcut desktop icons). But at second or third login, all this disappear and the default blue picture with no icons shows up. When looking at the plasma-desktop-appletrc file, it seems that at each login, a new [Containment] is added at the end of the file, defining these new defaults... with incremented numbers. I could reproduce it on the original computer after removing the .kde4/share/session/kwin_* and kmix_* files, so it may be a race condition between restoring session and reading the config files? Any hint to avoid this would be helpful anyway, if it is not related to the bud described above... Thanks in advance,
This might related to bug 341610
Hello! This bug report was filed for KDE Plasma 4, which reached end-of-support status in August 2015. KDE Plasma 5's desktop shell has been almost completely rewritten for better performance and usability, so it is likely that this bug has already been resolved in Plasma 5. Accordingly, we hope you understand why we must close this bug report. If the issue described here is still present in KDE Plasma 5.12 or later, please feel free to open a new ticket in the "plasmashell" product after reading https://community.kde.org/Get_Involved/Bug_Reporting If you would like to get involved in KDE's bug triaging effort so that future mass bug closes like this are less likely, please read https://community.kde.org/Get_Involved#Bug_Triaging Thanks for your understanding! Nate Graham