X11TIPDoc.tioga
Copyright © 1993 by Xerox Corporation. All rights reserved.
Created by: Christian Jacobi, June 1, 1993
Christian Jacobi, February 11, 1993 2:16 pm PST
X11TIP
Abstract: Input handling with tip-tables.
Created by: Christian Jacobi
Keywords: Input, TIP, Translation tables
========================
No message sent, but there is another possible cause for the clocking difficulties.
The PCR tick - clock sometimes runs fast to catch up and have the correct average number of ticks. I am not sure what depends on "correct" tick time, all I know is that this is quite inconveniant for X11TIP - Impl
========================
Date: Fri, 28 May 93 15:27:01 PDT
From: jacobi:PARC:Xerox
Subject: X11TIP for Cedar10.1
To: CedarUsers
Cc: jacobi
Reply-to: Christian P Jacobi:PARC:Xerox
X11TIP for Cedar10.1
Double click detection in X11Viewers sometimes got terrible bad (I don't know when it got worse). I made some changes which maybe improve double click detection. (I could no more reproduce the problem since I tuned X11TIP, but sending this message is probably the best way to reproduce the problem again).
Some details, explaining the context
Double click detection is hard because of the combination of these two problems:
1) To compensate for communication delays, double click detection should use server time.
2) The X server does not report time passed if nothing else happens
The compromise is to simulate server time on the host. This simulated time must be fast enough to recognize time out (=absence of double click), but also slow enough that communication delays will not cause the clock to run backwards. Actually, backward running can be prevented by always using the later time, except, we don't want to stop the clock if the server has to catch up either. Therefore two mechanisms are used:
a) The simulated clock is slow.
b) The simulated clock stands still when it is no more used.
FYI: The reason standard X window applications don't have these troubles is simple: They do report the first click as a single click before they report the second click as a double click. The user interface is defined such that the double click action may always be preceded by the single click action.
This is what I did
0) I re-read the silly code in X11TIP until I understood it again.
1) I slowed down the simulated clock a few percent more. As double click detection was so bad, I thought the slowness to be a minor problem compared to the observed failure.
2) The simulated clock is wound up more gentle (This makes it stand still faster).
3) Mere mouse movements will no more wind up the simulated clock. (I believe we do not have tip tables timing mere mouse movements).
There is more good news
Eric Bier found a further place in TIPMatcherImpl where real time is used instead of server time. Probably, Eric's fix will be the real cure of this problem, but I think we will never really know whether his fix or my fix finally solved it. Eric's problem isn't fixed yet, but Eric will probably send his own release message. My release message is sent first so you can try out the fixes in isolation, if you care.
Christian
========================
Interfaces
XlTimeEvents.mesa
This interface takes care of the hard problem of "double-click" timing, separated out from the bulk of the code. It is probably only used by the implementation of this package itself.
XTkTIPSource.mesa
Interface useful to provide "tip" input events into anything which wants them. (This is the part which connects X11Viewers input mechanisms to x windows)
XTkTIP.mesa
Interface which governs the "output" side of "tip" input events. High level interface to receive tip events from arbitrary XTk widgets.
Other Doc
See TIPDoc.tioga
========================