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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]