[kde] Re: plasma-desktop (KDE factory) acting up?

http://ivan.fomentgroup.org/blog/2010/10/29/for-the-trunk-users/

Does this affect you?
--
Cheers!
Kishore

On Friday 29 Oct 2010 3:25:32 pm phanisvara das wrote:
On Fri, 29 Oct 2010 15:11:51 +0530, Duncan <1i5t5.duncan@xxxxxxx> wrote:

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

i'm using KDE 4.5.2; you can get that as "KDE:/Release:/45" from
http://download.opensuse.org/repositories/KDE:/Release:/45/, or as
"KDE:/Distro:/Factory" from
http://download.opensuse.org/repositories/KDE:/Distro:/Factory/

the factory version uses qt 4.7 and will turn into KDE 4.6 some time soon,
while release 45 uses qt 4.6 and will stay that way.

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.

no need to remove/rename the whole .kde4 folder when plasma goes nuts.
everything in ~/.kde4/share/config starting with plasma*, plus all plasma*
directories under ~/.kde4/share/apps is sufficient to reset the whole
plasma thing.

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! =:^)


these days i'm not fiddling around with my desktops so much, so that
spending a lot of time fixing this type of bug isn't worth it. i usually
keep a backup of everything plasma somewhere, and either restore that, or
start fresh. but thanks for your explanation of the "bisecting" process.
might come handy when i get myself into some type of mess i don't want to
resolve via overkill.
___________________________________________________
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.

Relevant Pages

  • [kde] Re: plasma-desktop (KDE factory) acting up?
    ... What kde version? ... post, in fact), and I had a plasma crash (initial plasma crash due to a ... that I didn't want to lose all of it with a clean config, ... but it can still be difficult if there's multiple instances of a widget ...
    (KDE)
  • Re: [kde-linux] Dolphin config
    ... I could not make Plasma work in any relyable way. ... previous use of kde. ... but specific to a particular user's kde config. ... To get the root user settings, you have several options which may or may ...
    (KDE)
  • Re: [kde-linux] Dolphin config
    ... I could not make Plasma work in any relyable way. ... previous use of kde. ... but specific to a particular user's kde config. ... To get the root user settings, you have several options which may or may ...
    (KDE)
  • Re: [kde] How to save the desktop applets settings?
    ... Here I get the "factory settings". ... So, I guess when KDE shuts down normally, it deletes or at least changes ... I just did a bit of investigation here, looking to see where plasma keeps ... would be, normally for apps with only a single config file, is ~/.kde/ ...
    (KDE)
  • [kde] Re: 4.6.2 early report
    ... I am back to a totally fscked up kde. ... choice is on workspace 1, as is a cachew in the upper right corner. ... delete to get plasma sane again. ... customizations and the potential gain relatively little. ...
    (KDE)