wine's fullscreen code has no effect on metacity

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.

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

Havoc

_______________________________________________
metacity-devel-list mailing list
metacity-devel-listgnome.org
http://mail.gnome.org/mailman/listinfo/metacity-devel-
list

On 7/7/06, Havoc Pennington <hpredhat.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
htt
p://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
_______________________________________________
metacity-devel-list mailing list
metacity-devel-listgnome.org
http://mail.gnome.org/mailman/listinfo/metacity-devel-
list