wine's fullscreen code has no effect on metacity

[Havoc Pennington]

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