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

["Elijah Newren" <newren gmail com>]

On 7/7/06, Havoc Pennington <hp redhat com> wrote:
> Dmitry Timoshkov wrote:
> > An algorithm in Wine which asks a WM to activate fullscreen state for
> > a window is quite simple: it checks the size of a just resized visible
> > window and if it's equal or larger than screen size sends an event to
> > a WM. We are trying to understand at the moment why metacity sometimes
> > ignores such a request: window size and visibility should not be a reason
> > for it (except if metacity expects a window to have exactly same size as
> > the screen has, not larger than that), probably window decorations or
> > something else do.
>
> Currently what appears to be triggering the issue in metacity is that
> the window's minimum and maximum size are also changed, such that the
> window is not resizable. There's an exception to this rule if the window
> is already fullscreen-size, but the exception kicks in only for
> undecorated windows.
>
> I'd try just removing the !decorated line from metacity, or testing this
> theory by building a version of WINE that disables decorations in this
> case, just to see if it helps.

I'm pretty sure that would fix this issue for WINE apps, since WINE is
manually sending a please-put-this-app-in-fullscreen-mode message on
behalf of the app.  We should probably also fix the heuristics in
src/stack.c:window_is_fullscreen_size() as well for other apps.  (The
difference between the two pieces of code is _allowing_ an app to be
fullscreened in the first case, and automatically making an app be
fullscreen without it properly requesting it in the second)  I filed
this pair of issues at
http://bugzilla.gnome.org/show_bug.cgi?id=346927.

> > On the related note: any idea why adding _NET_WM_STATE_ABOVE to a
> > window makes it cover the GNOME dock, but GNOME top panel still
> > remains on the top?
>
> afaik the top and bottom panels should always be in the same layer (so
> both above or both below). Elijah would know better though.
>
> ABOVE windows can be below the panels if they don't have focus iirc.

As per the EWMH suggestions, stacking order is layered according to
 * windows of type _NET_WM_TYPE_DESKTOP
 * windows having state _NET_WM_STATE_BELOW
 * windows not belonging in any other layer
 * windows of type _NET_WM_TYPE_DOCK (unless they have
   state _NET_WM_TYPE_BELOW) and windows having state
   _NET_WM_STATE_ABOVE
 * focused windows having state _NET_WM_STATE_FULLSCREEN

Windows within a layer are reordered according to use (e.g. user
clicks on the window and it gets raised above other windows within the
same layer).  Since windows with the above type are in the same layer
as docks, it's not at all surprising that panels will be below type
above windows sometimes and above them at other times.  To have docks
always below (or alternatively always above) windows of type above,
the two types would have to be sorted into separate layers.


Hope that helps,
Elijah