"Raab, Andreas" <Andreas.Raab at 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