"Havoc Pennington" hp@redhat.com wrote:
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.
I'm attaching 2 logs: 1st one is a Wine log (thief.log.bz2) produced by running
WINEDEBUG=+win,+xrandr,+event,+x11drv,+synchronous ~/wine/wine THIEFD.EXE
i.e. this log avoids an issue with asynchronous X behaviour, Wine calls 'XSynchronize( display, True );' on startup once it sees '+synchronous' in the debug switches.
The 2nd is a metacity log (metacity_verbose.log.bz2) produced by starting X session with METACITY_VERBOSE=1, running Wine with the above debug switches. I've stripped the log by removing everything before 1st appearance of the window id 0x2200001 in the log and aftre destruction of that window.
Please let me know if you need anything else.
Thanks.