wine's fullscreen code has no effect on metacity
dmitry at codeweavers.com
Fri Jul 14 02:43:33 CDT 2006
"Havoc Pennington" <hp at 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
> 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
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.
More information about the wine-devel