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

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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]