ellis@audi.mit.EDU (Ellis Cohen) (07/30/87)
PROPOSED PROTOCOL CHANGE TO WarpPointer
Problem: WarpPointer provides only absolute warping,
not relative warping.
------------------------------------------------------------
Consider an application where the user is moving the pointer around.
When the user hits a key, the pointer must jump down 20 pixels.
We tried to use WarpPointer (followed by XFlush, of course) but the
effects were occasionally very distubing visually.
The problem is that between the time the client receives the position
at which the key press occured and then tells the server to WarpPointer
twenty pixels below, the user may continue to move the pointer.
Instead of smoothly jumping 20 pixels down from its current location,
the pointer instead jumps twenty pixels down from where it was when the
key press was received.
------------------------------------------------------------
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.
Ellis Cohen
Siemens RTL Tiled Window Project
ellis.cohen@a.gp.cs.cmu.edu
princeton!siemens!ellis
(609) 734-6524RWS@ZERMATT.LCS.MIT.EDU (Robert Scheifler) (07/31/87)
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?ellis@audi.mit.EDU (Ellis Cohen) (07/31/87)
> 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.
RWS@ZERMATT.LCS.MIT.EDU (Robert Scheifler) (08/01/87)
Date: Fri, 31 Jul 87 11:48:43 EDT
From: ellis@audi (Ellis Cohen)
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.
This seems like a perfect example of where a relative warp is a bad
idea, and a conditional absolute warp is a good idea. The position you
ideally want to end up at (the center of the window) is known
absolutely. If the window manager suffers a delay in warping, and the
user has since moved the pointer off to the new center and is about to
click, I find it hard to imagine that it is desirable to suddenly do a
relative warp.
What am I missing?
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.
This seems beside the point, but why should the length of time between
down and up matter? Why aren't all butten events "distinct"?
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.
I don't see how warping (no matter how) affects the situation. If the
user inadvertantly clicks twice, then they probably do so before you
have a chance to warp the pointer at all. I don't see how a relative
warp after the second click changes anything.
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.
No, I wouldn't argue that.
I don't see any way of solving these problems short of a relative
warp, but I am certainly open to another solution.
I'm still open to the idea of a relative warp, but your description
still doesn't provide me with a justification I can make sense of.RWS@ZERMATT.LCS.MIT.EDU (Robert Scheifler) (08/01/87)
Date: Fri, 31 Jul 87 23:52:51 EDT
From: Kimbo Peebles-Mundy <io!puppy!kimbo%ileaf.uucp%umb.umb.edu@RELAY.CS.NET>
The Interleaf system frequently makes use of relative displacements of
the mouse. This is done in our popup code when traversing levels in the
menu tree, and in diagramming, when creating objects.
These still seem like cases where, before you issue the warp, you know
where the pointer was, so you know absolutely where it should go to, and
if it has since been moved far from that position you probably don't
want to move it at all.
If that weren't
enough, we also use small deltas to greatly improve the "feel" of the
system; for example, within a level of the popup tree, if the motion is
mostly vertical, then the horizontal component is canceled out. This
make tall menus much easier to navagate. I can't see any way this kind
of correction could be done with an absolute warp.
Ah, now this sounds like a reasonable example.