Bob Stia posted on Sun, 07 Nov 2010 21:45:32 -0500 as excerpted:
> more info - I find that the other user of this machine,my wife, has the
> exact same problem. Applications dissapearing when minimized. With that
> in mind
> it is unlikely that the problem lies in my personal settings. My wife,
> the other user never configures anything. Uses KDE just as it was
> installed. Not very imaginative but she says she can't be bothered)
>
> Root does not have that problem and I created a new user also. The apps
> minimize to the task bar properly for both of them.
Well, if a new user doesn't have the problem, but an existing user that
never changes the default config does, then it's likely in the user
settings as they were migrated from an earlier version -- so existing
users have the problem but new users don't.
Once you know that, you can use the standard bisect method to find the
problem.
>From outside of KDE as your user (so from a text login or while logged in
as root... altho it's not a good practice to get into to do X/graphics
logins as root, but seems you already do, so...), rename your entire
$KDEHOME dir (normally ~/.kde or possibly ~/.kde<ver>, depending on
distribution), then log back into kde as your user, so it creates a new
$KDEHOME dir. Verify that the problem doesn't exist in that case, so you
know it's in your existing config.
Now, from outside kde (or as root), again, delete the new default that was
just created, and copy over from the backup version that you renamed,
about half. Since most of the config is in $KDEHOME/share/apps and
$KDEHOME/share/config, just to keep things simple, first time around I'd
copy over everything but those.
Again log back into kde, and see if the problem is there or not. Then
based on the result, again with kde as that user shut down, if the problem
wasn't there yet, as I expect since we've copied very little of the config
back, again blow away the $KDEHOME dir and copy what you did before, plus
half of what remains (say the apps subdir but not the config subdir) back
in.
If OTOH the problem reappeared, you know it's in what you copied back in.
So blow away the $KDEHOME dir, then copy in the /other/ half (the half
that you know is good since it wasin the half you tried), plus half of
what you tried, back in.
Either way, you'll now have roughly 3/4 of the config copied back, half
that you know is good, and a quarter from the half that was bad.
Repeat the process, each time narrowing down the focus, until you narrow
it down to a single subdir, and then a single file within that subdir. At
this point, if you're comfortable with restoring the settings in that file
manually (or simply using the defaults), you can stop the bisect and do
that.
If you want to continue the bisect after it's narrowed down to an
individual problem file, use your favorite text editor (personally, I like
the ncurses based mc, midnight commander, for file management at the text
console, and its built-in text editor, mcedit), and continue the process,
narrowing it down to a specific section and then if you wish, a specific
line of the file.
As long as the problem is a single config issue, and reliably
reproducible, as seems likely to be the case for you, this method, while
rather brute force and boring, does tend to find it for you... as long as
you have the patience to continue the process far enough. If the same
problem is triggered multiple ways, or if the issue is intermittent and
not reliably reproducible, that's more of a problem, but luckily, not so
common, so the bisect method works more often than not. =:^) Of course it
helps that the big eliminations are done first, and that you can quit
whenever it gets to the point that it's less bother to reconfigure what's
left manually than to continue the bisect, but I like to pinpoint the
issue personally, finding just what was giving me all that problem, so I
usually continue the process all the way, at least to the individual file
and usually to at least the individual config section within the file, if
not the specific line (which by that point is only a few more bisects
anyway, and it's often narrowed down so I'm not killing all of kde or
whatever by then, only restarting individual apps, making the bisect and
test cycle faster and thus easier to continue to the end.
Another thing that's helpful is that after doing this a few times, you
begin to understand the layout and have an idea where the problem's going
to be, thereby eliminating several bisect test cycles. As I mentioned
here, it's probably in either the apps or config subdirs under $KDEHOME/
share, because that's where kde keeps almost all its config and settings,
thus already eliminating the cycles testing the entire home dir, and
starting with a quick verify that it's in $KDEHOME.
--
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.
