wine's fullscreen code has no effect on metacity
Havoc Pennington
hp at redhat.com
Tue Jul 11 13:44:50 CDT 2006
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
More information about the wine-devel
mailing list