Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!uakari.primate.wisc.edu!dali.cs.montana.edu!ogicse!husc6!m2c!umvlsi!dime!leban
From: leban@par3.cs.umass.edu (Bruce Leban)
Newsgroups: comp.sys.mac.system
Subject: Re: The Mouse -- What is its History?
Message-ID: <21056@dime.cs.umass.edu>
Date: 10 Oct 90 22:42:47 GMT
Sender: news@dime.cs.umass.edu
Reply-To: leban@par3.cs.umass.edu (Bruce Leban)
Organization: University of Massachusetts, Amherst
Lines: 62

> From: rudd@calvin.tmc.edu (Kevin Rudd)
> Is there any logical reason (other than Apple's GUI Police) that a standard
> three button mouse could not be implemented in the Mac with the mouse
> driver (or mouse hardware) selectable to return either:
> 1.  a button signal for any button (the "Three Muskateer" configuration)
> 2.  L/R one click, M two clicks, R/L three clicks (the "Lazy" configuration)
> 3.  L, M, R for the appropriate button (the "Hacker Heaven" configuration)
[rest deleted]

The GUI police are (is?) a good reason to implement extra-button mice in some
standard way.  Seriously, if every application recognizes the extra buttons
differently, then you're in for chaos.  I know that some people love the Lisp
machine (Symbolics, TI, etc.) style of having the mouse bindings constantly
change but I find them very confusing.

So here is IMHO the "right way to do it":

  One button:     Click
  Two buttons:    Click, Shift-Click
  Three buttons:  Click, Shift-Click, Command-Click

The actions are assigned to the buttons left to right for right handers,
right to left for left handers.  We could argue about whether Command-Click
and Shift-Click should be swapped.  I chose Shift-Click because I think it's
used more and thus should be the one available on the two-button mouse.

Some people might object to such a simple assignment because they want to be
able to define the right button to bring up a popup menu bar or something.
There are always these people.  Nothing stops them from doing that.  If they
do, they lose the standard functionality of the mouse buttons but they can
always use the shift or command keys to get it back.  Just like when you
override the command keys of an application with QuicKeys you can still use
the menu.  In any case, this would be OK for an QK-like init to change the
meanings of the mouse buttons, but unneccessary/inappropriate for an
application.  If an application wants a menu attached to the right button of
a three button mouse, it just assigns that to command-click.  Then the menu
is also available to people without that third button.

I don't think that button chording is a good idea.  But I'm sure people will
do it anyway.  So here's my suggestions:

  Two-buttons:    BOTH = Command-Click
  Three buttons:  FIRST TWO = Option-Click, SECOND TWO = Command-Shift-Click

Ideally a chord would be detected by pressing a second button within a very
short period of time while the first one is still depressed, rather than
requiring the buttons to be pressed "simultaneously".  This would require
changing applications to recognize them.  Pressing all three buttons is
probably an even worse idea.  I just tried it on my Decstation mouse and
wasn't able to do it.

This has several good features:
	1) Applications already implement shift- and command-clicks and thus
already take advantage of the multi-button mice.  Presumably since these
variant clicks are now easier to type, applications would use them more.
	2) A person who normally uses a 24-bit color 2 page display with a
multi-button mouse who gives it to me in exchange for my standard b/w display
and one-button mouse will still be able to use the computer with a very
simple mapping of operations.

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