Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!sun-barr!decwrl!asente
From: asente@decwrl.dec.com (Paul Asente)
Newsgroups: comp.windows.x
Subject: Re: Help with double-click recognition.
Message-ID: <1934@bacchus.dec.com>
Date: 17 Oct 89 22:48:36 GMT
References: <1922@bacchus.dec.com> <603@granite.dec.com> <256@mirsa.inria.fr>
Organization: DEC Western Software Lab
Lines: 25

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