🚀 go-pugleaf

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).

In article <16995@phoenix.Princeton.EDU> bskendig@phoenix.Princeton.EDU (Brian Kendig) writes:
>In article <1990Jun5.091419.14219@portia.Stanford.EDU> canuck@portia.Stanford.EDU (William Stocker) writes:
>>I'm writing a Mac program in THINK Pascal 3.0, and need to force the
>>mouse to a particular screen location.
>
>    DON'T DO IT.  It's *very* bad technique, and your application
>    won't run, besides.
>
>Tell me what, exactly, this `good purpose' is that you've thought up,
>and I and millions of other Netters will help you come up with a more
>proper way of doing it.

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, <CTRL> key: pointer moves to the palette containing
  controls <-> CTRL key - quite easy to remember.
- select the tool you want,
- release the <CTRL>: pointer moves to the area where you were doing your
  things

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.

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').

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?

KK
-- 
Kris Kozminski   kk@mcnc.org
"The party was a masquerade; the guests were all wearing their faces."