Minimized apps dissapear - more info at end of post

[Duncan]

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.