[comp.windows.x] Help with double-click recognition.

pjs@granite.dec.com (Philip Schneider) (10/14/89)

    Okay, toolkit wizards, how about this one:

    I've created a drawing widget under Xaw by modifying the
"TemplateWidget" example in the Athena Widget documentation.  I've
tried in many ways to figure out how to get it to call one
callback on a single button press, and another for a double-click.  
So far, I've not been succesful, and it seems from my understanding
of the documentation and from my experimentation that it might not
be possible.

    Is there something obvious I'm overlooking, or what?  Any solution
to this problem would be greatly appreciated.  If the answer has to be
"I know how to do it with Motif, or DECWindows", etc., that's no
problem.

    I DO have a solution that involves trapping the single button-press,
checking the event queue for the appropriate ButtonPress and ButtonRelease
events, and attempting to "do the right thing"; this, however, is unreliable
due to the "meddling" of the toolkit with the event queue, and is rather
ugly :-)

- Philip Schneider


-- 
Philip J. Schneider			| pjs@decwrl.dec.com
DEC Advanced Technology Development	| decwrl!pjs
100 Hamilton Avenue			| (415)853-6538
Palo Alto, CA  94301			| (415)386-8232

asente@decwrl.dec.com (Paul Asente) (10/14/89)

>I've
>tried in many ways to figure out how to get it to call one
>callback on a single button press, and another for a double-click.  
>So far, I've not been succesful, and it seems from my understanding
>of the documentation and from my experimentation that it might not
>be possible.

You got it.

There really is a reason for it.  X is network-based.  There's no way for
an application to know, upon receiving one button click, whether there's
another one coming along.  Consider the following scenario:

-User clicks button twice.  For some reason (process scheduling, network
delays, whatever) the first event is delivered to the application but the
second one isn't.
-Application wants to know whether there is another click coming.  It
looks in the queue, but nothing is there.  It decides to wait a while and
check again; still nothing there.
-Application decides to execute single button action.
-The second event arrives with a timestamp that indicates that it took
place immediately after the first one, within the double-click interval.

What does the application do?

Unless the application is willing to do some extremely nasty things to the
user (like always waiting to see the next event before processing a single
click, which might take seconds or even longer) it can't know whether a
click is the first in a double click.  It has nothing to do with the
toolkit; it's intrinsic to X.

	-paul asente
	    asente@decwrl.dec.com	decwrl!asente

envbvs@epb2.lbl.gov (Brian V. Smith) (10/14/89)

In article <1922@bacchus.dec.com>, asente@decwrl.dec.com (Paul Asente) writes:

(But first, someone else:)
< >I've
< >tried in many ways to figure out how to get it to call one
< >callback on a single button press, and another for a double-click.  
< >So far, I've not been succesful, and it seems from my understanding
< >of the documentation and from my experimentation that it might not
< >be possible.
<
< You got it.
< 
< There really is a reason for it.  X is network-based.  There's no way for
< an application to know, upon receiving one button click, whether there's
< another one coming along.  Consider the following scenario:
<

[...]
 
<  It has nothing to do with the
< toolkit; it's intrinsic to X.
< 


Wait a second!
What about xterm's double/triple click and xrn's double/triple/quadruple
click recognition for text selection?

Please explain how that works so well 8-)

_____________________________________
Brian V. Smith    (bvsmith@lbl.gov)
Lawrence Berkeley Laboratory
I don't speak for LBL, these non-opinions are all mine.

asente@decwrl.dec.com (Paul Asente) (10/14/89)

In article <3954@helios.ee.lbl.gov> envbvs@epb2.lbl.gov (Brian V. Smith) writes:
>Wait a second!
>What about xterm's double/triple click and xrn's double/triple/quadruple
>click recognition for text selection?
>
>Please explain how that works so well 8-)

AHA!  It all has to do with carefully selected actions.

When you triple click in xterm, what really happens is you execute the
single click action after the first click, the double click action after
the second click, and the triple click action after the third.

What you can't do is say "do one thing after a single click and something
entirely different after a double click".

The safest thing to to is to make double click build upon single click.
Examples:
	single-click: go to position
	double-click: go to position and select a word
or
	single-click: select a file name
	double-click: select a file name and open it in an editor

