Henrik Gedenryd <Henrik.Gedenryd at lucs.lu.se> wrote:
> Marcel Weiher wrote:
> 
> > I suggest that the fix to double-click detection that was proposed
> > on this list earlier should be implemented (and will try it myself
> > now in order to see what happens):  send a #click: after the first
> > mouseUp event, and make sure that the few existing #doubleClick:
> > clients can deal with receiving a click before the double-click.
> 
> This is actually how a double click should always be designed. It should
> always be signalled as a click event followed by a double click event, and
> all uses of double click should be natural extensions of a single click.
> E.g. single click selects object, double click performs most frequent action
> on it.
> 
> Otherwise, e.g. nasty unpredictable things may happen if you miss the double
> click threshold by a couple of milliseconds.
> 

This is why I dislike double clicking in general.  Even if you do as you
describe, you need to make sure that the second single-click isn't going
to be too disastrous to someone who double-clicked too slowly. 
Furthermore, there's a related concern that two single clicks can
trigger as a double click, and so you need to make sure that this won't
be disastrous, either.  For examples, in Squeak, I occasionally try to
deselect an item in an inspector only to have a new inspector open.  And
in various text editors (not Squeak's!), I'll ocassionally click in one
place and then click in another, only to have the editor highlight the
second word I clicked on.

Overall, when you are designing systems that use double clicks, you
really have to think about what happens when the user performas the
wrong kind click by accident.  Personally, I'd rather have a
deterministic UI and give up on the extra kind of click.  Instead of using
double clicks, designers can use a new mouse button, put items on a menu,
or redesign the UI with fewer core operations.



-Lex