Re: wine's fullscreen code has no effect on metacity

["Dmitry Timoshkov" <dmitry codeweavers com>]

"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.

--
Dmitry.