You're actually ok as long as the single click item is reversible;
you can do something like
	single-click: do single-click action
	double-click: undo single-click action, do double-click action

Where you get into trouble is when the action is hard or impossible to
reverse; you could do something like
	single-click: start editor on file
	double-click: kill editor process, start compiler on file
but do you really want to?

	-paul asente
	    asente@decwrl.dec.com	decwrl!asente

jim@EXPO.LCS.MIT.EDU (10/16/89)

    When you triple click in xterm, what really happens is you execute the
    single click action after the first click, the double click action after
    the second click, and the triple click action after the third.

Unfortunately, it's even worse than that!  The same action (select-start) is
executed every time, but xterm keeps track of the timestamp of the last event
so that it can decide what to do on the fly.  This is why there are currently
so many grody parameters for controlling the line selection instead of simply
having additional actions.

							Jim

yost@esquire.UUCP (David A. Yost) (10/16/89)

In answer to why you can't implement double-click in X:

In article <1922@bacchus.dec.com> asente@decwrl.dec.com (Paul Asente) writes:
>There really is a reason for it.  X is network-based.  There's no way for
>an application to know, upon receiving one button click, whether there's
>another one coming along.  [and how long should it wait for one?]

Thanks for explaining to us how the
implementation stands in the way of a
robust implementation of a desired policy.
(Remember the X motto: implementation, no
policy).

Of course, users are best served when one
starts from a specific user-centered design
and then derives the appropriate implementation.
Too bad UNIX and X are not from this culture.

Isn't double-click commonly accepted enough
that X servers should be able to reliably
implement it?  (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.)
What if one wanted to hack the drivers on a
Mac so you could use it from an X terminal?
"Sorry, no double click."

Would someone from the NeWS camp care to add
to this?  Can you download code to the server
to do this so you don't have to beg the
protocol designers for the capability?  What
are some other examples of reasons why you
need to be able to download input code?

 --dave yost

haffley@cs.purdue.EDU (P Michael &) (10/17/89)

If one wanted to use double clicks in X, then one could simply look at the
timestamp of the events.  By flushing the event buffer after the
timeout and then by searching the event list of keypress events, one could
determine if a double click has occurred and then do the appropriate thing.
It is not restricting double clicks, it just takes some work (and
time) to use it.
 _ __      _ _ _                    _     _    ,              _
' )  )    ' ) ) )      /           //    ' )  /      /)  /)  //
 /--'      / / / o _. /_  __.  _  //      /--/ __.  //  //  // _  __  ,
/ o       / ' (_<_(__/ /_(_/|_</_</_     /  (_(_/|_//__//__</_</_/ (_/_
                                                  />  />            /
                                                 </  </            '

P. Michael Haffley
haffley@iuvax.cs.indiana.edu
(ames,rutgers,pur-ee,att)!haffley

rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (10/17/89)

    Of course, users are best served when one
    starts from a specific user-centered design
    and then derives the appropriate implementation.
    Too bad UNIX and X are not from this culture.

There are thousands of issues that go into the design of a system like X.
To think that X was designed ignoring user requirements, or that "perfect"
design is trivial, is to be rather naive.

    Isn't double-click commonly accepted enough
    that X servers should be able to reliably
    implement it?

Probably (even if it is a bad idea).  It may depend on how you define
"reliably".  Is doing the timeout on the client side, after receipt
of the first click, and then forcing a round-trip to the server to
ensure receipt of all current events, a workable solution?  If you
really wanted to, you could compute the network delay time and factor
it in as well.

    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?).

colas@mbili.inria.fr (Colas Nahaboo) (10/17/89)

In article <1922@bacchus.dec.com>, asente@decwrl.dec.com (Paul Asente) writes:

> There really is a reason for it.  X is network-based.  There's no way for
> an application to know, upon receiving one button click, whether there's
> another one coming along. 

This is not due to the network nature of X, just to the fact that in the
current MIT sample server implementation, the timestamp is only updated
on key/mouse events. If the planned enhancement make it
to R4 (having some requests, such as ChangeProperty, update correctly the
timestamp), then you can implement a REAL double click by, if the input event
queue is empty, sending PropertyAppend of NULL length at fixed intervals in
your client time, which will return
a property notify with the correct timestamp (now (R3) you get only the same
time as the last key/button event) in the server time. Then, as soon as the
timestamp exceeds some the value you know you have only a single click,
unless you receive a second click in the meantime, of course.

