- configure Window menu integration in window decorations - get any program that opens the File menu with alt+F - go to fullscreen - activate the file menu (nothing happens) - exit fullscree (now the menu is visible)
I can reproduce. Obviously the full screen window is ontop of everything. Martin, any idea how I can get the app menu raised above? I tried Qt::WindowStaysOnTopHint for the menu but didn't help
(In reply to Kai Uwe Broulik from comment #1) > I can reproduce. Obviously the full screen window is ontop of everything. > Martin, any idea how I can get the app menu raised above? I tried > Qt::WindowStaysOnTopHint for the menu but didn't help There's only one way: it needs to be a transient for the window it belongs to.
Figured that but we explicitly got rid of the WinId stuff in global menu.. but then we also need an even more broadscale solution for Wayland (foreign window thingie).
(In reply to Kai Uwe Broulik from comment #3) > Figured that but we explicitly got rid of the WinId stuff in global menu.. > but then we also need an even more broadscale solution for Wayland (foreign > window thingie). Now comes the crazy part: on Wayland that's easier. There's the XdgExporter (https://api.kde.org/frameworks/kwayland/html/classKWayland_1_1Client_1_1XdgExporter.html ) and XdgImporter class in KWayland. The application would export the window (e.g. Plasma-integration could do that), pass the exported string through a side channel (e.g. dbus) to Appmenu, which uses the XdgImporter to mark the menu as a transient to the window. Now in theory we could pass also an X11 window id through this mechanism. E.g. a string "x11/12345" could be used by KWin to map the X11 window 12345 in the same way.
That's what I was looking for. Cool.
This bug was reported against an outdated version of KWin. We have made many changes since the. If the issue persists in newer versions can you reopen the bug report updating the version number.