Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!sdd.hp.com!ucsd!ucbvax!agate!shelby!neon!Kermit.Stanford.EDU!philip From: philip@Kermit.Stanford.EDU (Philip Machanick) Newsgroups: comp.sys.mac Subject: Re: There *ARE* uses for forcing the mouse to a location (non-games). Message-ID: <1990Jun7.052138.15103@Neon.Stanford.EDU> Date: 7 Jun 90 05:21:38 GMT References: <2285@speedy.mcnc.org> <1990Jun5.091419.14219@portia.Stanford.EDU> <16995@phoenix.Princeton.EDU> Sender: news@Neon.Stanford.EDU (USENET News System) Reply-To: philip@pescadero.stanford.edu Organization: Computer Science Department, Stanford University Lines: 85 In article <2285@speedy.mcnc.org>, kk@mcnc.org (Krzysztof Kozminski) writes: > In the beginning a suggestion to Apple: > > 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. > > 2) Provide a flag in SysEnvirons that lets the program know the status of > this bit, so that the program can use it for the convenience of the user. > > 3) Provide this sorely missing routine for setting the mouse position. > Something like SetMouse(x,y), returning TRUE if mouse was set, or > FALSE if it was not set. (e.g, if the user has turned the 'jumpy mouse' > off, or the position was off-screen or something like this). "sorely missing?" See below - I can't say I particularly miss this feature. I used the Mac first, them moved to X. Beware of the "the first system I used is best" syndrome. I can do the same thing back to you (but I won't). [...] > I am not the original poster, but coming up with a good purpose seems to > be a trifle (hey, I am so stuffed with painkillers right now that I can > come up with ANY idea for anything :-) > > Purpose 1. Imagine running MacDraw on a large screen (1200x1000 pixels > or more), editing some stuff in the lower right corner. You want to > change a tool and continue drawing in the lower right corner. You have > to move the mouse all the way to the palette, select a tool, and move > it all the way back. Kinda trouble, especially on a cluttered desk with > all 2 inches to mouse about without bumping your coke can off the desk... > > Solution accordingly to the guidelines: you gotta roll this mouse. Or > dig up this reference card and find out which option-command-control- > capslock-shift combination selects the tool you want (in case your > program was produced by a certain company that considers shift-option-H > to be a perfect mnemonic for changing the text style to subscript :-) > > Solution that comes immediately to anybody whose perspective has not > been limited by a puny 512x340 screen and/or by The Gospel from Apple (or > whose perspective has been broadened by a substantial dose of opiates > after surgery :-) > - press, say, key: pointer moves to the palette containing > controls <-> CTRL key - quite easy to remember. > - select the tool you want, > - release the : pointer moves to the area where you were doing your > things My solution: exactly rhe same, only you warp the palette to the cursor instead. Why? - it's more consistent with the rest of the interface - you don't lose sight of the cursor - you stay focussed on 1 part of the screen > Purpose 2: You are editing elaborate widgets on your elaborate multi-screen > setup, double-click on a widget to open a dialog, and thanx to the ossified > guidelines gotta move this mouse to the dialog, then back to your widget ... > Opening the dialog in the vicinity of the widget would obscure the widget, > hence is no good... > > Solution: if looking at the widget is useful while manipulating the dialog, > open the dialog on another screen, jump the pointer there, return the > pointer to the widget after dismissing the dialog. Instead of the idiotic beep when you click outside a modal dialog, 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. > I would be very interested in hearing any suggestions for handling such > situations that are both convenient and consistent with the guidelines > (then I'll swallow another Percocet and generate more 'good purposes'). I'd hate to be responsible for your health, but please feel free to continue the discussion. > Actually, here's the best reason: LOTS of programs using X-windows move > the mouse. How are you going to run X-windows on a Mac without this > capability? Fair enough, but you are presumably conscious that you are in a different operating system if you use X, just the same as you have to change to MS-DOS mode if you run Soft PC, or find the keyboard behaving in funny ways if you use your Mac as a VT100 terminal. This doesn't stop you from trying to think of alternatives more consistent with the Mac interface (for example, there are some contexts where Soft PC uses standard Mac open file dialogs, and I use a Mac-style dialog to enter my unix password in Microphone II). See also comp.sys.mac.programmer for my suggestion for menus on a big screen. Philip Machanick philip@pescadero.stanford.edu