Hope this will make its way in the R4 toolkit, too :-)

Colas NAHABOO       BULL Research FRANCE -- Koala Project 
                    (GWM X11 Window Manager)
    Internet:       colas@mirsa.inria.fr
Surface Mail:       Colas NAHABOO, INRIA - Sophia Antipolis, 
                    2004, route des Lucioles, 06565 Valbonne Cedex -- FRANCE
 Voice phone:       (33) 93.65.77.71, Fax: (33) 93 65 77 66, Telex: 97 00 50 F

peter@ficc.uu.net (Peter da Silva) (10/17/89)

In article <1490@esquire.UUCP> yost@esquire.UUCP (David A. Yost) writes:
> Isn't double-click commonly accepted enough
> that X servers should be able to reliably
> implement it? 

No. Double-click is a kludge foisted on the computing world by the
decision to put only one button on the Macintosh mouse.

Of course, the X people didn't help this situation any by their
blind refusal to dictate policy. As a result the three mouse buttons
don't mean anything, and you have people wanting to double-click.

On the Amiga, the two buttons have a meaning: "select" and "menu". A third
button, for "perform" would be nice, but the designers of the Amiga
user interface fell in with the Mac fad and hid "perform" in "double-
click-select". (that, and putting the ^&%^&%& menus at the top of the
&^*&^* screen... another Macintosh kludge designed to avoid adding
buttons) :-<
-- 
Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation.
Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-'
"That particular mistake will not be repeated.  There are plenty of        'U`
 mistakes left that have not yet been used." -- Andy Tanenbaum (ast@cs.vu.nl)

barmar@kulla (Barry Margolin) (10/18/89)

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

yost@esquire.dpw.COM (Dave Yost) (10/18/89)

> Probably (even if it is a bad idea).  It may depend on how you define
> "reliably".

> If you really wanted to, you could compute the network
> delay time and factor it in as well.

I meant by reliably that it would work well without
regard to network load, and without having to put
in an extra delay to try to deal with network delay.

Thanks for your restrained reply.

 --dave

rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (10/18/89)

    I meant by reliably that it would work well without
    regard to network load,

Well, since your X server and client are probably on non-real-time systems
anyway, you've already blown the "reliably" part. :-)

    and without having to put
    in an extra delay to try to deal with network delay.

It's only a one-way trip delay, the other half falls into the delay you
have to wait for anyway, to determine if it might be a double click.

asente@decwrl.dec.com (Paul Asente) (10/18/89)

In article <256@mirsa.inria.fr> colas@mbili.inria.fr (Colas Nahaboo) writes:
>In article <1922@bacchus.dec.com>, asente@decwrl.dec.com (Paul Asente) writes:
>
>> There really is a reason for it.  X is network-based.  There's no way for
>> an application to know, upon receiving one button click, whether there's
>> another one coming along. 
>
>This is not due to the network nature of X, just to the fact that in the
>current MIT sample server implementation, the timestamp is only updated
>on key/mouse events.

It's not strictly true that it's *just* because X is network based, since
scheduling anomolies could cause delays similar to network delays -- but
they rarely do.  Networks do cause substantial delays.

Until you've tried running an application connected to a server by a very
slow link across a lossy network you don't know the meaning of the word
"latency."  There is no way the application can know how long it will be
before the second click in a multi-click arrives; delays can make this
take seconds. Solutions that involve forcing a round trip to sync with the
server mean that single click actions get delayed; not a tolerable
trade-off to me.

	-paul asente
	    asente@decwrl.dec.com	decwrl!asente

Ed@ALDERAAN.SCRC.SYMBOLICS.COM (Ed Schwalenberg) (10/19/89)

    Date: Wed, 18 Oct 89 12:42:18 CDT
    From: ekberg@osage.csc.ti.com

       From: ficc!peter@uunet.uu.net  (Peter da Silva)

	      Double-click is a kludge foisted on the computing world by the
	  decision to put only one button on the Macintosh mouse.

    Hardly!  I still haven't used a Mac but I have been a double-click fan for >6
    years!!  Try looking at a lisp machine.

