Path: utzoo!censor!geac!torsqnt!hybrid!scifi!bywater!uunet!censun1!cew
From: cew@censun1.UUCP (SSUID Craig E Warsaw)
Newsgroups: comp.windows.x
Subject: Re: XWarpPointer revisited.....
Summary: There could still be a problem.
Message-ID: <595@censun1.UUCP>
Date: 19 Jan 91 19:53:51 GMT
References: <9945@ncar.ucar.edu> <100920272@hpcvlx.cv.hp.com> <977@attc.UUCP>
Organization: Century Computing, Inc., Laurel, MD
Lines: 40

In article <977@attc.UUCP>, marbru@attc.UUCP (Martin Brunecky) writes:
>    I think that one more thing to *consider* is the "lifetime" of the
>    warp and the context. For example:
> 
>    Now. If the application would:
>    - popup the box
>    - warp the pointer into the "acknowledge" button
>    - wait for reply
>    - warp pointer to the *original* position
> 
>    In this scenario, the user would *only* have to click the button to
>    acknowledge the message. He von't be lost, since the application would
>    return the pointer where it was before...
>    Naturally, this should ONLY be done if the pointer *was* in the application's
>    window to start.

I've often thought that this would be extremely nice in our product.
It is a pain to have to move the mouse to click "acknowledge".  Makes me
almost want to use keyboard focus policy  :-)

However, I've seen users click the mouse button twice for various reasons:
  - He's used to the sequence of events.
  - System slow down
  - Accidently

If you warp the pointer before the second click, he'll dismiss the dialog box
without being able to read it.

We ran into a similar problem with a modal dialog box getting obscured.
The window manager would take the second click and raise the original window.
We fixed that by raising the modal dialog.

I agree with Martin in that there may be good reasons to warp the pointer
(for example: IMHO, OpenLook scrollbars are much better than Motif), but
it is dangerous.

---------------------------------------------------------------------------
Craig Warsaw
Century Computing, Inc.
cew@fox.gsfc.nasa.gov