KDE 4.11.2 intermittently forgets plasmoids (2013-10-06)

Duncan 1i5t5.duncan at cox.net
Mon Oct 7 11:08:10 BST 2013 

Steven P. Ulrick posted on Sun, 06 Oct 2013 08:30:00 -0500 as excerpted:

> Hello, Everyone Lately after I logout of KDE and then log back in, my
> desktop background is sometimes changed to something that I did NOT have
> as my background, and all of my Plasmoids are gone...

> [bad] 
> http://afolkey2.us/gallery3/index.php/Assorted/KDE4_11_00-Desktop-
Screenshot-BAD


> [good]
> http://afolkey2.us/gallery3/index.php/Assorted/KDE4_11_00-Desktop-
Screenshot-GOOD

> Rebooting [seemed] to be a sure way to get my desktop back to
> looking like it is supposed to.
> 
> This is on Fedora 19.  KDE version is 4.11.2.
 
> A few weeks later...
> 
> Well, it did it again today.  But this time, the plasmoids, desktop
> background & other settings were still gone AFTER logging in after a
> reboot...  Rebooting used to be how I got all of that back...
> 
> But I tried something new.  I logged out, and then logged back in the
> KDE "Safe Session"  Doing that, my desktop looked just like it is
> supposed to:
> http://afolkey2.us/gallery3/index.php/Assorted/KDE4_11_00-Desktop-
Screenshot-GOOD

> Unfortuately, when I log out of the safe session, and back into a
> regular KDE session, it looks like this again:
> http://afolkey2.us/gallery3/index.php/Assorted/KDE4_11_00-Desktop-
Screenshot-BAD

> Here is all of the stuff that KDE adds to
> ~/.kde/share/config/plasma-desktop-appletsrc:

[new activity added.  Actually two new ones]

> Someone on the Fedora KDE list thought my problem might have something
> to do with Activities.  Here are screenshots of the Activities settings
> when my desktop looks like it is supposed to, and when KDE seems to
> "forget" how my desktop is supposed to look:
> http://afolkey2.us/gallery3/index.php/Assorted/KDE4_11_2-Desktop-
Screenshot-GOOD-Activities_SafeModeLogin
> http://afolkey2.us/gallery3/index.php/Assorted/KDE4_11_2-Desktop-
Screenshot-BAD-Activities_RegularLogin
> 
> 
> So, as things stand now, the only way to get my desktop to look the way
> that I set it up to look is to logout and log back in to the KDE Safe
> Mode.  So, for some reason, when I log into safe mode, KDE reads
> plasma-desktop-appletsrc correctly, but when I log into a normal KDE
> session, it mangles it.  Unless of course Safe Mode is getting my
> desktop settings from something other than
> ~/.kde/share/config/plasma-desktop-appletsrc

They're correct.  I've been suffering this bug since the 4.11-betas and 
filed a bug on it too, but it has yet to be fixed, or even commented on 
by the plasma devs.

https://bugs.kde.org/show_bug.cgi?id=321781

Except my setup's a bit different.  I'm on gentoo and don't use a *DM 
graphical login, choosing instead to login at the CLI and run startx, 
with kde set as my xsession.

So I go directly from CLI login to kde via startx and don't have the so-
called safe mode you mention, nor do I know what it actually does.  
However, the fact that it works there should be a clue as to the cause, 
for anyone who knows more about it.

Meanwhile, I've discovered that there's another application, the activity 
manager, kactivitymanagerd, running in the background.  As best I can 
tell, the activity manager is the actual problem, or more precisely, the 
fact that it is racing with something else, perhaps kded, or maybe the 
user dbus session, at kde startup/login.  It tries to get the existing 
activity configuration and because whatever service isn't running yet, no 
configuration is returned.  Instead of interpreting that as a hint to 
wait a bit and try again after whatever service has time to start, it's 
interpreting that as no configuration existing -- a fresh user config -- 
so it's creating a new default activity.

The config file for kactivitymanagerd is activitymanagerrc, in
$KDEHOME/share/config/ just as is plasma-desktop-appletsrc.  You'll 
probably find it's adding a new default activity every time this happens, 
since it can't find the existing config until AFTER it creates a new 
activity.  So you might have a whole bunch of default activities there, 
probably with corresponding entries for each one in plasma-desktop-
appletsrc.  At least that's what I saw happening here.

So I did a couple things as a work around.

First, in ordered to keep those files from getting useless junk added 
every time I started kde, I set both activitymanagerrc and plasma-desktop-
appletsrc read-only.  Fortunately, plasma/kde DOES seem to honor that, 
and the files don't have the "junk" activities continuously added any 
more.

However, that DOES mean that any plasma config changes you make are 
temporary -- they don't actually get written to the file(s) unless you 
set them read-write again so the updates can be written.  However, if 
like me you've setup a custom config and don't change it much, and 
*DEFINITELY* don't want plasma overwriting it with garbage and risk 
having to redo all that customizing, that's an acceptable trade-off.  
Also note that for plasmoids such as comic-strip, that keep current state 
(in the case of comic strip, the last visited strip) in plasma-desktop-
appletsrc, setting it read-only will mean those get reset when you 
restart plasma, too.  Fortunately plasma can deal with that and updates 
to the current day's comic without fuss.

Second, with those two files set read-only so the bad settings couldn't 
be written to them so I don't I end up with more and more proliferating 
default activities, I found that killing and restarting plasma-desktop 
after kde was running gave me back my normal activities.  Apparently by 
then whatever service is running properly, and plasma and/or the activity 
manager can read the config normally.

Except, unless I kill BOTH the activity manager and plasma, and then 
restart plasma, when plasma restarts it'll still have that default 
activity that the activity manager added before it could read the config, 
but at least it'll have my normal activities as well, and I can switch 
between the new default activity and my normal activities using the 
normal activity switching mechanism.  (Here, I have the ctrl-vertical-
scroll event over the desktop set to trigger an activity switch so it 
cycles thru all activities, just like unmodified vert-scroll over the 
desktop cycles thru all virtual desktops.  So I usually just ctrl-vert-
scroll to one of my two normal activities, just as I'd normally switch 
between them.


So after kde's up and running, kill plasma-desktop (a killall plasma-
desktop from the run dialog works, or do it the kde way, kquitapp plasma-
desktop), and optionally kactivitymanagerd, then restart plasma-desktop.  
You should then have your normal activities, tho unless you killed 
kactivitymanagerd too, you'll also have the new activity along with your 
normal ones, and it'll start out active so you'll have to switch to your 
normal activity however you normally switch activities.

That should work.

But I got tired of doing that manually here, so I setup an autostart 
script to do it for me:


#!/bin/bash
# uncomment the following exit to see if plasma starts correctly yet
#exit

app=plasma-desktop

# reset our path from autostart-disabler
[[ $OLDPATH == */bin* ]] && {
        PATH="$OLDPATH"
        unset OLDPATH
}

sleep 2
kquitapp $app
sleep 1
$app

########################################

If you put that in a file called plasma-reset.sh, set it executable, and 
drop it in your kde autostart directory, that should do it.  Note that 
you may need to adjust the sleep delay's slightly, depending on the speed 
of your drive.  Here I have an SSD so things run pretty fast (I could 
probably even shorten those sleeps further but that's good enough for 
me), but on a legacy spinning rust hard drive, particularly a slow one, 
if whatever mystery service isn't started yet and you still only get the 
default activity with those settings, lengthen the sleeps a bit.

Meanwhile, please add the bit of information about kde safe mode that I 
didn't have to that bug.  With luck it'll get the attention of the plasma 
devs and get it fixed.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.

More information about the kde mailing list