In message <4.1.20000808141445.00939ad0 at ux2.sp.cs.cmu.edu> you wrote:

> That ties into another of my beliefs: we need interrupt driven events, not
> polling.
That would be nice, but most GUIs get their events by polling calls
(GetNextEvent, wimp_poll etc) and have little to support actually
getting interrupts to alert one of an event. If you can do OS threads
you can sometimes work around this somewhat - but it's horribly
non-portable. Events and interrupts are quite seperable, as the event
stuff I recently did demonstrated. Andreas proposed a variant that we
have agreed could live with either capability (depending on the OS) and
that should be releasable sometime soonish.


>  Polling results in lost events or delayed event handling, both of
> which are miserable for usability.
Polling _for state_ can cause that. If the OS queues up events and you
have to poll for them then you don't lose events. You may however be
delayed, of course.
>  Squeak should be able to guarantee that
> user inputs will be handled within ~100 ms (preferably < 50 ms), even if
> the system has to interrupt computation to do it.  And no user action
> should ever, under any conditions, be lost.
Agreed about the no-losing aim, but you have to be careful about the
'handling the user input' part; I doubt you would be happy to see the
response to one action interrupted to repond to a later one!
> 
> Regardless, the system could bundle the modifier key status into the mouse
> down (or keyboard) event, so that the programmer can determine both what
> the state of the modifier keys were when a key press or mouse click
> occurred, as well as their current state.
Exactly what my event code did.

-- 
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Your password is pitifully obvious.