I was just asking around about this, and double-clicking has been in the
Lisp Machine system since the beginning (1977 or so), and it wasn't an
original idea THEN.  The "computing world" has known about mice and
double-clicking for longer than Apple has been in business.

john@aardvark.ctt.bellcore.com (John Letourneau) (10/19/89)

In article <6564@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes:
>In article <1490@esquire.UUCP> yost@esquire.UUCP (David A. Yost) writes:
>> Isn't double-click commonly accepted enough
>> that X servers should be able to reliably
>> implement it? 
>
>No. Double-click is a kludge foisted on the computing world by the
>decision to put only one button on the Macintosh mouse.
>
>Of course, the X people didn't help this situation any by their
>blind refusal to dictate policy. As a result the three mouse buttons
>don't mean anything, and you have people wanting to double-click.

Well, my $.02 as a NeWS user are like this...with a 3 button mouse, you
have 3 choices of things->standard is i)selection ii)position iii)menu.
Stan Switzer and I talked this one over and using the time element allowed us
to include i-a)stretch! i-b)inverse! Basicly what Stan hacked up was
to use the selection button to "canvas-to-top" on the border with a
"quick-click", "canvas-to-bottom" on the border with a "double-quick-click"
and "constrained/un-constrained-stretching" with "click-hold". The end
result is we don't have to call up a menu or hit a function-key to do
these things. Stan isn't ready to send this stuff out (if he ever will),
but he and I are common friendly users of each others hacks, so don't
bug him for the code!

Sorry Stan, you were slightly out of touch when I responded to this! 8-)

-_ .- _ *  - ~ _______   "I feel the need...       | John P. Letourneau
 . * = _ .~ _ / 9000  \___  the need for speed!!"  | john@ctt.bellcore.com
~_ .~_ .  =  /    Turbo   \                        | Bellcore
~. - _ = * - \-O------O----|                       | Piscataway, NJ.

colas@trinidad.inria.fr (Colas Nahaboo) (10/19/89)

In article <1934@bacchus.dec.com>, asente@decwrl.dec.com (Paul Asente) writes:
> Solutions that involve forcing a round trip to sync with the
> server mean that single click actions get delayed; not a tolerable
> trade-off to me.

In fact I am working on a slow machine (16Mhz 68020) over a heavily loaded  
network, so for me respect of the "server" time, not the 
client time, is more important to me (I am always
in a sort of "mouse-ahead" situation) than quick response... :-)
But I agree, delaying single-click actions is NOT a good solution (I own an
atari ST, I know what it means!)

stpeters@dawn.crd.ge.COM (Dick St.Peters) (10/19/89)

>       No. Double-click is a kludge foisted on the computing world by the
>       decision to put only one button on the Macintosh mouse.

> Hardly!  I still haven't used a Mac but I have been a double-click fan for >6
> years!!  Try looking at a lisp machine.  That has a 3 button mouse that uses
> double clicking for alternates.

Agreed!  I too still haven't used a Mac.  I've only been double-
clicking for 4.5 years, but I've been quadruple-clicking for more than
3.  As someone with a mild impairment of one hand, having a lot of
capability available quickly using just the mouse is important.

--
Dick St.Peters, GE Corporate R&D, Schenectady, NY
stpeters@dawn.crd.ge.com	uunet!dawn.crd.ge.com!stpeters

peter@ficc.uu.net (Peter da Silva) (10/19/89)

In article <17943@bellcore.bellcore.com> john@aardvark.UUCP (John Letourneau) writes:
> Well, my $.02 as a NeWS user are like this...with a 3 button mouse, you
> have 3 choices of things->standard is i)selection ii)position iii)menu.

What does "position" do? How do you select-multiple without a "perform"
button? A (DO-IT) gadget? No default action?

> Stan Switzer and I talked this one over and using the time element allowed us
> to include i-a)stretch! i-b)inverse! Basicly what Stan hacked up was
> to use the selection button to "canvas-to-top" on the border with a
> "quick-click", "canvas-to-bottom" on the border with a "double-quick-click"
> and "constrained/un-constrained-stretching" with "click-hold".

