Xref: utzoo comp.sys.mac:55144 comp.sys.mac.programmer:15193 Path: utzoo!attcan!uunet!cs.utexas.edu!tut.cis.ohio-state.edu!rutgers!mcnc!kk From: kk@mcnc.org (Krzysztof Kozminski) Newsgroups: comp.sys.mac,comp.sys.mac.programmer Subject: Re: There *ARE* uses for forcing the mouse to a location (non-games). Summary: There *are*. No, there *aren't*. Are so. Are not so. Doubly are so :-) Message-ID: <2291@speedy.mcnc.org> Date: 7 Jun 90 18:31:43 GMT References: <1990Jun5.091419.14219@portia.Stanford.EDU> <16995@phoenix.Princeton.EDU> <2285@speedy.mcnc.org> <17041@phoenix.Princeton.EDU> Reply-To: kk@mcnc.org.UUCP (Krzysztof Kozminski) Organization: MCNC; RTP, NC Lines: 149 [I've added comp.sys.mac.programmer to the distribution - I think it's weird it wasn't there in the first place ... - KK] I am still going to defend the idea that allowing the software to control the mouse position is occasionally a Good Thing, and my primary example of such is still a situation when you need to go to a tool palette or a modal dialog and then return to the place on the screen that is distant from the palette/dialog. Some details on the methodology I intend to use are included. First of all, please remember that I would like to see this feature to be switchable on or off from the Control Panel, thus conforming to the principal idea of giving the control TO THE USER. I am somewhat surprised to see a dissent in this respect. By all means, 'jumping cursor' should be switched off as a default, but if the user is willing to accept the chance of an occasional confusion as a price of the increased convenience on many other occasions, then LET HIM/HER use it. The official guidelines forbiding this reek of BigBrotherhood to me. The restriction was acceptable in the times of a 9 inch screen, because it was not really noticeable. I think it is time to relax it (see the elaboration of the X-windows argument later on) - what do Apple people think about it? So far, the alternate proposals to my examples of a Good Thing were: >From: edgar@function.mps.ohio-state.edu (Gerald Edgar) > ADB Macs can have two mice plugged in. We just need the software to run > both mice, one for each screen ... After all, I have two hands. Some people could cope with this - but I personally find it very awkward to operate even a single mouse with my left hand. And keeping two mice within the reach of my right hand brings the vision of tangled cords... and if you need to type, two mice are no good, unless lingual dexterity allows you to operate keyboard with your tongue :-) >From: bskendig@phoenix.Princeton.EDU (Brian Kendig) >Better yet -- hit the Control key, and the tool palette comes up right >under your pointer. While trying to break one guideline, I probably should not use another as an argument, but aren't 'jumping windows' another no-no? I have a better argument against it anyway: this will generate an update event (possibly also for some background applications), thus slowing you down and negating the speedup that is desired by allowing the pointer to warp over to the palette. >Or hit Return for the OK button, Command-Period for the Cancel button, >and other command-things for other buttons (such as Cmd-S for "Save"). I am talking about editing complicated (maybe hierarchically organized) widgets - with just as complicated dialogs (or windows) associated with them - try, e.g, to manipulate a scrollable list with a keyboard - yuck. >From: philip@pescadero.stanford.edu (Philip Machanick) > The dialog should warp to the cursor. Better still, the modal dialog > should be movable, so you can adjust its position once it's near enough > to reach without risk to your ligaments. OUCH, that hurts (a torn ligament is why I had my knee surgery yesterday :-) (and if anybody is wondering why the smiley, read my previous article :-):-) I presume that you mean that the dialog should come up near the cursor (to avoid a jumping window, and to avoid having two areas to update). But the dialog will obscure the widget you're editing - this is why I wanted it to show up away from the cursor in the first place. Now back to the X-windows: this is where I hope to make a final convincing argument. I'd like just to mention that "the first system I used is best" syndrome does not apply here; I am not pushing Xerox Star paradigms, am I ?-) I've picked the X-windows just because sometimes I have to use them. Normally I run UW or Telnet from a Mac, so that I can write documents while watching over the number crunchers outputs in the terminal emulator windows. X-window emulators on a Mac are a fact. Allowing the software to move the pointer all over the screen is a necessity for this particular application. The size of the X-window market seems to my uneducated in the marketing matters self a good reason for Apple to provide some kind of consistent access to these undocumented low-memory globals to the X-developers. So why should this acces be denied to others? Assuming that the user knows when to expect a 'pointer warp', there is nothing wrong with it. The feature should be used with good judgement, and the current guidelines seem to deny that developers have the ability to make such a judgement. Some final wrap-up. >Brian Kendig: >If you start doing esoteric things with menus, windows, and especially the >pointer, novice users will become confused and leave. And it you forbid doing esoteric things, sophisticated users will leave. Point in case: several weeks ago my officemate, showing off some features of an elaborate schematic capture program, was gloating over the fact that when he was adding a new element, after checking on some attribute of the element, the pointer jumped to the next checkbox that was likely to be checked - the choice of the next checkbox depended here on ALL the previously checked boxes, so no nice things like a default button or a default choice of selected checkboxes could be implemented. And he asked: "now can YOUR Mac do THIS?" I failed to defend the Mac Way... >>1) Let the user choose in the Control Panel whether she/he wants to allow >> a 'jumping mouse pointer'. There's lotsa space there to fit one checkbox >> that is needed. >Can you say `counterintuitive'? Sure, you can... Come on, this was just a sketch, not a final interface specification. There's enough space in the Control Panel to put a detailed exaplanation. Speaking of 'counterintuitive' I haven't seen many Mac users outside CS/EE who would find the RAM Cache control *understandable*, all intuition aside. OK, now, how am I going to do this in my program for widget editing ... First of all, while displaying the About... dialog on startup, I watch these undocumented locations, compare them with the legally obtained mouse location, and, if they do not agree, I assume that something is not compatible and disable the pointer warp. Just to make sure, I request that the user moves the mouse before dismissing the startup dialog - to double check that the numbers agree - but usually the user will fiddle with the mouse without a reminder. Of course, the entire feature can be disabled via the program setup/preferences dialog, just in case the initial checks happen to be insufficient. Furhtermore, I store the environment in the preferences file, so that when the program is moved to a different machine/system version, the feature becomes automatically disabled (just in case low memory suddenly becomes protected and trying to read it produces an exception), and the user is notified that the warp mode is off. All the above seems to me quite failproof - any comments are welcome. Now when do I use mouse warp? Precisely for moving the pointer to one of the several palettes with the tools. Pressing the CTRL (the actual modifier key used is selectable via the preferences/setup dialog) turns on the 'warp watch': when the user moves the pointer towards one of the palettes, it is automatically moved all the way there. Selecting a tool transports the pointer back. Moving the pointer off the palette while still holding CTRL warps it to another palette, provided that the direction of move is correct, otherwise beep and warp mode off (no return to the work area), to allow exit the warp mode if the user wishes so. Aside of the pointer returning to the work area after tool selection, all the above is totally consistent with the interface guidelines - it just can be considered as an ultra-fast, speed-sensitive mouse tracking. I have a couple of other, more elaborate uses, but this article is already way too long ... have I made any converts yet? KK -- Kris Kozminski kk@mcnc.org "55 saves lives. 110 saves twice as much"