ben@hpcvlx.cv.hp.com (Benjamin Ellsworth) (01/17/91)
> Is it simply because the user can become confused with the visual > effects? I think so. The problem is that it seriously disturbs the "direct manipulation" paradigm. The cursor is always attached to the mouse--moving the mouse moves the cursor. When you warp the cursor, you have caused the cursor to move without moving the mouse. This weakens the perception that the two are connected. There are also perceptual issues regarding "Where'd that darn cursor get to anyway?!" When the cursor is attached to the mouse, the user knows where the cursor is--it's right where he or she left it. When the cursor is warped, the user has to figure out where it went. Lastly, you can run into a problem between relative and absolute locator devices. What happens if the user is using a tablet for locator input (instead of a mouse) and the cursor is warped? Do you have a mechanical arm come out and adjust the tablet stylus for the user? ;-) ----------------------------------------------------------------------- Benjamin Ellsworth | ben@cv.hp.com | INTERNET Hewlett-Packard Company | {backbone}!hplabs!hp-pcd!ben | UUCP 1000 N.E. Circle | (USA) (503) 750-4980 | FAX Corvallis, OR 97330 | (USA) (503) 757-2000 | VOICE ----------------------------------------------------------------------- All relevant disclaimers apply. -----------------------------------------------------------------------
morreale@bierstadt.scd.ucar.edu (Peter Morreale) (01/17/91)
In article <100920272@hpcvlx.cv.hp.com> ben@hpcvlx.cv.hp.com (Benjamin Ellsworth) writes: > >> Is it simply because the user can become confused with the visual >> effects? > >I think so. The problem is that it seriously disturbs the "direct >manipulation" paradigm. The cursor is always attached to the >mouse--moving the mouse moves the cursor. When you warp the cursor, you >have caused the cursor to move without moving the mouse. This weakens >the perception that the two are connected. > Thanks Ben, I understand. Might I ask the net community for some help in how to implement re-setting the focus in an *Xt* application? I have read the ICCCM and and understand the premise, I just am not sure how to implement it. If some kind soul could point towards specific routines/resources/etc, I would be very grateful. This is my *first* app, and quite frankly, I *could* get away with moving the pointer as the app will only be used by a very small group of users. (internally) However for my own edification, and in the interest of "doing things right", I would like to know how this is done. My basic questions are: 1) How does one set focus on the basic of a KeyPress? (ie: when RETURN is detected in window A, set focus in window B?) (Please note that I already have code which detects the RETURN, and I know from which widget the RETURN was detected) 2) What (if anything) need I account for when the user *does* manually move the mouse? (I suspect nothing, but I'm not sure...) Barring a small code excerpt, an Xt methodology would be fine. Perhaps this is simple, but from reading the X/Xt documentation, it escapes me. Thanks for any and all help... -PWM -- ------------------------------------------------------------------ Peter W. Morreale email: morreale@ncar.ucar.edu Nat'l Center for Atmos Research voice: (303) 497-1293 Scientific Computing Division
marbru@attc.UUCP (Martin Brunecky) (01/19/91)
In article <100920272@hpcvlx.cv.hp.com> ben@hpcvlx.cv.hp.com (Benjamin Ellsworth) writes: > >> Is it simply because the user can become confused with the visual >> effects? > >I think so. The problem is that it seriously disturbs the "direct >manipulation" paradigm. The cursor is always attached to the >mouse--moving the mouse moves the cursor. When you warp the cursor, you >have caused the cursor to move without moving the mouse. This weakens >the perception that the two are connected. > >There are also perceptual issues regarding "Where'd that darn cursor >get to anyway?!".... I think that one more thing to *consider* is the "lifetime" of the warp and the context. For example: Application responds to the user's action, which caused an error, by poping-up a message box with application modal and "acknowledge" button on it. Under the current thinking, the user must: - move the pointer to the "acknowledge" button - click the button - remember where he was before the disaster happened - move the pointer back (sure, in click-to-focus mode you could use the keyboard, but thet's another issue). 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. So, I think that again and again, we should never make general absolute statements. Sure, warping the pointer disturbs the "direct manipulation" paradigm. However, there may be circumstances where such a "disruption" is justified and welcome. Besides, anytimes an application uses an Application or System Modal (to use Motif terms), it has *already* disturbed the direct manipulation paradigm, as it is forcing the user into something he did not want to do. -- =*= Opinions presented here are solely of my own and not those of Auto-trol =*= Martin Brunecky {...}sunpeaks!auto-trol!marbru (303) 252-2499 (sometimes also: marbru@auto-trol.COM ) Auto-trol Technology Corp. 12500 North Washington St., Denver, CO 80241-2404
barmar@think.com (Barry Margolin) (01/19/91)
In article <977@attc.UUCP> marbru@auto-trol.UUCP (Martin Brunecky) writes: > Now. If the application would: > - popup the box > - warp the pointer into the "acknowledge" button > - wait for reply > - warp pointer to the *original* position Sounds like the MIT Lisp Machine (and, by inheritance, Symbolics) pop-up menu mechanism (pop-up confirmations are simply menus with only one choice). One difference is that there is an option (which I think is on by default) to pop-up the menu at a location that puts the default choice under the mouse cursor; the cursor only has to be warped if it is close enough to the edge of the screen that part of the menu would be off the screen (the LispM window system doesn't support off-screen windows). In general, I've noticed that X Windows has adopted hardly anything from the LispM window system. Is this some kind of YIH (Yes Invented Here) syndrome? Next to the Macintosh, the LispM window system is probably the nicest window system around, and Symbolics's enhancements to it in the last few years are phenomenal. Yes, it still has some annoying limitations (windows must fit on the screen, the active window must be on top, updates to partially-obscured windows aren't usually visible until the window is raised), but many of the UIMS features are great (an automatic mouse documentation line, extensive support for mouse-sensitive regions, very good management of keyboard focus). -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
cew@censun1.UUCP (SSUID Craig E Warsaw) (01/20/91)
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
toml@ninja.Solbourne.COM (Tom LaStrange) (01/20/91)
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. Actually, OPEN LOOK applications and window managers can provide this exact behavior. This is accomplished through the private OL Client/WM protocol and it is actually the window manager that does the warpping. -- Tom LaStrange toml@Solbourne.COM
scotth@corp.sgi.com (Scott Henry) (01/21/91)
IMHO, after having used applications where the dialog/notifier/requestor /whatever pops up with the default action button under the pointer (warping the pointer only enough to get the whole thing on the display, if needed), I *don't see* dialog/notifier/requestors that pop up in the middle of the screen, because they are not where *my* focus is. To me, this paradigm difference is analogous to the difference between proportional scroll bars (which I first saw on the Amiga 5 or 6 years ago) and the type on the Macintosh: the proportional bars give better visual feedback than the fixed size type. Similarly, having the dialog/whatever pop up (as close as possible to) where the focus currently is provides much better visual feedback than having them pop up in a "standard" location, especially since many of them provide little visual contrast. -- Scott Henry <scotth@sgi.com> / Traveller on Dragon Wings Information Services, / Help! My disclaimer is missing! Silicon Graphics, Inc / Politicians no baka!
dshr@eng.sun.COM (David Rosenthal) (01/22/91)
Martin Brunecky writes: > The "popup non-obscuring" or "popup at screen-center" etc, however, > require pointer motion (either by the user or by the application). > My suggestion for this scenario was that there are situations where > warping the pointer by the application *may* be appropriate, and > may not disturb the direct manipulation paradigm any more than the > popup itself does. > The important words here are "warping the pointer by the application" not just "warping the pointer". Tom LaStrange points out: > > Actually, OPEN LOOK applications and window managers can provide this exact > behavior. This is accomplished through the private OL Client/WM protocol > and it is actually the window manager that does the warpping. > This provides the behaviour you want *without* the problems caused by the application warping the pointer. The ICCCM does not restrict warping the pointer by the window manager. Note that the behaviour being discussed is part of the overall look and feel that should be consistent between applications. Inconsistent behaviour in this area would be worse than consistent behaviour that you didn't like. This isn't an area that the application programmer should be writing at all - use what your toolkit gives you and if you don't like it beat up on your toolkit supplier. So, the rules are: - If you are writing an application and find yourself tempted to warp the pointer, take a long walk or a cold shower. The feeling will pass and in the long term you'll feel much better for not doing it. - If you are writing a toolkit and find yourself tempted to warp the pointer, try and resist. If you fail, make sure you abide by the ICCCM rules and restrict yourself to things like scrollbars. If you want to warp into popups, use a private protocol with the WM like OPEN LOOK. - If you are writing a window manager and find yourself tempted to warp the pointer, go right ahead and indulge yourself. David.
ben@hpcvlx.cv.hp.com (Benjamin Ellsworth) (01/22/91)
> Under the current thinking, the user must: > - move the pointer to the "acknowledge" button You assume that the box is not and cannot be posted under the cursor. > 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... Finding the cursor can be aided by visual clues. However, unless those cues are quite strong, the first time the box pops up the user will probably be lost. If you want to train the user, go ahead. > Besides, anytimes an application uses an Application or System Modal > (to use Motif terms), it has *already* disturbed the direct > manipulation paradigm, as it is forcing the user into something he > did not want to do. (The terms pre-date Motif.) "Forcing the user into something he did not want to do" is orthogonal to direct manipulation paradigms. ----------------------------------------------------------------------- Benjamin Ellsworth | ben@cv.hp.com | INTERNET Hewlett-Packard Company | {backbone}!hplabs!hp-pcd!ben | UUCP 1000 N.E. Circle | (USA) (503) 750-4980 | FAX Corvallis, OR 97330 | (USA) (503) 757-2000 | VOICE ----------------------------------------------------------------------- All relevant disclaimers apply. -----------------------------------------------------------------------
marbru@attc.UUCP (Martin Brunecky) (01/23/91)
In article <9101212345.AA03235@devnull.Eng.Sun.COM> dshr@eng.sun.COM (David Rosenthal) writes: >Martin Brunecky writes: > >> The "popup non-obscuring" or "popup at screen-center" etc, however, >> require pointer motion (either by the user or by the application). >> My suggestion for this scenario was that there are situations where >> warping the pointer by the application *may* be appropriate, and >> may not disturb the direct manipulation paradigm any more than the >> popup itself does. >> >The important words here are "warping the pointer by the application" not >just "warping the pointer". Tom LaStrange points out: >> >> Actually, OPEN LOOK applications and window managers can provide this exact >> behavior. This is accomplished through the private OL Client/WM protocol >> and it is actually the window manager that does the warpping. >> >This provides the behaviour you want *without* the problems caused by >the application warping the pointer. The ICCCM does not restrict >warping the pointer by the window manager. > >Note that the behaviour being discussed is part of the overall look and feel >that should be consistent between applications. Inconsistent behaviour in >this area would be worse than consistent behaviour that you didn't like. >This isn't an area that the application programmer should be writing >at all - use what your toolkit gives you and if you don't like it beat >up on your toolkit supplier. So, the rules are: > in brief, don't EVER do it .. The problem is that ICCCM conventions for any MODALS or the kind of behavior above DO NOT EXIST. Except for ONE WM (which we can't rely on any more than any other) there are NO Window Managers that would provide the functionality above, though there are (few) window managers providing private, incompatible, non-ICCCM (und thus TOTALLY useless) support for various application (and other) modals. I am sorry to say that, but the Window Manager (protocol) evolution is lagging a century behind application needs, thus forcing many of us to take action on the application side. As we (and many other people) migrate EXISTING applications to X World, we have to provide EFFICIENT solutions TODAY. Bad enough that switching to X we suffer a significant performance hit (compared to previous kernel graphics systems such as GPR, Pixrect, UIS). Now you suggest I should DRASTICALLY REDUCE USER'S (customers) PRODUCTIVITY for the sake of consistency with non-existent other applications and non-existent ICCCM rules. I AM SORRY. I CAN'T DO IT. I can't afford to dissatisfy my users (more that I already am by foisting the X performance upon them) by obiding by well-intended, but incomplete and even inappropriate requirements for consistency. Of course, I will obide the "consistency" requirements as soon as there will be rules and *implementations* which provide efficient solutions *available from multiple vendors*. Until such *implementations* do exist, I *MUST* and I *WILL* ignore rules which RESTRICT without GIVING alternate solution. {flame of} -- =*= Opinions presented here are solely of my own and not those of Auto-trol =*= Martin Brunecky {...}sunpeaks!auto-trol!marbru (303) 252-2499 (sometimes also: marbru@auto-trol.COM ) Auto-trol Technology Corp. 12500 North Washington St., Denver, CO 80241-2404
marbru@attc.UUCP (Martin Brunecky) (01/23/91)
In article <100920274@hpcvlx.cv.hp.com> ben@hpcvlx.cv.hp.com (Benjamin Ellsworth) writes: > >> Under the current thinking, the user must: >> - move the pointer to the "acknowledge" button > >You assume that the box is not and cannot be posted under the cursor. > Indeed I do. In graphics applications (CAD/CAM), the pointer is where user works, and where the graphical information (drawing) NEEDED to choose from the popup is. Often (not always) it is NOT desirable to popup at the current pointer location as this would HIDE (obscure) the information the user needs to see to make his (menu) choice. -- =*= Opinions presented here are solely of my own and not those of Auto-trol =*= Martin Brunecky {...}sunpeaks!auto-trol!marbru (303) 252-2499 (sometimes also: marbru@auto-trol.COM ) Auto-trol Technology Corp. 12500 North Washington St., Denver, CO 80241-2404
mouse@larry.mcrcim.mcgill.EDU (01/24/91)
>> Can someone explain why warping the pointer *within* the client >> using XWarpPointer is discouraged? > Speaking from personal experience, one real good reason is that the > pointing device might be an absolute one (like a tablet) rather than > a relative one (like a mouse), in which case warping the pointer is > completely ineffective! Not necessarily so. I brought this point up in an email exchange with someone a while ago and the other person pointed out that it is fairly easy to take absolute positions from a tablet-style device and turn them into deltas, which are then applied to the cursor the same way deltas from a mouse would be. Then, when the pen is lifted off the pad, the next point does not generate a delta. This way the tablet behaves very much the way a mouse does: keep the pen down and move it around and it tracks; pick it up and put it down elsewhere and it doesn't notice the motion. Not that you always want this. I recall a video game we had (years ago) that used a tablet as an absolute positioning device. That game would have been unplayable if the tablet coordinates had been processed this way; it depended on getting absolute positions. (Which is why I've never rewritten it to run on the machines we have now - we have no absolute pointing devices.) der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu