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

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.


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