Path: utzoo!attcan!uunet!lll-winken!xanth!ukma!tut.cis.ohio-state.edu!bloom-beacon!SUN.COM!dshr
From: dshr@SUN.COM (David Rosenthal)
Newsgroups: comp.windows.x
Subject: Re: SubstructureRedirect & server out of sync bug
Message-ID: <8903031937.AA04534@devnull.sun.com>
Date: 3 Mar 89 16:25:50 GMT
Sender: daemon@bloom-beacon.MIT.EDU
Organization: The Internet
Lines: 32

> Consider a toolkit which needs to warp the pointer for some reason.

It had better be a very good reason indeed.  The ICCCM convention saying
that clients should not warp the pointer is not to be disregarded lightly.
After all,  we all want to be able to claim "ICCCM compliance",  don't we?

> An example would be when input objects are "chained" together;
> hitting <CR> on one entry may imply warping the pointer into the next
> one to activate input (yes, there are other ways to change the focus...).
> 
There are indeed other ways to use the focus and you had better use
one of them.  A client warping the pointer is never an acceptable method of
transferring the input focus,  neither to its top-level window nor
among its sub-windows.  If you want to transfer the focus,  use the
requests that do so.  If you want to warp the pointer,  do so because
you want to warp it,  not because you want some side-effect that you think
is going to happen when you do.

> In any case, the toolkit knows nothing of what the application has been
> doing.  In particular, it does not know if the application has moved some
> arbitrary ancestor of the destination window for the warp.  As a
> consequence, the toolkit does not know if anything has happened at all,
> so it doesn't know whether to wait for the ConfigureNotify or not; and
> it has no idea of which ancestor it should look for it on.
> 
This is a good example of one of the reasons why the ICCCM specifies that
clients should not warp the pointer.  Although,  to be fair,  it is the
application you envisage that is buggy.  It is moving the window;  it
has the responsibility to do so safely (i.e. by selecting for and
observing the ConfigureNotify).

	David.