Bug 127466

The same problems happened two times with different user accounts after I moved from SuSE 10.0 to SuSE 10.1.

I can confirm this. I think it happens since bug 122359 was fixed, at least since the release the fix was in. I hope the fix is not going to be reverted, because I use it all the time.

I have this problem too with kde 3.5.2 gentoo linux 
also, see this http://forums.gentoo.org/viewtopic-t-407921-highlight-kde+kicker.html

I have heard that deleting some file(s) in ~/.kde/ should solve this but I don't know which one(s)

*** This bug has been confirmed by popular vote. ***

*** Bug 126741 has been marked as a duplicate of this bug. ***

This bug still appers on kde 3.5.6 (kicker).

This bug still appers on kde 3.5.7 (kicker). 

I have this problem as well. No Xinerama support compiled in at all. I am using KDE 3.5.7 on Gentoo.

Hiding and unhiding the kicker via the Kcontrol module corrects behavior. This seems to happen randomly (at least to me).

I have a friend with Kubuntu we just installed and it also happened for him. He also has KDE 3.5.7.

To confirm the case when this happens:

Open personal kickerrc file and modify XineramaScreen to be
XineramaScreen=-1

Now you have to restart kicker (you can dcop it or logout)

Kicker will be hidden and unraisable via mouse. Pressing ALT+F1 will bring up the kicker + Kmenu. Let it hide again and still unable to raise via mouse movement to screen bottom.

Now, re-edit the kickerrc file and reset XineramaScreen to 0, dcop/re-login and problem solved.

It would appear there is some library/app/call somewhere that is setting this flag to -1 incorrectly. 

With my old computer with Athlon64 3500+ this problem happened every few days, but after I bought new computer with intel quad core 6600 the kicker seems to disappear almost every 5 minutes! I have no idea how cpu speed would affect kicker, but this really fatal! Every time kicker disappears I must kill it, change Xineramascreen to 0 in kickerrc and then restart it, it's really annoying! This was tested in KDE 3.5.7.

confirmed that this bug appears in Ubuntu 8.04 with KDE 3.5.9

OpenSuSE 10.3 kdebase-3.5.9-83.4

file: kicker/kicker/core/container_extension.cpp function void ExtensionContainer::moveMe() may be called when user don't moved panel. And as result, after this call:
UserRectSel::PanelStrut newStrut = UserRectSel::select(rects, rect().center());
newStrut.m_screen == -1.
and after following line:
arrange(newStrut.m_pos, newStrut.m_alignment, newStrut.m_screen);
application set in varibales invalid value and save it in kickerrc.

file: kicker/kicker/core/userrectsel.cpp in function:
UserRectSel::PanelStrut UserRectSel::select(const RectList& rects, const QPoint& offset)
{
    UserRectSel sel(rects, offset);
    sel.show();
    sel.grabMouse();
    sel.paintCurrent();
    qApp->enter_loop(); // this function in that case running too fast
    sel.paintCurrent();
    sel.releaseMouse();
    qApp->syncX();
    return sel.current;
}
and void UserRectSel::mouseMoveEvent(QMouseEvent * e) newer be called, and UserRectSel::select return value constructed by default:  PanelStrut::PanelStrut(). From here going apperance -1.

I don't know why ExtensionContainer::moveMe() called when user don't moved panel. I will continue my search.

PS. sorry for my english.

Created attachment 25293 [details]
patch for fix misplaced moveMe call consequences

This is odd. Logic seems fine:
* kicker got event: QEvent::MouseButtonPress --- left button
* kicker got event: QEvent::MouseMove
* moveMe() called

But, i don't pressed keys on mouse! I only moved it.

Here patch for fix misplaced moveMe call consequences.

May be source for this bug not in kicker?

I have encountered this same problem on SuSE 10.2 and 10.3 and finally got annoyed enough to hunt down this bug report on it. As a professional software engineer myself I just wanted to add a couple of thoughts for those who are going to fix this problem, to ponder on...

A good design for any problem is one that will guide a user to a solution and not require the he/she have sophisticate knowledge of "magic" commands or a guru's understanding. This particular issue of controlling the auto-hide feature of the task bar does make an attempt to do so, but it has the deadly oversight that in order to set the auto hide feature one must be able to access the task bar itself. Catch-22! if the task bar is failing to rise! To get around this, a rapid, easily discovered solution is needed which provides access to the task bar's control menu from outside the task bar itself. For me, my first place to look was in the context menu that comes up when one right clicks on the background. Might I suggest then, that a menu item be added to this context menu that a user can select to bring up the task bar's control menu? That provides an easily discoverable solution and a way out of the Catch-22...

I'm having the same problem on SuSE 11 with KDE 3.5.9.release 49.1
I've turned off auto-hide for now until I can reliably get it back.
I second the request for a desktop right click shortcut.

Reporting that this issue occured for me under Ubuntu 8.04 LTS Server Edition.  I installed KDE 3.5.9.  

Taskbar vanished and wouldnt pop back up.   Logged out & loged back in with no change.  rebooted with no change.  Finally ran the command 'dcop kicker kicker showTaskBarConfig' based on instructions from this forum's thread http://ubuntuforums.org/archive/index.php/t-212648.html that had many other ubuntu folks  with similar issue.  unchecked the hide taskbar setting, confirmed then rechecked it and confirmed.  presto.  taskbar appeared.  

annoying, please fix when you get a chance.  It's got my vote.

Kicker is currently unmaintained, you can look to your distribution for help, however.