Compiz has made a workaround available in git for this issue.<br><br><a href="http://gitweb.opencompositing.org/?p=fusion/plugins/workarounds;a=commit;h=ddea8b07cf3046e2bb72dd5bc5161a6d24ef9f16">http://gitweb.opencompositing.org/?p=fusion/plugins/workarounds;a=commit;h=ddea8b07cf3046e2bb72dd5bc5161a6d24ef9f16
</a><br><br><br><div><span class="gmail_quote">On 10/9/07, <b class="gmail_sendername">Alexandre Julliard</b> <<a href="mailto:julliard@winehq.org">julliard@winehq.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Michael Jung <<a href="mailto:mjung@iss.tu-darmstadt.de">mjung@iss.tu-darmstadt.de</a>> writes:<br><br>> It seems that the added "data->whole_window" check in the expression<br>> used to decide if a window has to be switched to managed mode causes
<br>> this problem for me.<br>><br>> data->whole_window is set in create_whole_window at window.c:1002<br>> create_whole_window is called from X11DRV_CreateWindow at window.c:1292<br>><br>> data->whole_window is tested in X11DRV_SetWindowPos at
winpos.c:251<br>> X11DRV_SetWindowPos is called form X11DRV_CreateWindow at window.c:1287<br>><br>> Thus, it seems to me that this check happens before<br>> "data->whole_window" is initialized. Removing this check (as in the
<br>> attached patch) resolves the issue for me. But this does not seem to<br>> be the correct solution, since the root desktop window is now flagged<br>> as "managed", which does not have any impact (at least for me), but
<br>> which seem logically incorrect.<br><br>That's just hiding the problem. If the window manager doesn't<br>reevaluate the wm hints when the window is mapped, many things won't<br>work. That's really a Compiz bug IMO.
<br><br>--<br>Alexandre Julliard<br><a href="mailto:julliard@winehq.org">julliard@winehq.org</a><br><br><br></blockquote></div><br>