Strange behavior of launchers inside task manager after crash

[Duncan]

JC Francois posted on Mon, 23 Jul 2012 09:58:57 +0200 as excerpted:

> I [crashed due to a full /home.]
> 
> I rebooted, deleted some data files but since then the task manager does
> no longer behave as before:
> 
> . when I click on the Firefox or Thunderbird icon in the task manager
> the app starts but the icon remains visible instead of disappearing.
> . when I click on the Dolphin or Transmission icon the app starts and
> the icon disappears as before (which is fine).
> 
> I tried removing the Firefox and Thunderbird icons and re-adding them
> but the behavior does not change. They seem to be the only 2 apps
> affected by the problem.
> 
> Can you help me fix this issue? I am running KDE 4.7.2 on openSUSE 12.1

This isn't going to be as direct help as it might be, as I actually run 
without a task-manager at all in my panels, so I can't easily check what 
files are involved, etc.  However, here's a general-case strategy that 
I've found often works for such troubleshooting, tho it's somewhat 
laborious...

The idea is to bisect the problem, narrowing down the candidates by 
testing aproximately half of what's left in each round, until you figure 
out which file, and if desired, where in that file, the problem is.

The first step is to verify that a clean user config doesn't have the 
problem.  Either create a new user and test it, or (from root when not 
logged in as your normal user) rename your user dir and recreate an empty 
one for the test.  Then login to kde as that user, and verify that the 
problem isn't there.  Assuming the problem is gone with a clean user 
config, you've verified that it's a problem with your config, not with 
the system.

Step two verifies that it's not the normal kde config within your user.  
Kde stores most of its config under ~/.kde (~/.kde4 on some distros), but 
some of it is in the freedesktop.org standard location (normally 
~/.config/) instead.  So (delete the config from the first test and) move 
your user dir back in place if necessary, and now simply rename your 
user's ~/.kde dir (again, working as root or at least with kde not 
running as your normal user).  Login to kde again, and verify that the 
problem remains missing with all your user config in place EXCEPT ~/.kde 
(or ~/.kde4 if that's what your distro uses).  Assuming it does, you've 
narrowed it down to the ~/.kde dir.

Step three is similar, but now working in ~/.kde.  In there, nearly all 
the config is located in two directories, both under ~/.kde/share.  
~/.kde/share/config contains mostly single *rc files, while ~/.kde/share/
apps contains directories for apps, each with multiple files.  Pick one 
and rename it, then test again.

Once you've confirmed that the problem is in either config or apps, make 
a backup copy of the whole directory, then delete about half of the 
working copy (half the dirs in apps or half the files in config) and test 
again.

If the problem is in the half you test, delete half of it and restore the 
other, good half.  If the problem is NOT in the half you test, simply 
restore half of the remaining, bad half.

Recursively narrow down until you get to a single directory (if it's in 
the apps dir), and then a single file within that directory.  At that 
point, you can take a look at the file, and decide whether you want to 
continue with sections within the file, or simply delete the whole file 
and reconfigure that bit.

If you continue within the file, obviously at that point you switch from 
working with a file manager to working with a text-editor.  Kde config 
files are normally text based generally standard *.ini file format, with 
sections delimited by [entries in brackets] and lines of value=date type 
entries.  In most cases, you can bisect down to the individual file and 
individual line, thus finding your problem.  Of course, if you get down 
to the file level and open it to discover a bunch of binary gibberish, 
you've found your problem as well... a corrupt config file.

One exception is the plasma-desktop-appletsrc file in config.  While it 
IS *.ini format, it's a rather huge complex beast with sections that 
interrelate to each other, storing most of the panel and plasmoid 
settings for the entire plasma desktop, all panels, all activities, all 
plamsoids, so bisecting it is difficult and requires a bit of extra care 
and patience.  In general, I recommend trying to avoid it if possible.  
Once you know you have a configuration customized to what you're happy 
with, keep a backup of that file to simply replace, if it gets 
corrupted.  Alternatively, especially if you don't customize much, you 
can simply blow away the entire file and start with the defaults again, 
altho heavy customizers like me would find that rather painful, since it 
contains the config for the entire desktop, activities and panels.  
Editing the file by hand is possible with enough care and patience as 
I've done it, but it's not something I want to do again, thus the 
recommendation, from experience, to keep a backup!

Hope that helps you pin down and fix the problem! =:^)  It generally 
does, tho if the problem's a complex one with interdependent parts in two 
different config files, it tends to either disappear before you pin it 
down, always frustrating, or refuse to be pinned down to an individual 
bit of the configuration, since if either file triggering the problem 
remains, it comes back.  Especially in the last case, bisecting can often 
help narrow down the problem some, but some other approach may be needed 
to finally pin down and eradicate the issue. =:^(  Luckily, most problems 
are simple enough to be pinned down with a bisect, and the technique 
remains a valuable problem solver as a result.

Meanwhile, it gets easier.  The first time you do it you don't have a lot 
of idea what you're doing, so it's harder.  Tho the hints about the 
~/.kde dir and the config and apps dirs within it do help avoid a couple 
rounds of bisection at the full ~/ level.  After you do it a few times, 
you'll get a better feel for how kde works and where the problems are, 
thus being able to avoid a few more rounds of the bisection, focusing 
more quickly on the exact problem files.

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