Re: GTK frame changes

["Stephen J. Turnbull" <stephen@xemacs.org>]

grischka writes:
 > Jan Djärv wrote:

 > > The XProtocol specification (the oldest I have is R6.8, the newest is 
 > > 7.4, they say the same thing) says this:
 > > 
 > > "Whether or not a server is implemented with internal
 > > concurrency, the overall effect must be as if individual requests
 > > are executed to completion in some serial order, and requests
 > > from a given connection must be executed in delivery order (that
 > > is, the total execution order is a shuffle of the individual
 > > streams).

Jan is missing a number of issues, I think.  First, there are (at
least) two clients and *two* connections involved here.  One is
Emacs's, the other is the WM's.  This leaves a lot of room for
nondeterminism ("shuffling") in the order in which configuration
events arrive on Emacs's connection.

Second, the process that generates the ConfigureNotify event is *not*,
and cannot be, atomic.  When the WM has set the SubstructureRedirect
flag on the root window, a request by Emacs to configure one of its
(X) windows will propagate up the toolkit hierarchy to a shell window,
which will then execute X protocol.  However the reaction of the
server to that protocol request is *not* to configure the window and
send a ConfigureNotify event.  It is to *do nothing* except send a
ConfigureRequest event to the window, which will be processed by the
WM (because of the substructure redirection), not Emacs.  The WM *then
issues the configuration request again*, which will succeed this time
because the WM "owns" the substructure redirection.

 > I'm somehow confused what they mean by reply here.  If events are sent
 > before replies then replies must be something else.

Yes.  An event is sent as a reaction to something that happens to or
in a window.  A reply is something that the server says as an
informational matter in response to a request, which doesn't need to
specifically refer to any window.

 > Just with WM redirection (metacity here) the ConfigureNotify
 > clearly arrives about 2 ms later and the behavior is completely
 > unimpressed by XSync.

"metacity"?  As a developer of an X client, that's not my favorite
WM....  metacity's idea of "well-behaved" is a bit more restrictive
than fdo's standards specify.