Try using 'click' as a toggle: if it's obscured, bring it to front. Otherwise
drop it to back. This will give you the same semantics for obscured canvasses,
and save a click on unobscured ones. This is what the new Amiga windowing
system is supposed to do (haven't seen it yet :-<).

Click-hold is a different matter... you don't need to use the time domain:
just see if the current position changes while the button is down. Doesn't
everyone do it this way?

What does 'selecting' a border usually do?
-- 
Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation.
Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-'
"You can tell when a USENET discussion is getting old when one of the      'U`
 participants drags out Hitler and the Nazis" -- Richard Sexton

montnaro@sprite.crd.ge.com (Skip Montanaro) (10/20/89)

This note showed up in comp.windows.news. I thought it might be interesting
for those people following the same thread in comp.windows.x. Can somebody
speak to Robin's question about timestamp ordering of events in X?

---------- begin included message ----------
From: robin@SUN.COM (Robin Schaufler)
Newsgroups: comp.windows.news
Subject: Re: Help with double-click recognition.
Message-ID: <8910192039.AA00634@borogove.sun.com>
Date: 20 Oct 89 08:17:38 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 13

The difficulty with waiting for another event and then looking at the timestamp
is knowing how long to wait.

In NeWS, this problem is solved by sending oneself a shuttle event timestamped
in the future; since distribution of events is ordered by timestamp, if the
shuttle arrives before another down transition, then it is known to be a single
click.  If the down transition arrives before the shuttle, the client can
dequeue the shuttle so it never gets distributed.

X does not have this notion of timestamp ordering for all events.  I don't see
any way to implement this sort of shuttle interface.  If anyone else does,
please enlighten me.
						-- Robin
---------- end included message ----------
--
Skip Montanaro (montanaro@crdgw1.ge.com)

barnett@crdgw1.crd.ge.com (Bruce Barnett) (10/20/89)

	Followup to comp.windows.misc. please.

In article <6594@ficc.uu.net>, peter@ficc (Peter da Silva) writes:

>Try using 'click' as a toggle: if it's obscured, bring it to front. Otherwise
>drop it to back.

I HATE this in window systems that have this "feature".
I set up the windows the way that I like, and some window system keeps moving
my windows around when I don't want to.

Example: I want to look at a large window 'cause it has a manual page,
data or source, but do work in a smaller window on top of the first.

Then I want to select something in the "back" window and
move/copy/paste it in front. BANG! my small window goes away. Grr!
This is a real pain when the small window is completely covered over
by the large window, and both windows are on top of a dozen other
windows. It might take me a dozen actions to undo the changes of this
"helpfull feature".

When I set up my windows, I don't want them changed!

But, you ask, how do you change this?

>What does 'selecting' a border usually do?

Bingo!

A lot of window systems use clicks on the border of a window to
specify window-manager actions.

These clicks can therefore be used to change window hierarchy,
iconify state, move or resize windows, or pop up the menus that all
window-based applications have.

But inside the window, you can make that program use any sort of
chord like
	 Shift-Meta-Control-DoubleClick left, middle and right mouse buttons.

I have that chord defined to update the database in my Watch!
Well, not really. Maybe next week. :-)

--
Bruce G. Barnett	<barnett@crd.ge.com>   uunet!crdgw1!barnett

john@aardvark.ctt.bellcore.com (John Letourneau) (10/20/89)

In article <6594@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes:
>In article <17943@bellcore.bellcore.com> john@aardvark.UUCP (John Letourneau) writes:
>> Well, my $.02 as a NeWS user are like this...with a 3 button mouse, you
>> have 3 choices of things->standard is i)selection ii)position iii)menu.
>
>What does "position" do? How do you select-multiple without a "perform"
>button? A (DO-IT) gadget? No default action?
  OK, OK, Sorry, Sorry...position should be DRAG! sheesh
  I don't understand the rest of the comment. You can define whatever you
  want on the mouse buttons. The above list is the standard actions for
  windows and panels.
