| Summary: | Toolbar appears above all windows when deattached from main window | ||
|---|---|---|---|
| Product: | [Unmaintained] kdelibs | Reporter: | artem <artem.rizhov> |
| Component: | kdeui | Assignee: | kdelibs bugs <kdelibs-bugs> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | kwin-bugs-null, rutsky.vladimir |
| Priority: | NOR | ||
| Version: | 0.1 | ||
| Target Milestone: | --- | ||
| Platform: | Ubuntu | ||
| OS: | Linux | ||
| See Also: | https://bugs.kde.org/show_bug.cgi?id=357213 | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: |
The kontact/mail toolbar is above the active konsole window
Outout of `xprop` Outout of `xprop -id` |
||
|
Description
artem
2011-09-29 12:24:46 UTC
open konsole,
call "kcmshell4 kwinoptions", enter the last tab - is "hide utility windows..." checked?
call "xprop > nasty_tool.txt" and click the nasty toolbar.
call "xprop | grep TRANSIENT" and click it again
The last item in the output should be a hexadecimal number ("0x123456"), we'll name it "<hex_num>", last
call "xprop -id <hex_num> > nasty_tool_leader.txt" (only the last '>' is really a '>' - the rest is part of the number figured above)
and attach nasty_tool.txt and nasty_tool_leader.txt to the bug
Created attachment 64073 [details]
Outout of `xprop`
Created attachment 64074 [details]
Outout of `xprop -id`
> call "kcmshell4 kwinoptions", enter the last tab - is "hide utility windows..." checked? Yes > and attach nasty_tool.txt and nasty_tool_leader.txt to the bug Done The windows look ok. - Can you raise konsole above the toolbar? - Is the toolbar interactive (ie. does it react on clicking icons _w/o_ activating the kontact mainwindow first? - Does it happen with compositing suspended? (shift+alt+f12) - Does it happen with other UI styles (eg. "kontact --style plastique")? - Do you use tabbing and/or tiling features of kwin? > - Can you raise konsole above the toolbar? No. Even if I activate the "always on top" feature. > - Is the toolbar interactive (ie. does it react on clicking icons _w/o_ > activating the kontact mainwindow first? Yes, it's interactive and works well even when the kontact window is minimized. And the toolbar is shown on all desktops and rooms. > - Does it happen with compositing suspended? (shift+alt+f12) Yes. No changes when I suspend compositing. > - Does it happen with other UI styles (eg. "kontact --style plastique")? Yes > - Do you use tabbing and/or tiling features of kwin? No The toolbar is still there even after restarting kontact. Maybe this is related somehow. If I unlock the toolbar and click a button on it, it appears locked again. However the context menu item shows that it's not locked still. So I have to lock and unlock again to make it possible to move the toolbar. The problem had disappeared when I unlocked and moved the toolbar. And I was not able to reproduce the bug. However it returned just after restarting kontact. Interesting. I get the very same with konqueror when changing tabs. The toolbar is hidden and reshown with the tab switch (since it's somehow virtually part of that tab) and looses the locking representation (just as you mentioned - but that is a client issue only, ie. ktoolbars fault) and also sticks above the desktop.... well, at least i can add some debug code to watch what's going on there ;-) Great. I just tried and have got exactly same problem in konqueror. And I have two sticky toolbars now! :) Good luck with debugging! Ok, i know what's going on but it's likely a client bug (will test the client side next) When changing tabs in konqueror, the toolbar receives an upmap request and is released by kwin but never gets a following maprequest when remapped - thus remains completely unmanged by kwin what likely means it uses the Qt::X11BypassWindowManagerHint (or there'd be a major problem with event processing) Filtering QEvent::Show shows that "widget->windowFlags() & Qt::X11BypassWindowManagerHint" is true when a) the toolbar is dragged out (expectable - likely a Qt thing and ok, since the toolbar is re-shown w/o this flag) b) the toolbar is withdrawn and re-shown when switching tabs in konqueror (i expect the very same to happen for kontact but maybe other causes) As a result of (b) the toolbar is not considered by kwin when de/activating the main window. This is not a kwin bug, since the window maps directly, bypassing the WM as the set flag suggests. -> Reassigning & confirming. forgot to reset the mail assignment ... :S Does it make sense to change the status from NEW to OLD ? :) *** This bug has been marked as a duplicate of bug 311768 *** |