Path: utzoo!utgpu!watserv1!watmath!att!rutgers!apple!agate!shelby!portia.stanford.edu!news
From: kevinw@portia.Stanford.EDU (Kevin Rudd)
Newsgroups: comp.sys.mac.system
Subject: Three Button Mouse and Mac System Interface
Summary: Differences between short term and long term solutions.
Keywords: Mice, Buttons, Enhancements, Improvements, Controversy
Message-ID: <1990Oct15.031331.25456@portia.Stanford.EDU>
Date: 15 Oct 90 03:13:31 GMT
References: <21056@dime.cs.umass.edu> <1123@helens.Stanford.EDU> <9028@jarthur.Claremont.EDU> <1990Oct11.174840.21598@ux1.cso.uiuc.edu> <9038@jarthur.Claremont.EDU>
Sender: news@portia.Stanford.EDU (USENET News System)
Reply-To: rudd@umunhum.Stanford.edu (Kevin Rudd)
Organization: Stanford University
Lines: 123

This is a modified repost of an article which got lost.  It attempts to explain
why kludging keyboard modifiers is a BAD IDEA when implementing a multi-button
mouse WITH system support but the ONLY WAY when implementing a multi-button
mouse on a Mac WITHOUT system support.  It's long but worth it (?!?!).

In article <9038@jarthur.Claremont.EDU> wilkins@jarthur.Claremont.EDU (Mark Wilkins) writes:
>In article <1990Oct11.174840.21598@ux1.cso.uiuc.edu> dorner@pequod.cso.uiuc.edu (Steve Dorner) writes:
>>Using modifier keys is not much better, worse, or different than having
>>multiple buttons on the mouse, if done properly.  "Properly" I would define
>>as pretty much what an earlier poster said:
>>
>>Left button, click
>>Right button, shift-click
> >
>  Sorry if you got the impression that I was attacking that concept with my
>earlier post.
>
>  The person to whom I was responding had the opinion that multiple mouse
>buttons should be treated differently, in a standard and explicitly separate
>way by the operating system.  In fact, he was flaming what your propose.
                                               ^^^^^^^

N.b. that flaming typically means something to the effect of irrational
and excessive slam in an otherwise civilized message stream.  None of
my messages have been "flames" and it is unfortunate if individuals
felt that my opposing opinion was utter condemnation of them and their
ideas.  This has been a good discussion and has raised some good points
on both sides.  The remainder attempts to clarify my position on mice
and cheese.

Now, let me restate that it seems to me painfully clear that multi-button mice
should be treated differently BY THE SYSTEM software.  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.  For mice with more (e.g. three) buttons,
software which does not believe in them would still react the same way to
a mouse down event.  Only if the application checked would it find out
that it was the right button or such rathere than just a single button.

This is the only way in which the mouse interface should be done using the
system.  The mouse down event would return as normal.  Then, either somewhere
in the event field or with a separate call (e.g.

	theKey = GetMouseKeys(theEvent))

would either return 0 (standard mouse result) or (MOUSE_BUTTON_LEFT,
MOUSE_BUTTON_CENTER, MOUSE_BUTTON_RIGHT in some or'ed combination).
Thus current software would treat all the keys the same and new software
could behave appropriately.  Now, there is no reason that, in the event
software does not appropriately understand (or react) to the new mouse 
keys, there is pleanty of room for a QuickButtons INIT which would provide
customizable responses (essentially lisp-bindings just as QuickKeys does
for the keyboard).

There are two problems with having the mouse directly simulate the keyboard
to effect SHIFT-CLICK and siblings.  The main one from Apple's GUI Police
standpoint is that applications do not all behave the same way between
modifier keys and poly-click sequences.  Thus one application would use
LEFT-BUTTON and another would application would use OPTION-RIGHT-BUTTON
to accomplish the same thing.  At least by starting with a DEFINED INTERFACE
(of whatever kind -- popup menu navigation or multi-function depending
on the button, that kind of discussion is beyond the current thread (but
very important nonetheless)) there will be some consistency in the use
of the buttons.  Inconsistency will simply make three button mice less
desirable by the masses and will probably prohibit mainstream software support.

The other problem is more major: simulating both mouse and keypress
events. This is a REAL KLUDGE.  (Note, kludges have their place -- more
follows).  Not all keyboards today have the same
codes for all keys (the right control on the extended keyboard normally
as well as the right cluster of keys optionally have different codes), and
it is not unlikely that new keyboards will have SHIFT, OPTION, and COMMAND
as different encodings on different keyboards.  For this technique to be
used, the mouse would have to know which keyboard was in use and know how
to simulate it.  Another method is to have an INIT which would 
intercept mouse events and patch in a prior key down event
in the queue (also considered a no-no by Apple).

The method of using a simulation or software kludge is a requirement if
multi-button mice are to be used WITHOUT APPLE SUPPORT.  However, the system
and users would benefit by using the hardware directly.  I would certainly
use one of these kludged mice with great pleasure.  But I would dump it
as soon as there was actual support for the buttons directly in software.
Thus there is certainly a place for the key-and-button approach.  However, 
the place only exists while there is no support in fact.  And these devices
would still function, they would just not be fully functional with the new
system (without a modification to support the STANDARD (easy to implement
thereby giving use now while Apple is bline and later when they open
their eyes)).  I hope that we will see kludges to fill the void.  But
Apple should not adopt a kludge into the system itself.

As was noted in earlier messages, a multi-button mouse would be a
compatable OPTION and would only be supported as an ENHANCEMENT
to the standard features as the new keyboards were for the Mac.  Old Macs
with old keyboards still function, but those who upgraded (either Apple
or third-party) gain new features.  Those who choose not to upgrade
plod along as always and probably don't notice the difference.
Their Macs would use new software as before -- keyboard modifiers and menu
commands.  But the software would be able to use three button mice (as
governed by the interface guidelines) to ENHANCE the operation of the software.

Why three button mouse?  Many programs would be much
more effectively used with multiple-buttons, and using the mouse
and the keyboard at the same time is awkward (using modifier keys).
Yes, the buttons could certainly ACT as if they had a modifier key in some
applications, but many application) would be better written to support the
actual hardware by reading the buttons in some manner and determining what
happened and acting accordingly.  Making the mouse play keyboard as well
prevents this and applications would be the same as today and not be able
to offer any additional functionality.

And finally, progress shouldn't be kludged when better alternatives exist.
Kludges are for PC's -- they NEED them.  After all, is a PC with
Windows 3.0 as good or better than a Mac?  That's a kludge until
a real system gets put on the machine to hide the rest of the hardware --
either OS/2 or Unix (you shouldn't have to ask which one I would prefer).

Anyway, I hope that Apple gets the message:  We need MORE BUTTONS!  But
KEEP THE INTERFACE CLEAN.  Let's get enough three-button mice out there
unsanctioned (read: kludged) so they fill the need and build in a good
interface!

  -- Kevin