Path: utzoo!attcan!uunet!ginosko!gem.mps.ohio-state.edu!apple!snorkelwacker!think!kulla!barmar
From: barmar@kulla (Barry Margolin)
Newsgroups: comp.windows.x
Subject: Re: Help with double-click recognition.
Message-ID: <30997@news.Think.COM>
Date: 17 Oct 89 19:04:47 GMT
References: <1490@esquire.UUCP> <8910171248.AA03392@expire.lcs.mit.edu>
Sender: news@Think.COM
Organization: Thinking Machines Corporation, Cambridge MA, USA
Lines: 40

In article <8910171248.AA03392@expire.lcs.mit.edu> rws@EXPO.LCS.MIT.EDU (Bob Scheifler) writes:
>    i.e. after one click, if
>    another click comes in before the timeout,
>    send a double click event, else when the
>    timeout expires, send a single click event.
>This is what I would call an "idea", rather than a complete design.  As stated,
>it sounds rather specific to a single policy, and interactions with other
>mechanisms would need to be considered (e.g. what if the first click starts
>a synchronous grab?).

This is giving me some ideas.  First of all, I believe that
multi-click detection should be in the server, so that the
recognition time can be short; yes, there are ways to do it in the
client by using timestamps, but I suspect the network delays will make
single clicks look clumsy.

I think multi-click detection should be controlled by a per-window
attribute.  Each window would have an attribute specifying the maximum
number of clicks to be recognized together.  By default this would be
1 (the current behavior), but an application that uses multi-clicks
could request the facility.  When the mouse is in or grabbed by a
window it would recognize up to the specified number of sequential
clicks, and send a RepeatedButtonDown event containing the number of
clicks and the initial mouse position (the final position would be in
the next ButtonUp event).  There should be settable per-server
attributes specifying the multi-click timeouts.

I think this is the right separation of mechanism and policy for this
facility.  Multi-clicking is a well-known mechanism, and the only real
policy is whether or not a particular application uses it.  It could
also be made an optional server feature, so applications would have to
do it using timestamps when necessary, but users of more featureful
servers would get the smoother feel; however, I think the overhead of
multi-click detection (as contrasted with backing store) is low enough
that this shouldn't be necessary.

Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar