Version: (using KDE KDE 3.5.0) Installed from: Fedora RPMs Compiler: standard fedora 4 distribution build OS: Linux After installing latest KDE distribution (3.5 - most modules) the toolbar which is set to autohide disappears completely from the desktop AND DOES NOT RETURN. Was functioning correctly with version 3.4.2. This is true both on the machine console monitior and from a remote XDMCP session (Reflection). Please note: my toolbar is positioned at the top of the screen. I also noted that some desktop icons were superimposed (stacked) on each other in the the top left corner. This forced me to revert back to the previous version where the KDE menu system was no longer available. Additional details are available on request. Althoough KDE did not crash, I consider this a critical issue where most KDE functionality was gone.
The Konqueror bookmarks toolbar? Is that what you're talking about?
I'm talking about the main KDE desktop Toolbar/Menubar. The bug reporting system caused Konqueror to be added. My guess is that it would be part of kdebase or kdelibs, but I'm not sure of this.
Same here under Gentoo! I have a dual head / xinerama setup with one screen at 1600x1200 (left) and one screen 1024 x 768 (right). I configured two panels, the main panel at the bottom of the left screen, and another one at the bottom of the right screen. As soon as autohide is activated (immediately) in my case, the panel will hide and although "raise when the pointer touches the screen's:" bottom edge (in my case) is checked, the panel(s) won't come up again. I tried several combinations of panel positions and "raise edges" without success. Once a panel is hidden in KDE 3.5 it will not raise again. When reverting to "Only hide when a panel-hiding button is clicked" the panel(s) will raise and remain so, even if "Hide automatically (immediately)" is re-selected and applied in the panel configuration, so we then have the opposite behaviour -- the panels wont auto-hide any longer. Now one can uncheck "raise on edge" and reapply -- the panel will hide again with no way to raise again, of course, so we'll re-check "raise on edge" again, and hit apply, alas the panel will not come up when touching the configured edge. I can be brought back by switching to manual hiding and hitting apply. The panel will come up. Then swiching to hide automatically has no effect again, and so on and so on. Panel hiding is severly broken in KDE 3.5, the only thing that works is manual hiding. In manual hiding, window maximizing (at least with two active panels) does not work console sessions, for example, maximize to the full screen resolution an therefore are overlapped by the panel. I hope a fix will be out very soon, as-is KDE 3.5 is quite cumbersome to use... Cheers, Flexx
I can confirm that this autohide problem is present in the kde 3.5.0 packages currently in Debian Scud (experimental). Previously worked fine in 3.4.3 and 3.4.2 from Debian Scud/Unstable. [melkor@melkor:~]$ kicker --version Qt: 3.3.5 KDE: 3.5.0 KDE Panel: 3.5.0 I have kicker set to autohide and transparency, the only way I could fix this problem was to turn off autohiding completely. If I didn't, kicker would momentarily appear after logging into the desktop environment, but only for a split second, and then it would disappear for good. Dave
NOTE: tommi.tervo@kdemail.net has changed this bug's version to 3.4.2. This is incorrect. This bug's first appearance is with version 3.5.0 (current).
Works fine with both 3.5.0 and 3.5.1 in SUSE Linux 10.0.
about the autohide w/ dualhead setup. Setting "Raise when the pointer touches the screen's: " to Right Edge, Top Edge or Top Right Corner will make auto hiding work again but only in those 3 configurations. I'm using KDE 3.5.1 btw. Aaron said this was a duplicate but I couldn't find it after a very non exhaustive search soooo... by the powers vested in me. I declare this bug confirmed.
wrong version. updated.
OK! I think I've kinda figured out what the heck is going on here. The "Raise when the pointer touches the screen's: " option defines the edge relative to the screen where your kicker panel is located. Now this will only hold true, I believe, for panels with a Left-Right setup: ------------------------- |a b|e f| | | | | | | | Screen 1 | Screen 2 | | | | | | | | | | |-----------|-----------| |c Panel-1 d| Panel-2 g| ------------------------- Those with a Top-Bottom setup will have to be thought about with that orientation in mind (and no I'm not going to draw it). This means that for a panel which resides on the right (panel 2) it will have Right Edge (f-g), Top Edge(e-f), Top Right(f), Bottom Edge (d-g) and Bottom Right (g) ONLY available to it as edges. This however is complicated by the fact the in multiple monitor displays monitors can have different resolutions for the two screens. Resulting in something like this: ------------------------- |a b|e f| | | | | | | | Screen 1 | Screen 2 | | | | | | | | |-----------| | | Panel-2 | |-----------|-----------| |c Panel-1 d|----------g| ------------------------- If you are using nvidia's twinview, as I am, then this further complicates the issue. It's possible that X is given the regions a-g as accessible by twinview, but we are only shown on the monitor regions a-e up to Panel-2. This means that nothing below Panel-2 is accessible, removing the "Bottom" options from being used. Thus we only really have Right Edge, Top Edge or Top Right available for access and use for unhiding. In actuality, Top Left Edge is also available for Panel-2 unhiding. If one moves the mouse slowly enough across the top of the desktop "e" will be touched and unhide the panel, but it's such a bitch to get to that it's not worth it. Having exhausted myself explaining what's happened on one of the screens I hope you can extend that logic to see what will happen when Panel-1 is being set to autohide. "a","b","c" and "d" will be accessible but "b" and "d" will take some work to actually get at. The same holds for the Right edge which they define. Now what would be _great_ is if all the people who've commented here could tell us a) whether they are using a twinview setup or a multiple monitor setup. b) if they try again to access the edges, as laid out above, if unhiding now works. I'm kinda tempted to unconfirm this bug as it doesn't seem to be a fault in the code but rather some quirks in how X interacts with multiple displays, but I think I'll let aseigo be the bad guy on this one :-)
Created attachment 15128 [details] Debug output to help track down the problem can someone with the problem please apply this patch and then send me (or attach to this BR) the output along with a detailed description of their X setup and panel configuration (c.f. what illogic-al did =)
I was finally able to get around this bug by completely removeing the KDE environment and then deleting the ".kde" configuration directory. After I installed KDE 3.51, I setup the same screen options as before and the issue did NOT reappear. It seems that there may be an issue with something that is in the ".kde" configuration directory.
how would we send the output? actually where we we get the output from?
> how would we send the output? as a text file, either attached to this report or to me directly by email (aseigo at kde dot org) > actually where we we get the output from? start kicker from a konsole and it will output it to screen. then you can go under the Edit menu and select "Save history as..."
This is an attempt to debug info on the problem laid in Bug Report 118551. It seems that this issue is been ignored. BY THE REPORTERS! "A number of other users have CONFIRMED this on a variety of different systems." And it would be nice if said users could try to help with fixing the problem. And about what Tim said, He must've been talking about something else. Logging into a "new" account with no pre-existing ~/.kde directory does NOT fix the problem.
Created attachment 15165 [details] kicker_konsole_output OK, I have time now so I might as well do it.
illogic-al: thanks for doing this ... however, what we need is the output from kicker after having shown/hidden the panel a few times, both succesfully and showing the failure that you are seeing. if you could then note in which order you did it, such as: "first i showed the panel on screen 1 by putting the mouse at the bottom of screen 1, then i tried to show the bottom of screen2 by putting the mouse at the bottom of screen 2, but it failed.. etc"
Created attachment 15177 [details] kicker_konsole_output A little aside, each time I start kicker from the build directory it crashes then restarts fine. Don't know if that'll affect anything but that's why "'lt-kicker' crashing" shows up. Upon restart kicker seems fine. First changed the Main Panel's (Panel 1) setting to "Hide Automatically: Immediately". "Raise when the pointer touches the screen's:" was first set to Bottom Edge. On screen 1 this works fine, on screen 2 I had to drag the mouse to below the edge of the visible screen. All the other settings worked, but only with respect to the screen the panel was on. Nothing really fails. but if people decide to use edges then they need to keep in mind which screen an edge is on. Here's the debug output anyway. not much different from what was before though.
illogic-al: can you do a "make install" first and then just run kicker from your $PATH? i'm not seeing any of the debug output, which means one of four things: - the patch was not applied (though i'm sure you did that =) - the patched source was not built (make) - the kicker binary being run isn't the one with the patch - you aren't moving the mouse to the edge of the screen and causing panels to unhide automatically (and so no unhidetrigger debug output)
Created attachment 15188 [details] kicker_top_edge Debug using the Top Edge as the trigger for Panel 1. The top edge of Screen 1 and Screen 2 were used.
Created attachment 15189 [details] kicker_right_edge Using the right edge as unhide trigger for Panel 1 on screen one. First used edge from b-d then f-g. Only b-d right edge worked.
So! If we right-click on the panel choose "Configure Panel..." we're presented with the configuration dialog. In the "Arrangement" section for Xinerama setups we have in the Screen section the "Xinerama screen:" option. Setting it to "All Screens" a) stretches the panel to both screens and b) gives us the four corners of the _combined_ screens as our edges. Thusly things will now work (mostly) as expected. Point (a) has to be taken into account and resizing of the Panel (I used 60% of the screen) will be necessary so that you can see everything on it. Again stuff gets weird if the screens are two diff. sizes but i do believe I have conclusively proved (in my case at least) it's not a bug! Can I close this Mr. s-EYE-go? ;-)
good work. though what i think you've proven is that it works, but not as the user expects =( i don't think we should close this bug because there certainly is a discrepancy between what "should" happen and what does... though i don't think i'll be fixing it for 3.5 (though made ade will with his new xinerama setup? =) ... certainly something to avoid in plasma for kde4, however.
Now this is my story, I hope it can help. I do not have a dual display this is a T43 Thinkpad laptop. Running Debian sid. I had this problem in all 3.5 versions what I can think of. Now running kicker --version Qt: 3.3.6 +--+---+---, KDE: 3.5.4 | '---' | KDE Panel: 3.5.4 |__________| |K_________| I have two autohide panels one at the top and one at the bottom. After a while the mainpanel wont come up. The workaround it that I go to the upper one that always work and then select the option Rise then the pointer touches the screen's: bottom edge. Press OK and it is working as normal again, for a while. It happened more then once that it have stopped working again. With the reverse procedure unchecking "Rise then the pointer touches".. and press OK, then it is working again. The time between stops vary from a few minutes up to several days. I will try running kicker from console more often to see if I find something. -- Johan Thelmén Sweden Falun
OK I finaly have some debug output. xinerama screen: 0 then -1 !? When does this happen.. kdDebug() << (int)this << "ExtensionContainer::unhideTriggered(" << tr << ", " << XineramaScreen << ")" << endl; I got int casting error on that one so I excluded it for now. Attaching debug output.
Created attachment 17835 [details] Kicker debug1 jth
I can confirm this bug, too. I get it on Debian Etch, Kubuntu Dapper, FreeBSD, Arch Linux and LFS (self-compiled). No system is using Xinerama. When set to autohide, the toolbar suddenly disappears at a random time. To get it to return, I can press the keys for the k-menu, but it disappears as soon as the menu is closed. When I change the setting of "rise when the pointer touches ..." it reappears. But just some random time after that, it disappears again. Same workaround and it appears again and so on...
Aaron, kicker needs you! kbabel will survive.. :) Still in kicker --version Qt: 3.3.7 KDE: 3.5.5 KDE Panel: 3.5.5 Bug getting closer to birthday.. Anything more we can do to help you find this one?
*** Bug 126893 has been marked as a duplicate of this bug. ***
*** Bug 144482 has been marked as a duplicate of this bug. ***
I finally could find a hint to the problem with the disappaearing kicker: Kicker sometimes autohides forever and does not come back until autohide is switched off and on via kcontrol. A diff between the config files before and after this procedure shows just one different line: XineramaScreen=-1 when the autohide is buggy, and XineramaScreen=0 after kcontrol 'fixed' it. How does XineramaScreen get -1? I do not use multiple screens.
I have the same problem. If I can help somehow let me know. I just use Kubuntu Feisty with a single monitor. This is very annoying since it happens around 2 times per day. Is there any way to get traces or logs to find the root cause? I have killed "kicker" and started again from the console. I can see some logs then, but it seems that nothing special when the problem occurs...
I can also confirm this on Mandriva 2008 and my previous Mandriva 2007.0 (but I don't think I noticed it on Mandriva 2007.1). My kicker task bar is also set to autohide / immediately and is located at the top of the screen. I'm using a Dell Inspiron 9100 with no external displays etc. The problem seems to happen when I move my mouse up onto the taskbar and it starts to unhide. There is a momentary appearance of the kicker at the bottom of the screen, and then it vanishes and will not reappear whatever I do with my mouse. The kicker process is still running. I normally work around this by killing the kicker process and starting kicker from a terminal, but kicker will not work properly unless I also delete my ~/.kde/share/config/kickerrc before restarting it. Because this is means I lose my preferences for the clock, panel icons, panel size etc this is quite irritating but I probably get it once a month on average. One thing I tried was that I wondered if the kickerrc had become corrupted, so after I initially had re-done all my preferences I made a backup of kickerrc as I liked it, with the intention of reinstating this after the next crash. However, this did not solve the problem, so I'm guessing that possibly another settings file has a bad entry which only gets reset on the recreation of kickerrc after I delete it? Just a thought.
I'm seeing this problem too with Debian KDE 4:3.5.8.dfsg.1-2. I have a laptop with a single display. kicker is at the bottom of the screen and set to auto-hide immediately. It sometimes auto-hides and never comes back. The process is still running. If I kill it and restart kicker it works again (for a while).
I have seen the same issue in KDE 3.5.8. And what is more worrying, I have seen it once when setting autohide to 1 second!! With autohide set to 1 second it is less likely that it happens though. So this means that there is something generally wrong with autohide. I cannot reproduce it, but I have noticed that it happens more likely if there is some activity while the hide operation is happening, like switching between windows with Alt+Tab. And some of those operations disturb the autohiding. Is there the possibility that if while autohiding kicker gets disturbed, and the status of the toolbar is still marked as visible instead of hidden, although the reality is that it is hidden? That would explain why it never comes back, because kicker thinks it is visible.
*** Bug 146220 has been marked as a duplicate of this bug. ***
*** Bug 129680 has been marked as a duplicate of this bug. ***
*** Bug 136722 has been marked as a duplicate of this bug. ***
*** Bug 134676 has been marked as a duplicate of this bug. ***
*** Bug 129818 has been marked as a duplicate of this bug. ***
*** Bug 153132 has been marked as a duplicate of this bug. ***
*** Bug 155334 has been marked as a duplicate of this bug. ***
Just to add my experiences: (x86; openSUSE 10.2; KDE 3.5.7 "release 72.4"; one 1280x1024 screen) I use two full-length panels, main one on top, other one bottom. Both set to autohide immediately and reappear when the corresponding screen edge is hit with the mouse. I used to have the problem described here, that (one of) the panels remained hidden and wouldn't come back unless going back to the panel menu and re-applying my settings (sometimes the panels position mysteriously changed from centered bottom/top to left bottom/top). I don't know what changed, but this stopped. Now, the problem I have is that the last unhidden panel just won't hide (so one is always visible), no reapplying the correct configuration changes this. This faulty behavior starts and stops seemingly at random.
I'm using KDE 3.5.8 and have just yesterday developed this kicker autohide problem. Kicker was hiding and appearing very normally, and then yesterday it disappeared and I wasn't been able to make it reappear. I've rebooted after shutdown. I've killed kicker twice, and restarted it, and still it wouldn't come into view. But now I've just tried the workaround of Paul Barratt (Comment #32), and that has made the kicker reappear, but without the Autohide feature. So that is real progress. I can live for awhile without autohide. I haven't tried to reinstall the old kickerrc, which I'd saved.
I've just tried reinstalling the old kickerrc file which I'd saved by renaming, and with it in place, a newly started kicker would not reappear. So I infer taht there is probably a problem in that file that keeps the autohide feature from working. But most of what I had on the Kicker taskbar seems to still be there, so little or now reconfiguration will be needed.
On Friday 01 February 2008 17:13:30 weil@alpha0.iki.kfki.hu wrote: [bugs.kde.org quoted mail] For me it suffices to do: Alt+F2 -> kcontrol Desktop -> Panels -> Hiding -> Only hide when a panel-hiding button is clicked -> Apply toggle back to Hide automatically, Apply And the problem is solved, (until it reappears usually after several hours). Harri Privileged or confidential information may be contained in this message. If you are not the addressee of this message please notify the sender by return and thereafter delete the message, and you may not use, copy, disclose or rely on the information contained in it. Internet e-mail may be susceptible to data corruption, interception and unauthorised amendment for which Wall Street Systems does not accept liability. Whilst we have taken reasonable precautions to ensure that this e-mail and any attachments have been swept for viruses, Wall Street Systems does not accept liability for any damage sustained as a result of viruses. Statements in this message or attachments that do not relate to the business of Wall Street Systems are neither given nor endorsed by the company or its Directors.
Dear Harri, Many thanks for your message (below) on how to activate the Autohide. The first step up to "Only hide..." did not result in an "active" apply button, so I went to the second step, and could apply the "Hide automatically" and it works. Thanks again. Jess On Fri, 1 Feb 2008, Harri wrote: [bugs.kde.org quoted mail]
Updating my comment #42: replace "starts and stops seemingly at random" by "can be worked around by hitting one of the side edges"
Is there any progress on this bug? Still it is present in KDE 3.5.9. Is there anyway we can help? If any debug on kicker can be activated, I am willing to help. This bug is really anoying and it has been opened for quite a while.
Yep, it seems clear, still in 3.5.9 same symptoms: XineramaScreen=-1 in kickerrc makes that kicker will never unhide. The funny thing is that file kickerrc gets updated without changing any configuration parameters. Killing kicker and starting it again has the same results, after hiding the first time it will never unhide again. So the issue seems to be triggered by the unexpected XineramaScreen=-1 coming from the darkside of kicker's code... Are there any changes this will get fixed? This little devil will be soon 3 years old...
Can the XineramaScreen value be checked when saving the settings to kickerrc file and prevent the -1 value to be written there? Isn't the -1 value anyway an illegal value?
Kicker is currently unmaintained, you can look to your distribution for help, however.