Re: Strange behavior of launchers inside task manager after crash
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
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
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
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.
More info: http://www.kde.org/faq.html.
[Red Hat Install]
[GIMP for Windows]
[Red Hat Development]