Re: wine's fullscreen code has no effect on metacity

[Havoc Pennington <hp redhat com>]

Dmitry Timoshkov wrote:
> 1. Why the WM thinks that it knows better than the app where to place 
> its window
> and insists on moving it to another position? That's not a user related 
> interaction
> related to moving a window using mouse or a keyboard, IMO the WM should 
> not do
> this kind of things behind applications back.
>
> 2. How that could happen that the WM maps a window to the screen 
> although it
> clearly was not asked to?
>
> I hope that the log above will help to shed some light into the 
> investigated
> problem and will allow to find a resolution to it.

I can't tell enough from this log, because remember things are 
asynchronous. So we don't know what information metacity already had or 
did not have at each point in the log. i.e. WINE may think it said "hide 
the window" then get a configure notify, but metacity may have sent the 
configure notify BEFORE the window was hidden. (Just an example.)

I'd suggest getting a new WINE log but with metacity verbose logging on 
also. Then we'll have the exact same run of this app from both sides of 
the issue and we can tell exactly what happened during that run of the 
app. Metacity verbose log will mention all the property changes and 
configure requests and so forth.

btw the "synchronous" vs. "asynchronous" API impedance mismatch is a big 
problem; I worked with the Eclipse project on this years ago, where they 
had it with SWT vs. GTK. Though they did not afaik use the advice we 
gave them, which was to leave X/gtk working asynchronously but have a 
"write-through cache" of the server side state so things looked 
synchronous from the SWT point of view.

Of course the most robust approach is to design any API that has to run 
on top of X to have async semantics, but that's not an option with 
exisitng APIs like SWT or win32.

Havoc