Path: utzoo!utgpu!watserv1!watmath!att!att!emory!swrinde!zaphod.mps.ohio-state.edu!samsung!crackers!m2c!umvlsi!dime!leban
From: leban@dime.cs.umass.edu
Newsgroups: comp.sys.mac.system
Subject: Re: The Mouse -- What is its History?
Message-ID: <21679@dime.cs.umass.edu>
Date: 23 Oct 90 17:58:46 GMT
Sender: news@dime.cs.umass.edu
Reply-To: leban@dime.cs.umass.edu ()
Organization: University of Massachusetts, Amherst
Lines: 51

The dicussion is about what binding to attach to multiple mouse keys, in
particular a discussion to bind additional mouse keys to shift-click and
command-click.

> From: kevinw@portia.Stanford.EDU (Kevin Rudd)
> The problem that I have with the mouse simulating both mouse and keyboard
> events is that this is a real kludge.  For this to be used, the mouse would
> have to find out the keyboard in use (possibly a new one any day) and
> know how to simulate that particular keyboard.  Either that or a software
> (e.g. CDEV) to intercept mouse events and patch in a prior key down event
> in the queue (also considered a no-no by Apple).

To do the binding as described it is NOT necessary to (a) kludge anything,
(b) muck with the keyboard or (c) intercept mouse events, etc.  The mouse
driver generates events which are placed in the event queue just like the
keyboard driver generates events.  Presumably if you have a new mouse, you
need a new mouse driver.  When the driver wants to generate a command-click
all it needs to do is set the command key bit in the event record.  Some
facility of getting raw button codes like the facility for getting raw key
codes might be available but strongly discouraged.

> ... it seems to me painfully clear that multi-button mice
> should be treated differently BY THE SYSTEM software.

It needs to be treated differently by the mouse driver itself, but it's not
at all clear that the rest of the system has to know anything about it at all.

> However, this does not imply that the current interface would become
> incompatable with current software.  It would be compatable with software
> which assumes that the mouse has only one button.

So would the modified-click definition: right now, programs which don't use
command-click and/or shift-click treat them as normal clicks.

> The mouse down event would return as normal.  Then, either somewhere
> in the event field ...

There could also be other mouse modifier key bits added.

> 		 ... or with a separate call (e.g.
> 	theKey = GetMouseKeys(theEvent))

This would be a bad idea.  It's like saying:
	if Button() then GetMouse(...);
The reason for attaching the modifier keys and mouse location to the event
record is to avoid timing problems: by the time you receive the event the
mouse button has already been released.


	--- Bruce
	Leban@cs.umass.edu  @amherst.mass.usa.earth