plasma-desktop (KDE factory) acting up?

Sat Oct 30 05:39:59 BST 2010

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 at cox.net> 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.