>Try using 'click' as a toggle: if it's obscured, bring it to front. Otherwise
  We've done this (for a loong time) and interresting things come of it.
  Since the actual display state is not always know (ie. a window can appear
  to be TOP to the observer but it's state does not say that) interesting
  things happen-> the toggle will seem to do nothing to the top screen the
  first time it is clicked; and on the second click it will go to the bottom
  as was probably intended with the first click. With an explicit TOP/BOTTOM
  type of action (double-click) this is avoided.
>Click-hold is a different matter... you don't need to use the time domain:
>just see if the current position changes while the button is down. Doesn't
>everyone do it this way?
  Ah! You are in the world of implementations and not techonologies. Sure there
  are a plethora of ways of doing things. We wanted to see how the time element
  could be used. I'm sure when Stan returns (next week I think) he'll have
  a few things to add to this discussion.
  PS. The click and move can get trickey if framebuffer interrest are
    used for things...trust me on this I tried it.

-_ .- _ *  - ~ _______   "I feel the need...       | John P. Letourneau
 . * = _ .~ _ / 9000  \___  the need for speed!!"  | john@ctt.bellcore.com
~_ .~_ .  =  /    Turbo   \                        | Bellcore
~. - _ = * - \-O------O----|                       | Piscataway, NJ.

sjs@spectral.ctt.bellcore.com (Stan Switzer) (10/23/89)

Well, frankly, it comes a quite a surprise to me that you can't do
double click detection in X, but is quite easy in NeWS.

Here's a routine to check if a click is, in fact, a double click.
After you have detected a single click, invoke this routine to see if
there is another click.  Since it just checks to see if another click
follows the current one, it can be cascaded to detect triple,
quadruple, etc. clicks.

    /DoubleClickDelay .3 60 div def
    /DoubleClick? { % - -> another click(true) or not(false)
	null blockinputqueue { % fork
	    ParentCanvas setcanvas
	    currentcursorlocation
	    createevent dup begin
		/Name /MouseDragged def
	    end expressinterest
	    createevent dup begin
		/Action /DownTransition def
		/Exclusivity true def
	    end expressinterest
	    createevent dup begin
		/Name /Timer def
	    end dup expressinterest createevent copy dup begin
		/TimeStamp currenttime DoubleClickDelay add def
	    end sendevent
	    unblockinputqueue
	    WaitButIgnoreJiggle
	    /Action get /DownTransition eq % Have we a click?
	} fork waitprocess
    } def
    /JiggleFudge 4 def
    /WaitButIgnoreJiggle {
	{
	    % get events until something more than a
	    % mouse jiggle happens
	    awaitevent
	    true % exit flag
	    1 index /Name get /MouseDragged eq {
		1 index begin XLocation YLocation end
		% stk: origX origY event exflag X Y
		4 index sub abs JiggleFudge le exch
		5 index sub abs JiggleFudge le and
		{ pop false } if % continue (don't exit)
	    } if
	    { exit } if
	    pop
	} loop
    } def

If you wanted to be more clever, you could download a global click
processor that converted all multiple clicks into distinct events for
distribution.  It would probably be a bad idea, though, since it would
make all single clicks just a little bit sluggish.

Stan Switzer  sjs@bellcore.com

dan@watson.ibm.COM (Walt Daniels) (10/24/89)

Walt Daniels
>Stan Switzer  sjs@bellcore.com
>>Bruce G. Barnett	<barnett@crd.ge.com>   uunet!crdgw1!barnett

>Well, frankly, it comes a quite a surprise to me that you can't do
>double click detection in X, but is quite easy in NeWS.
I believe it is just as easy to do in X, but it is done client side
with much the same technique.  The problem is that client side is
slower by a network delay or two.

>Here's a routine to check if a click is, in fact, a double click.
>...

>If you wanted to be more clever, you could download a global click
>processor that converted all multiple clicks into distinct events for
>distribution.  It would probably be a bad idea, though, since it would
>make all single clicks just a little bit sluggish.
Notice that even done server side the possibility of double click
makes single click slower by the permissible time constant of the
double click which may be comparable with normal (not extreme) network
delay.

>>IMHO If multiple-clicks were to become a standard, it should be used for
>>accelerators, unnecessary to know about but useful if available.
This seems reasonable. One will quickly notice that on a slow network
they are not useful and resort to the more reliable way of achieving
the same results.

peter@ficc.uu.net (Peter da Silva) (10/24/89)

In article <18005@bellcore.bellcore.com> john@aardvark.UUCP (John Letourneau) writes:
> In article <6594@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes:
> >In article <17943@bellcore.bellcore.com> john@aardvark.UUCP (John Letourneau) writes:
> >> Well, my $.02 as a NeWS user are like this...with a 3 button mouse, you
> >> have 3 choices of things->standard is i)selection ii)position iii)menu.

