Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!rutgers!ames!ucbcad!ucbvax!audi.mit.EDU!ellis
From: ellis@audi.mit.EDU (Ellis Cohen)
Newsgroups: comp.windows.x
Subject: re: Proposed Protocol Change to WarpPointer
Message-ID: <8707311548.AA08410@audi.siemens.uucp>
Date: Fri, 31-Jul-87 11:48:43 EDT
Article-I.D.: audi.8707311548.AA08410
Posted: Fri Jul 31 11:48:43 1987
Date-Received: Sun, 2-Aug-87 00:58:21 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 46

>  The semantics of always moving relative to the current
>  position strikes me as undesirable and non-intuitive.
>  Can you provide a concrete example of where this effect
>  is desirable?

In our tiled window manager, we have a move gadget
to the right of the title bar.
Clicking on the gadget warps the pointer to the
middle of the window.
The user then moves the pointer to another place
on the screen and clicks again, and this location
becomes the new center location of the window.

In earlier versions of the manager, we did not warp
the pointer.  Based on experience with user's, we added
warping for two reasons.

   1.  The warp made it clear to the user right away that
       we were doing a center move -- i.e. that the moved
       location of the pointer would be the new window center.

   2.  Some users would inadvertantly click twice, or would
       click so slowly that we would treat the down and up
       press as distinct button events.  Either would cause
       the move to be completed.  Because the pointer was
       warped to the center, the window would simply stay in the
       same place in this case.  In a tiled window system, this
       is especially important, since a move can cause side
       effects -- changing the size and/or location of other 
       windows.

You might argue that instead of warping the pointer, we could
simply blank it out, and track along with our own cursor suitably
displaced from the pointer.  There are a number of problems with
this approach.  First of all, there are timing problems -- at best
feedback may be flaky, at worst, the user may click at the wrong
location (our cursor hasn't caught up with the pointer).
More seriously even than that is the problem that the pointer can't
move outside of the screen, and so our cursor wouldn't be able
to move near the top or right edges of the screen.  Our move has
some semantics (similar to MicroSoft windows) that make it
essential that the cursor be able to be moved to edge of the screen
(basically, it pushes the window that is at the edge out of the way).

I don't see any way of solving these problems short of a relative
warp, but I am certainly open to another solution.