"Havoc Pennington" hp@redhat.com wrote:
to shift it below the top GNOME top panel by 25 pixels (btw,
that's why I wrongly thought that the top GNOME top panel remained above in Z order of the main game's window, actually they do not overlap each other).
Metacity does this with all windows (keeps them below the panel) unless there's some reason not to (such as fullscreen); it's a longstanding UI decision.
It's OK that a WM constrains windows to be placed inside of its work area but still allows to place them into a fullscreen state on request. How would you suggest to properly inform a WM that a window needs to be in a fullscreen state? Does metacity ignore ClientMessage/_NET_WM_STATE_FULLSCREEN request due to 'fullscreenable = 0' or something else?
Last line above confuses a lot: why WM behind our back maps a window? What may be a reason behind that?
From the metacity log, it looks to me like WINE here withdraws the window, turns on window decorations, then remaps the window.
Metacity then has to unmap/map one more time in order to place the window inside its window frame. Undecorated windows don't have a frame so don't have the extra unmap/map caused by reparenting, but normal windows do.
Thanks for the explanation, now the behavour I see in the log looks reasonable to me: a window gets mapped/unmapped in a succession, and actually Wine handles that correctly since it has an internal visibility state for each window. This answers the question (2) as well.