> >What does "position" do? How do you select-multiple without a "perform"
> >button? A (DO-IT) gadget? No default action?

>   OK, OK, Sorry, Sorry...position should be DRAG! sheesh

OK, I understand now. You have select/drag/menu. I don't know... I don't
move windows around that much, so I can't see giving a mouse button up for
that action. I'd rather use a poke point.

>   I don't understand the rest of the comment. You can define whatever you
>   want on the mouse buttons. The above list is the standard actions for
>   windows and panels.

From a theoretical viewpoint, having a standard set of actions is desirable.

What I mean to say is, suppose you want to "activate" a bunch of icons at
once (where activate means start a program, send a signal, or whatever), what
is your standard sequence of operations? I'd think you'd SELECT each one, then
hit PERFORM. On the Mac, SELECT is a mouse click and PERFORM is a double
click. I'd rather make PERFORM a seperate button.

Then if you want more than the default action, you use the third button to
call up a menu of actions.

> >Try using 'click' as a toggle: if it's obscured, bring it to front. Otherwise

>   We've done this (for a loong time) and interresting things come of it.
>   Since the actual display state is not always know (ie. a window can appear
>   to be TOP to the observer but it's state does not say that)

Implementation detail. I didn't say "top", I said "obscured". You can tell if
a window is obscured either by looking at the clipping list for that window,
or by looking at other windows. Whether it's the highest window or not is
of little interest to the user.

Was it just too much trouble to check for this, or was this information not
available to the part of the program that decided on the action?

> >Click-hold is a different matter... you don't need to use the time domain:
> >just see if the current position changes while the button is down. Doesn't
> >everyone do it this way?

>   Ah! You are in the world of implementations and not techonologies.

Not really. If you *think* of the action as being in the time domain, it
can be annoying to people whose perception of the time domain is different
from yours. If everything depends only on a sequence of actions, instead
of worrying about just when the actions occurred, it's a lot easier on the
programmer and the user.

>   PS. The click and move can get trickey if framebuffer interrest are
>     used for things...trust me on this I tried it.

Now it's my turn... what does this refer to?
-- 
Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation.
Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-'
"I feared that the committee would decide to go with their previous        'U`
 decision unless I credibly pulled a full tantrum." -- dmr@alice.UUCP

john@aardvark.ctt.bellcore.com (John Letourneau) (10/24/89)

In article <6648@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes:
>In article <18005@bellcore.bellcore.com> john@aardvark.UUCP (John Letourneau) writes:
>>   OK, OK, Sorry, Sorry...position should be DRAG! sheesh
>
>OK, I understand now. You have select/drag/menu. I don't know... I don't
>move windows around that much, so I can't see giving a mouse button up for
>that action. I'd rather use a poke point.
	Weeeell we've got 100+ host on our network; Sun 3's, 4's, sparcstations,
    Pyramids, uVaxes, 3B2s, and on, and on. I typically have over 5 windows
    up at least, doing different things. FOR ME, moving windows or selecting
    them to be unobscured is how I choose to work as oppose to icons opening
    and closing. Besides I haven't had the time to hack up a "something has
    happened in the window represented by this icon" code...ie. missing some
    host event when the icon is up.
>
>hit PERFORM. On the Mac, SELECT is a mouse click and PERFORM is a double
>click. I'd rather make PERFORM a seperate button.
    Well, YOU prefer the Mac look. Aren't user programmable interfaces neat?!
>
>Implementation detail. I didn't say "top", I said "obscured". You can tell if
>a window is obscured either by looking at the clipping list for that window,
    Hmmmmmm
>
>Not really. If you *think* of the action as being in the time domain, it
>can be annoying to people whose perception of the time domain is different
>from yours. If everything depends only on a sequence of actions, instead
>of worrying about just when the actions occurred, it's a lot easier on the
>programmer and the user.
    Ah, I doubt if we'll agree completely (at all?) on some of these points.
    Maybe not even on the magnitude of their importance. End Of Comment (EOC)
>
>>   PS. The click and move can get trickey if framebuffer interrest are
>>     used for things...trust me on this I tried it.
>
>Now it's my turn... what does this refer to?
    I was afraid you'd ask this...let's see...Ah, I have it set up so that
    a select click on the framebuffer will open another window on my Sun.
    When things are slow for whatever reason, I'll click on an existing
    window frame to unobscure it..I then move the mouse (just slightly) so
    that it is on the framebuffer..I get a new window instead. This is what
    I've observed, it doesn't make complete sense to me, I haven't had time
    to dig into it. It might vary well be a figment of my imagination, or
    a subtle difference between what event is actually used->down or up
    transition. Sorry I can't be any more specific than this.

-_ .- _ *  - ~ _______   "I feel the need...       | John P. Letourneau
 . * = _ .~ _ / 9000  \___  the need for speed!!"  | john@ctt.bellcore.com
~_ .~_ .  =  /    Turbo   \                        | Bellcore
~. - _ = * - \-O------O----|                       | Piscataway, NJ.

mike@antel.uucp (Michael Borza) (11/01/89)

In article <8910191633.AA08710@dawn.crd.Ge.Com> stpeters@dawn.crd.ge.COM (Dick St.Peters) writes:
>>       No. Double-click is a kludge foisted on the computing world by the
>>       decision to put only one button on the Macintosh mouse.
>> Hardly!  I still haven't used a Mac but I have been a double-click fan for >6
>Agreed! [...]
>3.  As someone with a mild impairment of one hand, having a lot of
>capability available quickly using just the mouse is important.

Exactly.  This is one of the major benefits of allowing a user to configure
the environment to suit his/her requirements.  It's only logical to use
a machine to do as much work as is practical to make life simpler or
easier for users.  While I wouldn't want to quad-click my way through
life, others may.  Your particular example is most poignant.

>Dick St.Peters, GE Corporate R&D, Schenectady, NY

mike borza.
-- 
Michael Borza              Antel Optronics Inc.
(416)335-5507              3325B Mainway, Burlington, Ont., Canada  L7M 1A6
work: mike@antel.UUCP  or  uunet!utai!utgpu!maccs!antel!mike
home: mike@boopsy.UUCP  or  uunet!utai!utgpu!maccs!boopsy!mike

pjs@basalt.dec.com (Philip Schneider) (11/02/89)

	As I was the original poster of the request for double-click
recognition help, I feel it is my duty :-) :-) :-) to post a follow-up to
all the follow-ups (is that grammatical?).

  	Some of you may recall that I wanted to find a way to get an
