Path: utzoo!attcan!uunet!van-bc!ubc-cs!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!mintaka!bloom-beacon!LARRY.MCRCIM.MCGILL.EDU!mouse
From: mouse@LARRY.MCRCIM.MCGILL.EDU
Newsgroups: comp.windows.x
Subject: Re:  Single click vs double click
Message-ID: <9010260615.AA15317@Larry.McRCIM.McGill.EDU>
Date: 26 Oct 90 06:15:31 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 60

> Ideally, the idea of double-click event should be unnecessary.  What
> should be done instead is to use a proper state model instead of
> trying to use a time-dependent input type.

This is not necessarily true.  You are making some possibly invalid
assumptions, which I shall elaborate on later.

> For example:

> Let's consider the standard select(single-click)/edit(double-click)

This is standard?

> if the programmer has sufficient control, the use of double-clicking
> can be easily obviated, so:

> Incoming button event:
> 	If the icon is unselected:  select
> 	If the icon is selected:    edit

This is a nice idea, but it works only in cases like this where the
single-click action can be subsumed into the double-click action.
Suppose the user wants to edit that object without selecting it (in
particular, without deselecting that other one over there)?

> I am, of course, biased --- I *despise* double clicking.  It tends to
> be substantially more difficult to program, and forces user-specific
> parameters to define the single/double time threshold.  The only
> reason it seems the double click was ever used was to compensate for
> crippled mice with only *ONE* button.  Multibutton mice don't need
> this kind of cruft.

You are assuming that there are no more commands on the mouse than
there are mouse buttons.  This is not necessarily true.  There may be
more reasonable, semantically distinct actions than there are buttons.
Having only one button is not notable, except that it exacerbates this
problem.  (I recall one program I wrote which had seven distinct mouse
commands.  I was using all single and double clicks and one triple
click.  Stop shuddering; it's not one of the things I distribute (it
wasn't even for X).  In retrospect using a menu for some of them would
probably have been a good idea, but I think my point is still valid.)

As a simple example of the sort of problem associated with having one
action implicitly perform others, take the NeXT.  If I have a large
window which has a small window in front of it, I cannot redirect
keystrokes to the large window without also raising it in front of the
small window[%].  NeXT has tied "raise window" and "type into window"
together, by making the same gesture (clicking in the window) invoke
both.  Your sample paradigm above has the same problem in a slightly
different guise: double-clicking not only edits, it also selects.  (In
the case of "edit" and "select" this is not as obviously bad as in the
case of "raise" and "select for typein".  That's not the point.)

[%] There may be some way; I certainly haven't discovered it.  Whether
    there is or not is irrelevant to my point anyway.

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu