[kde-linux] Re: No panel/taskbar after going to single monitor

[Duncan]

Mark Knecht posted on Mon, 04 Apr 2011 08:37:52 -0700 as excerpted:

> I'm using whatever the stable version from portage is. 4.4.5 I think.
> 
> I read through your response, used the Alt-F2 trick to get
> systemsettings up and running, didn't see any problems with KDE-4.4.5's
> thoughts about what was attached for monitors. It saw one 1280x1024
> monitor attached to VGA1 which is what it should see.

Yes, but forcing it to some other, likely lower, resolution (800x600 or 
1024x768 would have been candidates, if available), and then back, /might/ 
have resolved the problem.

Then again, it might not have, as well.

> Still no
> panel/taskbar/App Launcher across the bottom. I found I could add
> widgets to the desktop but if I tried to add an App Launcher it just
> disappeared.

Interesting.  What I suspect was happening is that plasma still thought it 
was using a bigger desktop, and was still placing the panel, and with it 
the taskbar, etc, on the now non-existent monitor outside the visible 
area.  Why an app-laucher plasmoid wouldn't stick to the desktop, I don't 
know.  Maybe it was going to the non-existent area as well?

As I said, however, 4.4 still had some significant bugs in that area.  kde 
in general and kwin had pretty much been cleaned up, but plasma was still 
buggy... and it's plasma that you were having problems with.

> The easy way out was to delete the .kde4 directory in my home directory
> and just start like a new user. I'm now back up and configured the way I
> want. I don't know what I lost by doing that - probably some saved
> passwords, etc., but nothing too hard to set up again.

Ouch!  For a heavy customizer like me, wiping the entire ~/.kde4 dir is 
pretty much unthinkable, as it represents DAYS of work, probably at least 
several HOURS worth to get everything customized as desired, once again.

Instead, if it came to that, I'd use what has with the popularity of git 
now come to be popularly known as the bisect method.  Repeatedly split the 
problem more or less in half, seeing whether the problem remains in the 
testing half and then either trying the other half or halving the testing 
half again (into quarters, eighths, 16ths...), until one resolves the 
problem down to a single file or even a single line within that file.

What that would mean in this case is moving the ~/.kde4 dir elsewhere for 
backup, then copying half of it back and trying that.  If the problem 
persisted, it's in the half copied back so the other half is clean.  Half 
the bad half can then be deleted (it's still available in the backup) and 
the clean half copied back, to repeat the test, now with a known clean 
half and a testing quarter.  If the problem disappeared, the half you 
tried is clean and it's in the other half, so copy half of the now known 
bad half back (a quarter of the total, combined with the clean half to 
make 3/4) back and test again.

Repeat until the problem file is isolated, then depending on how much 
customization it contains and whether one's really curious to find the 
real problem or not, either stop there, or continue doing the same thing, 
only now working with a text editor on a single file, instead of working 
with whole files and directories.  If the bisect is continued, work first 
with file sections until a single section is pinpointed as the problem, 
then if desired, with individual lines in that section.  Ultimately a 
single line will generally be found to trigger the problem, and you know 
where the bug or bad setting is.

This method of course allows one to spare all the customization of other 
things that would otherwise be lost with the ~/.kde4 dir, but it of course 
takes time and patience.  For the folks who don't care that much about the 
details and thus don't tend to customize that much anyway, it's often 
easier to simply blow away the whole dir, as you did, however much that 
makes heavy customizers such as me cringe at all that needlessly lost work.

The other possibility is that you lose valuable data, perhaps your kmail 
store if it's in that dir, as well, not just config data.  But so many 
users use webmail now, so don't use kmail for much if anything valuable.  
Or they have a backup and can move the kmail dir back if necessary.  Or 
they know it's storing its data elsewhere as they specifically told it to, 
or they lose it, but discover the problem too late...  kmail is of course 
just an example, tho I don't personally know of much other non-config data 
that might be stored in the ~/.kde4 dir.

In any case, it appears that blowing away the ~/.kde4 dir worked fine for 
you, and that's what counts, however much it might make folks like me 
cringe. =:^0

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