Athena widget to recognize double clicks.  My "solution" at the time
was to have my ButtonPress callback routine do a call to select with
a timeout corresponding to the desired double-click interval, but it 
wasn't quite working as I wanted, for no apparent reason.  I had used this
technique relatively successfully in the past, in non-toolkit X programs, and
was wondering what the problem was.

	A number of well-intended folks responded with things like "it
isn't possible", "what about processes being swapped out", "problems with
network latency", etc.  This is b.s., as far as I'm concerned.  I routinely
work across an ethernet that is usually "maxed-out", and often using machines
that are VERY heavily loaded.  I've NEVER seen this to interfere with
my double-click-recognition routine.  Let's face it -- your basic human
finger is a LOT slower than most computers and networks.  In a heavily-loaded
compute environment, one could just increase the threshhold interval.

	For all you know-it-alls out there, here's the problem -- I naively
thought that the toolkit would make correct calls to XSelectInput for the
window in question, only allowing events through that were specified in the
various tables, etc.  So, when I called "select", it would immediately 
return when that first up-click (i.e., ButtonRelease event) ocurred.  Since
the second ButtonPress would NOT be able to get into the queue by the time
my routine checked it (maybe I'm slow, but MY finger can't move as fast as
the CPU on my machine), the double-click was not recognized.  There are
several possible solutions to this -- for example, one could explicitly
call XSelectInput on the window, and disallow ButtonRelease events, or
make the recognition routine more sophisticated so that it dealt correctly
with other sorts of events, etc.  In fact, one could write a custom widget 
that would do this for you!  Amazing, ain't it ???  I've recently been 
informed that the DECWindows toolkit does seem to correctly implement 
double-click recognition, so I don't think this is all my imagination.

- Philip Schneider



	



Philip J. Schneider			| pjs@decwrl.dec.com
DEC Advanced Technology Development	| decwrl!pjs
100 Hamilton Avenue			| (415)853-6538
Palo Alto, CA  94301			| (415)386-8232