I think the screenshot is the best description. If I undock toolbars of an application, they are "always on top", even if the application they belong to is in the background or even minimized. Much better would be if they would automatically disappear as soon as the window goes into the background, just as it's the case with e.g. the undockable sidebars/"sub-windows" of Dolphin and Amarok. Reproducible: Always Steps to Reproduce: 1. Undock toolbars of one application 2. Open another application 3. Actual Results: The toolbars stay on top. Expected Results: The toolbars disappear or at least don't stay on top.
Created attachment 75864 [details] A screenshot of the issue.
They're supposed to be on top of their parent, or if that doesn't exists the group, and they act like that here (git master) - however, the focus is not tied to the layer (ie. a window can be activated w/o being risen) please from konsole run "xprop | grep _NET_WM_WINDOW_TYPE", click the toolbar and post the output devnote: since KDE toolbars (should) have _NET_WM_WINDOW_TYPE_TOOLBAR, _NET_WM_WINDOW_TYPE_UTILITY, _KDE_NET_WM_WINDOW_TYPE_OVERRIDE, _NET_WM_WINDOW_TYPE_NORMAL it's very well resonable to cover them by the "hide utility windows" setting, since they're utility windows as well.
Output is: $ xprop | grep _NET_WM_WINDOW_TYPE _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_TOOLBAR, _NET_WM_WINDOW_TYPE_UTILITY, _KDE_NET_WM_WINDOW_TYPE_OVERRIDE, _NET_WM_WINDOW_TYPE_NORMAL
That's expected. If you raise a client and unless the toolbar is marked to be kept above[1] it should not remain above the risen client. What focus policy do you use? (click to focus, focus follows mouse etc.) and do you raise clients with clicking / activating them? [2] [1] xprop | grep _NET_WM_STATE [2] see "kcmshell4 kwinoptions", that's a config dialog you'll also find in systemsettings
I'm using "click to focus". The way I rise clients doesn't affect the behaviour. The toolbars just stay at the top no matter what I do.
- Are they tagged to stay on top? (see second xprop grep) - Do you have any related rules in "kcmshell4 kwinrules"? (eg. alter the type of toolbars to docks or tag them to stay on top)
I have no special settings done. The issue is application independent, as long as it's a KDE application. As of today, newly dragged out toolbars aren't automatically on top anymore? Strange thing. But when opening an application where it's already dragged out the problem is still there: 1. The toolbar is always-on-top and locked, even though the option "lock toolbars" in context menu is unchecked 2. Check that option and uncheck it again 3. Move the toolbar around a bit 4. Toolbar is now no longer "always on top", unless opening a new window of that application or restarting it -> go back to 1.
Yupp that happens - on first sight, it seems due to some motif hint, but could also be the override type. The window is basically treated as "unmanaged" (you can eg. also not move it around with alt+lmb)
The window is indeed initally unmanaged (MapNotify just informs the WM that it's now there) and turns into a managed Toolbar (additional MapRequest) once you unlock and drag it around. The behavior is the same with openbox & compiz (and expected as unmanaged windows should be on top of the stack) => either bug in (rather) Qt/QToolBar or KDE/KToolBar There's unfortunately no workaround from kwin, since we don't manage the problematic window in the first place (ie. don't really touch it) Moving to kdelibs with request to escalate it to Qt in case.
Bug 283030 has additional analysis.
*** Bug 283030 has been marked as a duplicate of this bug. ***
I experiencing similar behavior with detached toolbars with Qt application on Ubuntu 13.10 (Unity). My application restores main window geometry and state on startup and saves them on quit. If toobar was detached when application quits, next run of application will restore toolbar that will be visible on all workspaces and will be above all windows. Attaching test application. To reproduce this behavior you can: 1. Start test application. 2. Detach toolbar from main window. 3. Close application. Application will save it's state in "state.dat" file in current directory. 4. Start test application. It will load state from "state.dat" file --- toolbar will be detached. Now detached toolbar is above all windows and visible on all workspaces.
Created attachment 83931 [details] Test Qt application that reproduces bug
Resetting Qt::X11BypassWindowManagerHint flag and showing toolbar makes toolbar behave normal, so this can be used as workaround in test application: // Do this at the end of MainWindow::MainWindow() in test application, after restoring toolbar state: toolbar->setWindowFlags(toolbar->windowFlags() & ~Qt::X11BypassWindowManagerHint); toolbar->show();
I can confirm this bug with KDE 4.13.3 (konqueror 4.13.3, dolphin 0.19.3) with Debian.