After upgrading from 4.10.1 to 4.10.2 all settings related to desktop containment (wallpaper settings, applets placed on desktop, but panels were not affected) vanished. Exact same issue happened at least once during update around 4.8.x or 4.9.x. I'm not using acitivities, although once I've seen that apparently I have multiple ones created automatically, but not shown in UI, not listed by DBus query (except few) and apparently not switchable that way either. Also (probably) some of windows from previous session ended up on one of them and become unaccessible (until nuking activities settings). Reproducible: Sometimes
It is some issue related to activities, apparently new one got created and switched to (activitymanagerrc lists two entries, still nothing shown in UI). Executing: qdbus org.kde.kglobalaccel /component/plasma_desktop invokeShortcut "Previous Activity" Restores configuration.
Small update, both activities showed up in UI after Plasma crash.
And that happened again today, no upgrades this time... Activities switcher shows only newly created one. This time DBus doesn't help. Contents of activitymanagerrc: [Plugins] org.kde.kactivitymanager.activityrankingEnabled=false org.kde.kactivitymanager.globalshortcutsEnabled=true org.kde.kactivitymanager.resourcescoringEnabled=false org.kde.kactivitymanager.slcEnabled=false org.kde.kactivitymanager.virtualdesktopswitchEnabled=true [activities] 749725b6-55db-4976-9826-f486019b47fe=Nowe działanie.. 8ec29a2e-e0af-4cb7-b544-7e466b16878a=Nowe działanie.. [main] currentActivity=8ec29a2e-e0af-4cb7-b544-7e466b16878a lastUnlockedActivity=8ec29a2e-e0af-4cb7-b544-7e466b16878a runningActivities=749725b6-55db-4976-9826-f486019b47fe
After discussion on IRC it seems to be result of disabling Nepomuk. There was also idea of possible workaround, by removing .desktop files of services related to activities, but that doesn't help, it even makes things worse, new activity is created each time when user logs in.
Hi all, it's possible that https://bugs.kde.org/show_bug.cgi?id=322526 is a duplicate of this, only with a different version of the desktop. I too get a "New Activity" in "config/activitymanagerrc" and the wallpapers, widgets, icons and others containments gone. Very annoying. What can I do?
In my case removing (but renaming is enough) of /usr/bin/kactivitymanagerd solved the issue for good (it has to be done after each update... at least in case of binary packages). You can mark your bug as duplicate using ling under comment field.
Hi Michał, (In reply to comment #6) > In my case removing (but renaming is enough) of /usr/bin/kactivitymanagerd > solved the issue for good (it has to be done after each update... at least > in case of binary packages). thanks for the insight - I'll try it out. > You can mark your bug as duplicate using ling under comment field. Thanks, I know. Regards, -- Shlomi Fish
*** Bug 322526 has been marked as a duplicate of this bug. ***
(In reply to comment #6) > In my case removing (but renaming is enough) of /usr/bin/kactivitymanagerd > solved the issue for good (it has to be done after each update... at least > in case of binary packages). > You can mark your bug as duplicate using ling under comment field. Renaming kactivitymanagerd did not fix the problem here - sorry. I marked my bug as a duplicate of this one.
It won't undo harm already done (it can be done manually by editing plasma-desktop-appletsrc, but it is not so easy...), but should prevent creation of new activity for each login. Also make sure that you don't have that process (kactivitymanagerd) running. AFAIR I took also few other steps before finally removing that binary (like removing its desktop file as suggested, removing its configuration etc.). But still that should be enough (at least for 4.10.x and older)...
I discovered something: on my laptop, which is also running Mageia Linux Cauldron x86-64, the upgrade went smoothly and all my containments still exist there. I guess I'll have to investigate what the difference between the two systems is.
As pointed above, check if both of them are running Nepomuk. According to developers activities were made to require it. And I wonder why they can't at least check if it is available and disable them at all if it is not or give at least option to manually disable them (since at least Kubuntu doesn't allow to uninstall them without removing most of KDE packages...).
(In reply to comment #12) > As pointed above, check if both of them are running Nepomuk. None of these systems are running Nepomuk (at least not in systemsettings), and it doesn't seem to matter. Regards, -- Shlomi Fish > According to developers activities were made to require it. > And I wonder why they can't at least check if it is available and disable > them at all if it is not or give at least option to manually disable them > (since at least Kubuntu doesn't allow to uninstall them without removing > most of KDE packages...).
Hi all, OK, I discovered something: sometimes when I start KDE using "WD=kde4 startx " ("WD" is my which desktop environment variable), then the activities manager displays all the activities that were created - *including* the original one with all the containmaints (wallpapers, icons, etc.). However, it doesn't stick for the next time even if I do save session. It may have to do with my attempt to create a new activity by cloning an existing (and empty and undesired) one. So now I can use my new settings after a few trials and am mostly happy. The downside is that empty new activities tend to accumulate. Regards, -- Shlomi Fish
I finally have my computer back and access to bko... The first thing that I need to ask is whether the behaviour is the same for a blank slate - you can create a new user and log in every once in a while to test. Before every log-in, after log-in, before log-out, and after log-out, it would be nice to check the activitymanagerrc file. Another thing to do is to go to the system settings and disable all activity manager plugins, and enable them one by one to see whether they are to blame. Theoretically, kamd should not be impacted by the presence of nepomuk, it should react badly to not-working-but-present nepomuk.
Hi Ivan, thanks for trying to help. (In reply to comment #15) > I finally have my computer back and access to bko... > > The first thing that I need to ask is whether the behaviour is the same for > a blank slate - you can create a new user and log in every once in a while > to test. Before every log-in, after log-in, before log-out, and after > log-out, it would be nice to check the activitymanagerrc file. OK, like I said - it doesn't happen on my laptop's user. But I'll try on a new user on my desktop machine. > > Another thing to do is to go to the system settings and disable all activity > manager plugins, and enable them one by one to see whether they are to blame. Well, I disabled all the activity manager plugins and I am still getting this problem. > > Theoretically, kamd should not be impacted by the presence of nepomuk, it > should react badly to not-working-but-present nepomuk. OK. Regards, -- Shlomi Fish
> > The first thing that I need to ask is whether the behaviour is the same for > > a blank slate - you can create a new user and log in every once in a while > > to test. Before every log-in, after log-in, before log-out, and after > > log-out, it would be nice to check the activitymanagerrc file. > > OK, like I said - it doesn't happen on my laptop's user. But I'll try on a > new user on my desktop machine. > Everything appears to be fine in a new UNIX user account. I can log in, change the wallpapers, log out and log in back again there.
One surprising workaround for this bug is to reboot. Yes, after I upgrade KDE, I reboot and then I can use the old activities with the containments. Maybe there's a stray daemon running around, but I didn't fully investigate.
Still present in KDE 4.11, cannot reproduce on another account (also with Nepomuk disabled).
And ideas what can be done to fix this or find a reason? I've forgot to delete kactivitymanagerd before restarting after upgrade from 4.11.0. to 4.11.2 and it bitten me again.
Just a note: I tried to see if the following Bash script that I ran as root and which I called "Restarto_mania.bash" will fix this problem and it didn't fix it either. I'm running it on Mageia Linux x86-64 Cauldron: [CODE] #!/bin/bash pkill -9 -u shlomif pkill -9 -U shlomif service dbus restart systemctl list-unit-files --type=service | grep enabled | perl -lane 'print "systemctl restart $F[0]"' | bash [/CODE] My username is "shlomif" - you should replace it with yours. Regards, -- Shlomi Fish
The only thing that comes to mind is that plasma is creating an additional activity because of some problem in its configuration. Can you try logging out, logging in a terminal (or some non-plasma session), moving .kde/share/config/plasma* and activitymanagerrc files somewhere else, and logging back in. It should create the default plasma and kamd configuration, and should not reintroduce the problem.
Hi Ivan, (In reply to comment #22) > The only thing that comes to mind is that plasma is creating an additional > activity because of some problem in its configuration. Ah. > > Can you try logging out, logging in a terminal (or some non-plasma session), > moving .kde/share/config/plasma* and activitymanagerrc files somewhere else, > and logging back in. I can try that, but that may make me need to recreate all my settings back. > > It should create the default plasma and kamd configuration, and should not > reintroduce the problem. OK, thanks, I'll try that. Regards, -- Shlomi Fish
Hi Ivan, (In reply to comment #23) > Hi Ivan, > > (In reply to comment #22) > > The only thing that comes to mind is that plasma is creating an additional > > activity because of some problem in its configuration. > > Ah. > > > > > Can you try logging out, logging in a terminal (or some non-plasma session), > > moving .kde/share/config/plasma* and activitymanagerrc files somewhere else, > > and logging back in. > > I can try that, but that may make me need to recreate all my settings back. > OK, I tried that: backed up those settings, moved them away, and then I started KDE from the command line, and had a mostly pristine Plasma/activities state. Then I set different widgets (and a background) per virtual desktop and restored the wallpapers and the icons. Then I logged out of KDE (which I started using startx), and backed up the entire ~/.kde4/share/config/ settings. After that, I ran startx again and saw that the problem reported here happened again. :-(. I again was unable to solve it except for a reboot, but this time we have a pristine state of the KDE configuration right before it happened again. Is there anything there that you would particularly be interested in? The plot just thickened. :-). Regards, -- Shlomi Fish
Hi all. It's possible that I found a workaround for this bug that does not require rebooting. What worked for me was logging out of all KDE sessions, killing all the processes of your user, and then moving away «/var/tmp/kdecache-shlomif/» ("shlomif" is my username - and /var/tmp is where the kdecache directories appear in KDE). After starting KDE using startx after that I had all of my activities back. It's possible that it will work while moving away the kdecache directory without the need for the rest of the procedure. One way I found to reproduce the problem here is to start a KDE session on :0, then login from virtual console 1 and start a new session on :1, then kill the :1 session using Ctrl+Alt+Backspace, then exiting from the :0 session normally, and then starting it again. Hope it helps. Regards, -- Shlomi Fish
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 is already 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