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