plasma-desktop (KDE factory) acting up?

[Duncan]

phanisvara das posted on Fri, 29 Oct 2010 13:50:25 +0530 as excerpted:

> for the last week or so i'm experiencing plasma-desktop getting
> corrupted without any apparent reason: the standard panel disappears,
> additional activities 'create themselves,' and the desktop seems to be
> in front of running applications. app.s show up on alt+tab (task
> switcher), but are invisible behind the desktop. they react to
> keystrokes, like alt+F4, but don't show up. restarting plasma-desktop
> doesn't help in such situations. only deleting everything plasma-related
> from ~/.kde4/share remedies the situation.
> 
> i'm not complaining: using factory such things are to be expected, and i
> have the awesome windows manager to fall back to if things should get
> worse. but i'd like to know if i'm the only one experiencing this, i.e,
> if i have messed up something in my box, or if this happens to others
> too?

I've no idea what "KDE factory" is.  Maybe "as shipped by upstream"?  What 
kde version?

Meanwhile...

With 4.5.x here (currently 4.5.2 but I'm not sure if it was 4.5.2 when 
this happened), I triggered something rather similar when I started 
experimenting with adding activities, etc (it was for a reply to a list 
post, in fact), and I had a plasma crash (initial plasma crash due to a 
graphics related kernel bug on my particular hardware).  After a couple 
plasma crashes (triggered by the kernel bug), it was as if plasma decided 
to create new versions of about three activities every time it was 
restarted (new kde start, graceful plasma terminate and restart, crash, 
didn't matter now), PLUS remembering the activities it had before, so I 
very quickly developed a whole slew of activities.

I don't know what was causing it (after the initial trigger, anyway, other 
than presumably plasma doesn't react as well as it might to a partially 
corrupted config), but I have a heavily enough customized plasma setup 
that I didn't want to lose all of it with a clean config, so I was quite 
reluctant to go that route.

So I used the bisect method to track it down to a specific file, then dove 
into that file with a text editor...

The bisect method is a reasonably simple if boring "brute force" method of 
tracing a problem down.  Many people use it, by various names, but it has 
become popular lately by the name "bisect", as the git revision control 
system has a tool by that name that automates the process in regard do 
pinning a bug down to a specific commit.  However, the technique works 
well enough to narrow down the domain that it even has a popular social 
game based on it -- "20 questions" -- you may have heard of it.

The idea is this.  From outside of whatever is causing the problem (so 
with a kde issue, from gnome or from a text login, without kde running, 
for some things you may want to login as root, and do it with your whole 
user home dir), backup the existing config.  To ensure that you're on the 
right track, it's recommended to simply rename the whole thing (the entire 
~/.kde dir, for instance) the first time, so it's starting fresh.

Then start whatever is causing the problem (kde, in this case), and see if 
the problem is gone.  If it is, you've confirmed that you're on the right 
track.

Now, shut down the problem (kde, here) again, and remove anything created 
from the initial test.  Now split the problem space roughly in half.  Copy 
about half the config back from backup, and repeat the test.  Now, if the 
problem is back, you know it's in the half you copied back.  If it's not, 
you know it's in the half you did NOT copy back.

If you copied the good half, you can leave it, and now copy back half of 
what's left.  If it was the bad half you copied, delete half of it, and 
copy in the good half.  Either way, you now have half of the config known 
good and half bad, with the good half plus half of the bad half now in 
place.

Repeat the test again... and again... each time reducing the suspect area 
by roughly half.

Eventually, you'll narrow it down to a suspect dir, then a subdir, then an 
individual file.

If you customize like me, at any point you can decide, "OK, I can recreate 
what's left from here without too much problem, I'm done."  But because I 
like to actually find the problem, I generally keep going.  The point at 
which it gets down to an individual file is a natural point at which to 
make that decision, because at that point you cease working with the 
filesystem and start working with a text editor (assuming it's a text 
based config file, like KDE's are, fortunately).

However, once I reached the individual file, which in at least my case was 
$KDEHOME/share/config/plasma-desktop-appletsrc, I *STILL* had a huge 
amount of customization invested in the thing that I didn't want to lose.  
Basically, it appears that file contains the ENTIRE plasma desktop config, 
ALL activities, ALL panels, ALL plasmoids on those panels!  That's a *LOT* 
of config to lose, for a heavy customizer such as myself.  (IOW, I really /
do/ hope they make it a directory tree based config at some point, with a 
top level file at the top of the tree, describing each panel and activity, 
with a subdir for each one.  Each subdir would then contain further files 
and perhaps subdirs of its own, if it represents a container plasmoid, so 
ultimately, losing or corrupting a single file isn't such a huge loss!)

So I had little choice but to continue with the text editor in that file 
itself.  Unfortunately, while the layout is text oriented, the file isn't 
exactly designed to be easy to edit manually, as every widget is numbered, 
and one has to manually track down what each numbered element represents.  
Some are easier than others as they contain names or other config hints, 
but it can still be difficult if there's multiple instances of a widget 
configured -- say multiple panels, or multiple activities, as one then has 
to sort out not just that it's an activity, but which one.

But eventually, using a combination of further bisection and simply 
reasoning out what each section corresponded to, I made enough sense of 
the format and how the the individual sections corresponded to various 
plasma widgets, whether they be containers or plasmoids, that I was able 
to trouble-shoot things, and eliminate all the multiplying activities, 
etc, while keeping the two activities I actually use, plus the panels, 
along with all but one of the individual plasmoids, intact.

In the process, I pruned several sections that were "lost" fragments of 
config from widgets I had long since deleted, as well as whatever was 
actually triggering the activity multiplication, etc.

So it's possible to do, if you have enough patience and reasoning power to 
stare at the text config and reason out what each section does.  I 
mentioned the file that was the problem here, plasma-desktop-appletsrc, 
and I expect your version is getting corrupted as well.  If that proves to 
be your problem, I've already eliminated all the bisection to the 
individual file level that I had to do, for you.

What you'll need to do now is either using the same edit methods I did, or 
simply from-scratch reconfiguration, try to pin down the multiplier 
trigger to a single widget or action, and then avoid it like the plague!  
You can then configure everything else to your liking, simply avoiding 
whatever individual widget or action (in my case, it had something to do 
with playing around with additional activities, but fortunately, my 
existing config was stable enough and close enough to what I wanted that I 
could stop doing that, thus ceasing to pull the trigger on more problems) 
causes the issue, once you're otherwise configured to your liking.

Meanwhile, plasma-desktop is stable enough for me now, as long as I don't 
go playing with activities too much.  And if I DO decide to play with 
them, you can be very sure I'm going to make a fresh copy of my stable and 
working plasma-desktop-appletsrc before I do so, just in case!  Then I can 
play all I want, and knowing the file that's the problem if it gets 
corrupted, simply restore it from backup if activities start multiplying 
on me again or something!  =:^)

-- 
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.