"Raab, Andreas" Andreas.Raab@disney.com wrote:
Lex wrote:
Hmm, I just put these two ideas together. On Unix, the timestamps for X events are going to be based on a completely separate clock from the ones for sockets.
Whatever the time stamps are they should be based on what is reported by #millisecondClockValue so that the ST side can actually figure out how old an event is. There is no much use for a time stamp if you don't know the clock it's based upon.
Well, there is *some* use. If you want to check for double clicks (bleck), then you only need for the timestamps on mouse events to be consistent, and you don't need them to be consistent with the timestamps on, say, socket events.
I'm wondering how general purpose we really need to be. One of the cool things about Squeak is that it has very few tie-ins to the underlying OS. So how many event sources are we expecting?!
Do we really need timestamps on socket events?! And why has no one suggested putting sound-player events in the queue? Those are (potentially) asynchronous.
Input events certainly make sense. Also, timestamping input events makes sense. But do we really need a Squeak-wide abstraction for events in general? And does it have to be more than a handy semaphore-signalling mechanism?
-Lex
squeak-dev@lists.squeakfoundation.org