Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!rutgers!ucla-cs!zen!ucbvax!ZERMATT.LCS.MIT.EDU!RWS
From: RWS@ZERMATT.LCS.MIT.EDU (Robert Scheifler)
Newsgroups: comp.windows.x
Subject: re: Proposed Protocol Change to WarpPointer
Message-ID: <870731085659.4.RWS@KILLINGTON.LCS.MIT.EDU>
Date: Fri, 31-Jul-87 08:56:00 EDT
Article-I.D.: KILLINGT.870731085659.4.RWS
Posted: Fri Jul 31 08:56:00 1987
Date-Received: Sat, 1-Aug-87 21:57:25 EDT
References: <8707301918.AA07785@audi.siemens.uucp>
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 31


    Date: Thu, 30 Jul 87 15:18:50 EDT
    From: ellis@audi (Ellis Cohen)

    Proposal: That the semantics of WarpPointer be modified slightly,
	      so that if dst-window is None, then <dst-x,dst-y> are
	      taken to be relative to the current pointer position,
	      providing a relative warp.

The semantics of always moving relative to the current position strikes
me as undesirable and non-intuitive.  I've worked on a program with a
warping user interface (V10 xgedit).  The program admittedly sucks in
various ways, but that isn't the issue here.  I found the most natural
behavior (to me) was obtained by using the conditional semantics of the
warp, namely, warp the pointer to this particular spot, but *only* if
the pointer is still (approximately) where it was at the time of the
command.  Indeed, working on that program instigated the addition of
conditional semantics.  Example, the user types "snap to grid" in xgedit
and then moves the pointer to position the next point.  Very undesirable
if a slow xgedit now wakes up and moves the pointer, whether or not it
is back to some absolute position or relative to the current position.
Example, the user types "snap to grid", and then before xgedit can
react, the user gets distracted by some new frob on the screen and moves
the pointer over to some completely different window and is about to
click on some item.  Now xgedit finally wakes up and unilaterally causes
the pointer to unilaterally warp, and the user clicks on the wrong
thing.  Bad behavior, whether it is to an absolute position or to a
relative position.  These scenarios actually happened to me prior to
defining and using the conditional nature of warp.

Can you provide a concrete example of where this effect is desirable?