Version: unspecified (using Devel) OS: Linux Sometimes when I open or close a window, the panel (set to autohide mode) gets visible. This was a problem before, but now it does not hide itself again after a short delay. I have to visit the panel "mouse in/mouse out" to get it to hide. Using trunk r1201016. Regression probably caused by commits to workspace/plasma around r1200100. Reproducible: Sometimes
This is probably related to the task bar grouping regression (bug 258076). When I click on a link "Open in external browser" in Akregator, and have Konqueror set to "Open external links in new window", then the new Konqueror window is not grouped with existing Konqueror windows, and the panel gets visible with the new added task bar entry. After hiding the panel manually, when I close one of the Konqueror windows, the next active Konqueror window gets "ungrouped" from the task bar group, and this causes the panel to show again.
*** Bug 259267 has been marked as a duplicate of this bug. ***
Since some very recent commits, it is worse. Moving in and out of the panel does no longer hide it. I have to click into the taskbar to get it to hide. Totally annoying.
... and sometimes even clicking on the task bar entries does not help, the panel just keeps visible. Since I have the panel at the top, I cannot move or close any windows that it covers. I regularly have to kquitapp plasma-desktop just to get the panel to hide. I have no idea how to reproduce it, but it looks related to windows that demand attention.
in 4.5.90 the panel doesnt autohide anymore it stays ontop even there is no window that demands attention and clicking into the taskbar doesnt outohide it anymore ....
it seems the error is triggerd when a app is started from the classic menu style - when an app is started from kickoff style the taskbar hides itself here ...
rauchwolke has identified it perfectly. Is there any work-around, other than switching to application launcher style (YUCK!)?
the panel still doesnt hide itself but it only happens every now and then when using kickoff style - kquitapp plasma-desktop;plasma-desktop works to get it to its "normal" state again... when kde is left (logout) with the bug present, the panel doesnt autohide itself any more (even after the next start of kde), the only solution to get it working again is to delete the taskbar and create a new one - than it works as expected (until the next time ;) )...
I've got a similar problem in that a vertical auto-hiding right panel breaks sometime in session and wont auto-hide. Nothing seems to fix but restarting login.
Clicking desktop should check for 'auto hide' panel hang. Changing panel to 'always visible' and then back to 'auto hide' is not working either, only > kbuildsycoca4 && kquitapp plasma-desktop && kstart plasma-desktop
I see this too especially with kopete. I have small panel with everything except task list 'always visible' on right edge. Also bigger auto hiding panel on right edge, so it's hidden until I need it. When new message arrives and I have chat window opened in background, chat window wants focus and panel shows up. That's useless (with notification showing up too), but at least a little acceptable. Unfortunately panel never hides again, until I open that chat window and minimize it again, but when new message arrives, it opens again and again and again... and after some time, it's pretty annoying.
I just upgraded to KDE 4.6 via packages released for Ubuntu and I'm experiencing this issue. The panel will auto-hide after startup but then it will be stuck and I have to set it for "always visible". Auto-hide will not work when I reset the auto-hide setting.
*** Bug 264399 has been marked as a duplicate of this bug. ***
*** Bug 264639 has been marked as a duplicate of this bug. ***
in future, please report _each problem_ in a unique bug report. lumping all issues together just because they are similar somehow doesn't help. (imagine if we put all "it crashes" or "there's a memory leak" issues into one big report? :) that said the classic menu issue is resolved; i believe the kickoff one as well. as for kopete, that would likely be because it is setting the status on its system tray icon to "needs attentions" and is then never unsetting it. to the original reporter, Christoph: is the tasks related issue still happening for you? if so, is there a window that is constantly re-setting "demand attention" on itself? (i noticed konversation doing this once a couple weeks back, and had to quit it and then start it again to get it to stop..)
Aaron, thanks for the Kickoff fix! My assumption was that the "panel not hiding" was a panel bug, so fixing that (possibly by reverting the commits) would fix all related bugs. Sorry if I marked wrong duplicates. But the main issue of this bug (the fact that the panel does not hide itself), is not fixed by your commit to the Kickoff applet. I just checked with kdebase r1217835, and I still can get the panel to "block" with any of the following operations: * When I am clicking on an Akregator link to open in external Konqueror window, that window sometimes causes the panel to unhide. No window switching or window closing can hide it. * When I am visiting a site with Konqueror that requires KWallet access, a KWallet dialog shows, and sometimes the panel will not unhide after that. * The same happens when visiting sites with "certification errors", where it asks for confirmation to ignore or accept some certification stuff. * When clicking on the systray Klipper icon, and chose the "Clear Clipboard History" item, a confirmation window shows. After that, the panel does no longer hide. Unfortunately, it isn't reproducible 100%. It seems to depend on which window have focus or whatever. The Klipper systray in particular seems to be the in the same heisenbug category as the "systray menu sometimes shows behind the panel" bug :/
...and I just clicked on the Klipper icon to get the menu, and the panel got stuck. So it isn't just windows, but also plain menus that can block hiding.
(In reply to comment #15) > as for kopete, that would likely be because it is setting the status on its > system tray icon to "needs attentions" and is then never unsetting it. it was not acting like this in 4.5. Is it expected that any window with "needs attention" blocks hiding of panel forever? I added comment here because it fits bug summary quite well. Should I fill separate bug?
@Comment #18: > Is it expected that any window with "needs attention" blocks hiding of panel forever? Example: Open kwrite: type 1 (desktop 1) Open kwrite: type 2, ungroup window and move it to desktop 2 Go to desktop 3. Right click on kwrite group in tasks (settings: always group programs) and close kwrite group. Now 2 kwrite's need attention. Handling the 2 dialogs before continuing makes sense ? (Cleaning up the mess) Twinview setup: left panel, tasks not always grouped right panel, tasks always grouped (right click here kwrite group and close it)
(In reply to comment #19) > @Comment #18: > > Is it expected that any window with "needs attention" blocks hiding of panel forever? > > Example: > Open kwrite: type 1 (desktop 1) > Open kwrite: type 2, ungroup window and move it to desktop 2 > Go to desktop 3. Right click on kwrite group in tasks (settings: always group > programs) and close kwrite group. Now 2 kwrite's need attention. > > Handling the 2 dialogs before continuing makes sense ? > (Cleaning up the mess) Yes, but I don't see how is this related to the complain I made. I agree that there is reason both windows are marked as "needs attention", I just think it should not block hiding of panel forever. They can need their attention even if panel is hidden. Panel can show up when there is new such event, but it should hide again after some time.
How about a setting that disables windows' ability to raise the task bar? That way we can turn it off. Once the bugs are worked out, those who want to can re-enable this "feature" (this "attention" thing is a Windows idea that was a bad idea there and a worse one here!). I know this is actually a feature request, but this has introduced so many bugs in the panel auto-hide mechanism that it seemed appropriate to suggest it here.
Sorry if it's not the same issue, but for me it is very easy to reproduce. I just open Configuration Manager and then panel auto hide doesn't work (even when I close it) until "kbuildsycoca4 && kquitapp plasma-desktop && kstart plasma-desktop".
How to reproduce: Login KDE, start konsole > cat Makefile.out /usr/include/KDE/../kdebug.h:260: warning: array subscript is above array bounds > gvim Makefile.out Now comes the trick: select the green '/usr/include/KDE/../kdebug.h' with mouse. klipper's action menu for files appears. click it away. reselect the already selected file with mouse again. (klipper's action menu for files doesn't appear) Now click klipper in the auto hide panel and click it away. Whoop, the auto hide panel doesn't hide.
I noticed that in my case autohide doesn't work after I start Application Launcher menu by hot key (standard alt+f1 or any else, result is the same). So my workaround is disabling any hot key for Application Launcher in Global Shortcuts and Application Launcher widget settings. May it will helps somebody.
@Comment #23: An other example: Login KDE, start konsole > cat gaga hello > gvim gaga Now comes the trick: select hello in gvim click klipper > edit content (you see 'hello') and click cancel deselect hello in gvim click klipper Whoop, the auto hide panel whon't hide anymore.
steps in comment #25 work fine with current sources.
Maybe the same bug, maybe something else, but it looks the same from my chair... when ksudoku completes a game, either by filling in all the squares or by hitting "new game" while a game is already on the board, it beeps. This beep also causes the autohide panel at the bottom of my screen to become briefly visible. Sometimes (about one time in 3), it remains stuck in this visible state until I start up another ksudoku game and quit games a few times. Eventually, with the beep, the panel autohides again, and its behaviour becomes normal again. Note that I have two autohide panels, the second one is a small one on the left side of the desktop and has only icons to start up emacs and konsole, so this is likely related to something docked in the bottom panel, rather than the panel itself. My bottom panel has: Kickoff launcher, pager (8 virtual desktops), task manager, notifications and jobs, system tray, and digital clock. The widgets are locked.
Oh, forgot to mention the version. svn checkout performed on February 6, revision 1219158.
I'm running into this too, but when playing videos with gmplayer (most often when closing them, actually). It doesn't always happen, but when it does happen I've yet to find any good way to make the panel hide again (toggling the auto-hide setting does nothing) aside from restarting plasma-desktop. I've run into this at least half a dozen times now since I started using 4.6, and it never happened with 4.5 or any previous release, so it's definitely a regression.
*** Bug 265675 has been marked as a duplicate of this bug. ***
I've just upgraded to KDE 4.6.0 and the panel doesn't auto-hide any more. This bug is terribly inconvenient, as I've been using the auto-hide feature for years and a visible panel eats up valuable screen real estate.
Regarding the reproducability of the panel-stops-autohide-until-plasma-restart problem: On a fresh install of SC 4.6 RC1 I added the "Task Manager" widget to _two_ autohide panels and used it without that problem appearing for several days until today after I changed the options of the taskbar of the 1st panel to show only minimized windows of current desktop. After some app-needs-attention event (may be a notification popup but I'm not sure) the 1st panel no longer hides and its taskbar is empty (due to settings described).
imho The panel should always autohide and be hidden when it's set to be hidden. In KDE 4.6.0 frequently pops up the panel and I have to click on whatever opened it, which is sometimes hard to figure out and I have to click on just about everything there to perhaps get it to go away. More importantly, the panel now frequently refuses to hide at all after it pops up and I have to quit KDE to get it to go away. Autohide is basically broken.
I just installed KDE SC 4.6.1 and I can confirm that the panel is now auto-hiding properly.
It appears to have been fixed for me, also. I compiled from a recent checkout (2011-03-05).
The packages that I installed came from a PPA repository for Ubuntu 10.10. I'm not sure if the packager applied any patches but everything seems to be working great!
I just tried today's master from git, and I can still reproduce. So it is not fixed. Bug 267735 is reported for 4.6.1, so it most probably is not fixed in 4.6 branch either.
I'm going to be installing the same KDE 4.6.1 Ubuntu PPA packages onto my laptop and will check to see if the issue occurs on it.
I'm going to install the same Ubuntu Maverick PPA packages on my laptop and will see if the behavior persists there.
I am running KDE-4.6.1 from Fedora KDE (in kde-testing currently), and my panels do not always hide. :-/ kdebase-workspace-4.6.1-0.1.fc14.i686 kdelibs-4.6.1-0.1.fc14.i686
the bug still exists here with 4.6.1 and gentoo amd64 ...
i dont use the kde hotkey functionality and when i start an app from xbinkeys the taskbar doesnt autphide itself randomly - i cant reproducte it - it only happens every now and then - btw i use the kickoff style
If you really insist on keeping this "feature", you should add a setting to disable it completely or set a timeout after which the panel will start hiding again even if the app doesn't clear the lock. And if you'd like my opinion, I'm all for dropping this "feature" completely. It's not worth the trouble it has caused so far.
This bug is not anywhere near fixed in KDE 4.6.1. I want the panel to HIDE and STAY HIDDEN until I give indication that I WANT IT to appear by moving the mouse to the bottom of the screen. Now I start some app and it pops up and it STAYS THERE FOREVER. KDE doesn't have a (work) auto-hide panel feature at the moment. It's not like this problem is very hard to see (atleast not on my Gentoo box), I wanted to try if it had gotten any better since 4.6.0 and it took me like 2 minutes to get the panel stuck and go back to fluxbox. Don'ẗ think I'll be checking if KDE is usable again until 4.6.2 or maby I'll just check this bug a few days after that comes out and see if I should just wait until 4.6.3 because of this bug. It really does make KDE useless.
Aaron merged a reworked version of the panel auto hiding into git master. The more people give feedback about it, the higher the chance for a backport.
To avoid other cc'ed people the hassle of to find the right commit, here's a link: http://quickgit.kde.org/?p=kde-workspace.git&a=commit&h=f506210c74ab65c8bb1d6de3b2332d374c7cbfcc
the diff doesnt apply cleanly but i "ported" the two failed hunks - patch attached - works like a charm with 4.6.1 :) - now the pannel hides again even when the app that wants attention isnt selected ...
Created attachment 58167 [details] the patch applies fine on plasma-workspace-4.6.1
Created attachment 58168 [details] second version without the .orig file
Tested and now panel hides itself again after 3sec and the problem where killing application requesting focus prevented panel from hiding completely, seems to be gone.
hope it will make it into 4.6.2 this is realy annoying because often it covers buttons of windows which are "under" the panel
The panel does no longer get stuck, and I didn't notice any new (serious) problems. The only minor problems in my setup (panel at the right with a width of 145 pixels) are: Initially, a vertical blue edge highlight appears at ~300 pixels from the right screen margin if I have moved the mouse to the active zone and out again, with no panel anywhere near. The problem goes away after half a minute or something, in which time the GUI seems to be quite busy and slow. This initial slow-down seems to be new, but I'm not entirely sure. In any case, for me this patch is a major improvement.
I've just rebuilt kdebase-workspace-4.6.1-5.fc15.src.rpm with this patch on my Fedora14 box and all is working fine with the panel now. Thanks..
Thursday, March 31, 2011: KDE 4.6.2 tagging Any plan to backport the patch to branch 4.6 in time for 4.6.2 release?
The patch has been backported in time for 4.6.2: http://quickgit.kde.org/?p=kde-workspace.git&a=commit&h=b239193e10195b13943686f39a186cd29fbf7e24 kudos to Aaron Seigo
*** Bug 262592 has been marked as a duplicate of this bug. ***
*** Bug 270145 has been marked as a duplicate of this bug. ***
After a few days testing KDE 4.6.1 I was left with the impression that this bug was fixed. Yet, just now I've experienced the very same problem, with the taskbar being stuck on always on although the option that was set was for it to hide automatically. The taskbar got unstuck by restarting KDE, though. Regarding the new popup behavior that the taskbar exibits, it would be great if that was taken away as it's very annoying. The problem isn't necessarily due to the taskbar popping up once in a while. The problem is that the taskbar gets "stucked" on display until the newly activated window, the one that triggers the taskbar display, gets some focus. That is terribly annoying as it screws up with the workflow.
After a week of daily use of 4.6.2, i can confirm that auto hiding works just fine. Imho this bug can be marked as fixed
yay
I'm seeing this on Ubuntu 13.04: mcicolap 2001:$ kded4 --version Qt: 4.8.4 KDE Development Platform: 4.10.5 KDE Daemon: 4.10.5 It seems that when I edit the panel properties it gets stuck and won't auto-hide.
The Taskbar does not autohide consistently, this is not a fixed issue. Operating System: Fedora Linux 37 KDE Plasma Version: 5.26.5 KDE Frameworks Version: 5.102.0 Qt Version: 5.15.8 Kernel Version: 6.1.7-200.fc37.x86_64 (64-bit) Graphics Platform: Wayland (but also on Kubuntu and KDE neon)
*** This bug has been marked as a duplicate of bug 362105 ***