Xref: utzoo comp.windows.x:14308 comp.windows.news:1569
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!pyrnj!esquire!yost
From: yost@esquire.UUCP (David A. Yost)
Newsgroups: comp.windows.x,comp.windows.news
Subject: Re: Help with double-click recognition.
Message-ID: <1490@esquire.UUCP>
Date: 16 Oct 89 15:32:44 GMT
References: <603@granite.dec.com> <1922@bacchus.dec.com>
Reply-To: yost@esquire.UUCP (David A. Yost)
Organization: DP&W, New York, NY
Lines: 36

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