wine's fullscreen code has no effect on metacity

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

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"

In addition to whether a window is currently fullscreen,
metacity cares 
whether a window can be fullscreened (so it knows whether to
offer the 
keybinding, etc.).

So that's the algorithm in recalc_window_features() that
may need some 
tuning, since apparently on Windows fullscreen apps still
have 
decorations. (Or this is the hypothesis I threw out there.)

Now, the 100% correct app behavior IMO would be to not
change the size 
hints or the window size when the fullscreen hint is
advertised as 
supported by the WM. This allows the WM to remember the
pre-fullscreen 
size and support restoring to it, and allows the WM to allow
users to 
leave the fullscreen state.

WINE can't be fixed to be really right I gather, since the
Windows API 
does not provide enough information. There's an
"impedance" problem.

So someone will need to tweak recalc_window_features a bit
in metacity. 
It's not a big deal. An alternative fix might be to extend
the WINE 
heuristic to ignore the app's setting the size on the
window and instead 
convert it _solely_ into a fullscreen state request. Either
way, we're 
talking heuristics and not specs.

>> If nothing else, in modern desktops it's quite
hard to tell which 
>> configure requests are user-originated and which
are not.
> 
> That one is simple: if a request is being originated by
a user interaction
> it's a user's request and might be restricted; if
it's a result of an API
> call it's done programmatically and should be executed
by all means.
> 

The WM has no reliable idea whether a request was originated
by a user 
interaction, because not all user interactions are
originated through 
the window manager. Years ago in "strict
compliance" mode metacity used 
to deny all application configure requests entirely, and it
broke a lot 
of stuff including things users felt they had asked for.

There's also a social problem, which is that if you ship a
WM that only 
honors user-originated requests, all the app authors will
start setting 
the "user originated this" flag so you honor
their requests anyway.

It's kind of a lost cause for that reason. I did try it
experimentally 
though when first coding metacity.

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