Xref: utzoo alt.toolkits.xview:128 comp.windows.open-look:572
Path: utzoo!utgpu!cs.utexas.edu!wuarchive!uunet!mcsun!ukc!slxsys!bae-st!adam
From: adam@ste.dyn.bae.co.uk (Adam Curtin)
Newsgroups: sun.open-windows,alt.toolkits.xview,comp.windows.open-look
Subject: Re: Detecting and handling mouse double click with XView - paper
Keywords: doubleclick
Message-ID: <1991Feb12.111129.22360@ste.dyn.bae.co.uk>
Date: 12 Feb 91 11:11:29 GMT
References: <7698@exodus.Eng.Sun.COM>
Reply-To: adam@ste.dyn.bae.co.uk (Adam Curtin)
Organization: British Aerospace (Dynamics), Stevenage
Lines: 38

As a developer of a C++ interface to XView, I found Jim's paper very
interesting.  It's attractive to us to incorporate features that we feel have
been wrongly omitted from XView.  There was, however, one point that neither the
text of the paper, nor the code so far as I understood it, made clear: the fate
of the first ACTION_SELECT event of a (potential) multi-click sequence.

After receiving a click, the program can deliver the event as a single-click
(ie, ACTION_SELECT), or withhold it in anticipation of more clicks in a
multi-click sequence. Both choices have problems.  If the program delivers the
first click as a single-click, there's trouble if another click arrives within
the multi-click timeout.  If it withholds the event to compare against the next
click, it runs the risk of delaying the withheld click indefinitely.

So much for the passive processing of multi-clicks.  A couple of ideas occurred
to me immediately, both of which were discouraged by Jim's paper ...

In article <7698@exodus.Eng.Sun.COM> jcb@frisbee.Eng.Sun.COM (Jim Becker) writes:
>Some  implementations  of  double click can be created to perform this
>sort  of  functionality.  Specifically  the program can delve into the
>coming  event  queue  searching for more mouse down events. Or a timer
>can be used that goes off after the double click threshhold. 
>
>Although there are sometimes reasons to do this, in the spirit of user
>interface consistency we hope you refrain from this  if  possible.  If
>you  desire  code  that  performs this function, we have some examples
>(email me). However this sort of usage is generally discouraged.

Of course, neither of these solutions are ideal:  event-queue peeking could
still block, and setting timers in our toolkit could interfere with toolkit
users.

What would be _really_ good would be to post a next-click-should-have-arrived-
by-now event in the future, but you can't do that with XView.  Where'd that NeWS
manual go ...?

Adam
-- 
/home/research/adam/.signature: No such file or directory