Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!bbn!uwmcsd1!ig!jade!ucbvax!cadillac.siemens.COM!ellis
From: ellis@cadillac.siemens.COM (Ellis Cohen)
Newsgroups: comp.windows.x
Subject: Re: Warping the pointer for a reconfigured widget
Message-ID: <8711232205.AA03052@audi.siemens.com>
Date: Mon, 23-Nov-87 17:05:37 EST
Article-I.D.: audi.8711232205.AA03052
Posted: Mon Nov 23 17:05:37 1987
Date-Received: Thu, 26-Nov-87 20:36:10 EST
Sender: usenet@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 66

> First of all, I view the user as "owning" the pointer and not the system,
> suggesting that it is almost never the right thing to do to change the location
> of the pointer unless the user moves it.  Assuming we disagree on that
> religious point, ...

Sigh.., it certainly does appear to be a religious issue.  I can only report on
my own experience and reaction -- that when a window or a widget is moved as a
result of a client action, I find myself wishing that the damn cursor would
have moved as well.

The most serious problem is, of course, that of asynchronous and unexpected
client actions.  When a client opens a window unexpectedly, the cursor
suddenly may be in a new window.  I've had this problem on almost every
window system I've worked in  -- I find that the cursor is in the wrong place
and that I've done something dreadful and sometimes even irrevocable by typing
a sequence of control characters into the wrong window.

In our window manager, we go so far as to optionally disallow or delay a client
action (e.g opening a window) that would have the side effect of changing the
geometry of the listener (i.e. the window that received the last input event) if
the cursor is still in it.  That helps a lot, but we find it to be overkill.
It would be much nicer to allow the window to be reconfigured, and have the pointer
move along with it.

I'm not disputing the religious conviction that the user should own the pointer.
But as a matter of practicality, if there is any sort of automatic layout control
going on at either the top-level or the widget-level, then I think that many
clients, though certainly not all, will appreciate a corresponding pointer warp,
and that the toolkit should respond to this.

So perhaps this comes down to the another religious discussion -- the advisability
of automatic layout control, which we, of course, practice.  I'm not sure I want
to discuss that much outside of noting that X11 was architected to allow and support
automatic layout control, so I believe that the toolkit should do the same, and support
diversity rather than just one model.

> ..., then it still isn't ok for an individual widget to decide
> whether the pointer should be warped because presumably the behaviour should be
> consistent across the system. 

I agree that consistency would be preferable, and I'm certainly open to any
suggestions for turning it on or off globally (e.g. as a global resource value?).
No matter how it is enabled, though, I believe that toolkit support is essential.

> If you insist on warping, it seems better to leave the warping to the code that
> caused the re-layout, since it is the only place that has a chance of knowing
> what the right thing to do is.

Well, the difficult code to write is the one which warps the pointer automatically
when the window is reconfigured.
I tried to do this, and found it to be very difficult code to write, though
admittedly I had no previous experience writing code involving the new toolkit specs.
Still, I suspect that figuring out how to write the warp code taking the whole
widget hierarchy into account is not very easy.  Assuming that some client writers
will want to support warping the pointer for a reconfigured widget, then it seems
reasonable to me that the best place for the code is in the toolkit itself, where
it can be written correctly once and for all.

ellis.cohen@a.gp.cs.cmu.edu
Siemens RTL Tiled Window Project
105 College Road East
Princeton NJ 08540
(609) 734-6524