ellis@cadillac.siemens.COM (Ellis Cohen) (11/24/87)
> 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
mcgregor@zin.DEC.COM (SCOTT MCGREGOR) (11/24/87)
Ellis; My underlying model of the system leads me to have some difficulty with your proposal. 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, 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. The disable concept points out another difficulty-- you can't always tell (from the widget) what the right thing to do is. Sometimes the desired effect is to warp and other times not. 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. Scott.
raveling@VAXA.ISI.EDU (Paul Raveling) (11/24/87)
Regarding the following recent exchange . . . >> 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. My religious faith says that there if my widget (or window, or whatever) moves, the mouse had better move with it in order to maintain the same dialog state. Keeping the mouse stable over the screen often would represent motion in a semantic reference frame. Taking an example from a schematic editor, the cursor may be positioned over a pin on one corner of an IC chip. If the chip is rotated 90 degrees, I want the cursor to move with it in order to continue marking the same pin, which is likely to be the subject of the next editing operation. If the cursor position doesn't move, both the pin and the entire IC move from under the mouse, and the entire context is lost. In other cases the interactive context would dictate the opposite approach (not warping the mouse). I think it's appropriate for the level of processing which is "aware" of the semantic consequences to decide whether to warp the mouse and if so how. For toolkit widgets, the code supporting the widget should often be able to make this decision. I vote for having the ability to do this, even if the code often wisely elects to let the user make the moves. --------------------- Paul Raveling Raveling@vaxa.isi.edu
braca@THINK.COM (11/24/87)
I mostly use systems with little to zero warping. The single exception is Interleaf, which likes to warp the pointer to property sheets when they are opened, and back when they are closed. I find that I don't mind the warping to the property sheet, because that's where my focus goes anyway, but it blows me clean away when it warps back to the left margin where I initially fired up the property sheet, this now being a fairly random location. Warping may be desirable when a shift of focus can be predicted with good accuracy, otherwise just leave the pointer where it is. _Mike
haynes@DECWRL.DEC.COM (11/24/87)
Ellis, Your latest message brings up another important point. Just as my underlying model of the mouse pointer is that the user, not the system, controls it. I feel the same way about windows, and window layout. I, the user, control the windows, and their layout. The basic problem you seem to be having is that some client is creating windows unexpextedly, that is, not in response to user action. I can well believe that in a tiling window manager that would cause all sorts of nasty problems. The problem is not in the window manager, or in the mouse, but in the client that is bringing up windows without a user action. -- Charles
Len%AIP1%TSD@atc.bendix.COM (11/24/87)
Received: from GRACIE by HEART-OF-GOLD via CHAOS with CHAOS-MAIL id 503; Tue 24-Nov-87 10:16:44 EST
Date: Tue, 24 Nov 87 10:16 EST
From: Sai-Cheong Arnold Chu <Gilgamesh@HEART-OF-GOLD.ABATSD>
Subject: Warping the Pointer for a Reconfigured Widget
To: "3077::in%\"xpert@athena.mit.edu\""@TSD1.ABATSD,
gilgamesh@HEART-OF-GOLD.ABATSD
Message-ID: <871124101645.4.GILGAMESH@GRACIE.ABATSD>
Let me suggest that the source of this disagreement over whether to warp
pointer or not is due to the double meaning of the cursor. Those who
would like to see the cursor move with a widget is trying to preserve
the context of the client behind the widget. Those who wishes the cursor
to be stationary are trying to preserve the context of the whole screen.
These are two distinct meanings for one cursor. Often, this is indicated
by changing cursor shape when the cursor moves from a window to the background.
To make explicit this distinction, I would advocate using separate cursors.
One for overall interaction with the screen. One for each widget which needs
locator input. Mouse input may be multiplexed between these separate cursor via
keyboard modifier or commands. The focus of input may be indicated by blinking.
This type of interaction is already present in systems with text cursors and
mouse cursor. Implementation of this should be relatively straight forward.