wine's fullscreen code has no effect on metacity

[Dmitry Timoshkov]

"Havoc Pennington" <hp at redhat.com> wrote:

>>> Anyway, few WM bugs can be resolved by appeal to specifications alone...
>> 
>> Ok, let's appeal to the fact that Wine's fullscreen stuff works in KDE and
>> doesn't in GNOME :-) If you could point out what Wine is doing in wrong way
>> I'm all ears.
> 
> Don't get defensive, everyone is completely willing to change metacity.
> All I'm saying is that there's no point trying to appeal to specs in 
> this case.

That's completely understood.

> There's no question that we need some heuristic "try to detect legacy 
> apps" code which the spec in no way covers. KDE also has some heuristic 
> code for this sort of thing, as does any reasonable window manager. As 
> with any heuristic it's a little touch-and-go/trial-and-error.
> 
> I believe several WMs including KDE and metacity have code something like:
>  - if a window resizes itself to fullscreen,
>    assume fullscreen state was intended
> 
> This heuristic can have various tweaks, such as only assuming fullscreen 
> if the window is undecorated.
> 
> From other posts, I gather that WINE pretty much has this same 
> heuristic internally, because the windows API doesn't have a fullscreen 
> state, just "screen sized + on top"

That's correct, except that window size may not match the screen size
accurately, window size may be larger that screen, because applications
sometimes instead of removing window decorations (caption and borders)
simply resize a window so that client window area covers the screen.

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.

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?

Thanks for your help.

-- 
Dmitry.