Peter, thanks a lot for your valuable input. The more I think about it, the less does it seem to be an issue for us anyway, since instantaneous calls to changing a window's visibility and then reading its states again is very unlikely to happen in the deployed environment. I just stumbled across this behavior when running a unit test where I do something like this: 1. set some visibility state, e.g. maximize a window 2. read the states the WM set for this window 3. assert that the proper states are set for this window Since these steps happen in a matter of milliseconds, there is simply not enough room for the window manager to catch up. But, as I said, this is very unlikely to happen in the actual program so I'll just ignore it for now. Best regards, Matthias <div>2007/11/9, Peter Hutterer <<a href="mailto:mailinglists@who-t.net">mailinglists@who-t.net</a>>:<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Matthias Käppler wrote: > What if the client triggers a state change and some other client wants to > retrieve information about that window shortly thereafter? I need pull > semantics where clients are able to retrieve the currently active states > instead of pub/sub semantics. the problem is not unfamiliar to the synchronisation issues in multithreaded environments. you're basically calling for making the action and setting of the property an atomar operation. this is hard enough for simple operations like incrementing a variable, making something complex like changing a window's properties a window and then setting an atom on the X server indivisible doesn't make it easier. so no - I don't think there's a way to get around it. Cheers, Peter </blockquote></div> -- Matthias Käppler Research Assistant Knowledge Management Group DFKI GmbH, Germany