Bug 366278

Created attachment 100390 [details]
Screen capture showing problem

Some sort of strut problem, Martin?

Unfortunately I am very new to Qt/KDE/Plasma internals and not familiar with the term "strut".
Light Googling suggests it means a "keep out" area?

I would say that it's a Z-order issue rather than a "keep out" issue. Consider a case where I have a full-screen application minimized to the task bar. If I unhide the taskbar and restore the application, I would like it to use the entire desktop, including the area behind the taskbar. So, in that regard, the taskbar should not be considered a "keep out" area.

FWIW, on Windows (where I also have an auto-hide taskbar and I'm using Classic Start Menu to emulate Win2K cascading menus,) the submenus are displayed in front of the taskbar.

Oh, sorry about the confusion - I was asking the Martin I added to the CC list for technical input :)

(In reply to Eike Hein from comment #2)
> Some sort of strut problem, Martin?

IIRC auto-hiding panels don't set struts. This rather looks like an incorrect transient problem to me. The sub-menu should be a transient to the main menu, which should be a transient to the panel. If that's all setup correctly the windows should all be in the same layer and above the panel.

^ Thanks!

Git commit 433b6794fe8c08fee91dd8d307604ae0207d14c5 by Eike Hein.
Committed on 02/08/2016 at 10:20.
Pushed by hein into branch 'master'.

Add Qt::Dialog to default flags to make QXcbWindow::isTransient() happy.

Panel popup dialogs along with other applications of Plasma::Dialog
(e.g. Kicker's submenus) currently don't correctly set WM_TRANSIENT_FOR
to the id of their parent window on X11. This causes them to interact
badly with auto-hide panels which do not set struts, e.g. Kicker's
submenus open behind the panel.

Internally, Dialog makes calls to QWindow::setFlags when its window
type is "Normal" (the default) and otherwise uses KWindowSystem's
setType. (Kicker's subclass, SubMenu, does an additional
KWindowSystem::setType call for NET::Menu). Neither CompactApplet
nor Kicker change their Dialog's 'type' property to anything else,
so their dialogs are "Normal", thus going the setFlags route with
no setType calls.

Dialog also sets its transient parent to the window the visualParent
item is inside of.

Now here is where things break down: QXcbWindow will update
WM_TRANSIENT_PARENT for in show(), but only when an inline function
called isTransient returns true. isTransient decides this based on
window type, which is determined from the flags set with
QWindow::setFlags. Calls to KWindowSystem::setType would have no
bearing on this; there seems to be no mapping back from external
state. This is why setting Dialog.type to e.g. "DialogWindow" does
nothing.

This patch takes the route of adding Qt::Dialog to the starting
flags - after all Dialog is a dialog. That means isTransient()
will consider the window to be a transient and those
setTransientParent calls Dialog does will not be ignored. In the
case of CompactApplet, no further calls to KWS::setType are done;
Kicker continues to call it with NET::Menu to get desired window
manager behavior.

In light testing everything still seems too work, with the added
benefit of fixing:

That said, the weird mess of setFlags and setType and state in the
windowing system vs. Qt is horrible and sad.

REVIEW:128571

M  +1    -1    src/plasmaquick/dialog.cpp

http://commits.kde.org/plasma-framework/433b6794fe8c08fee91dd8d307604ae0207d14c5