Actually, I can't see any huge diferences at all in the basic workings.

> * InputSensor compatibility
I had the impression I had managed that as well

> 
> * Decoupling Morphic and Events
OK, makes sort of sense but hardly matters one way or the other.
> 
> * A somewhat different event format
A useful small change - like my code's comment said:-
>>>	since most events will be keyboard or mouse related, it seem reasonable to try to optimise for them.
>>>	Thus we will start off with a simple Array-like grouping of:-
>>>		event type
>>>		mouse pos x
>>>		mouse pos y
>>>		button state
>>>		keypress
>>>	which seems quite easy to live with for for most platforms.
Adding some extra room for other more complex events in the future is a
no brainer.
>
> [snip] Thus, whenever you ask for "Sensor mousePoint" you
> will get the latest mouse position regardless of the events still in the
> queue. This is useful since most users of Sensor use want to see a quick
> snapshot of the current state rather than an outdated state from possibly
> several hundred milliseconds before.
Same in my code, unless there is a relevant event in the queue. One
possible problem with your 'latest state' details - I can't prove it,
but I have a feeling from my ponderings that it is quite important to
flush the event queue down to the event responsible for the state you
are returning. Something about getting an event later that has in some
sense already been handled worries me.
> 
> Events itself are read in by a process running at #lowIOPriority. This
> process waits either waits for a specified amount of milliseconds between
> looking for more events or can be triggered by an event semaphore. You may
> ask why I'm using two mechanisms here but the answer is simple. Most VMs
> will not support true asynchronous notifications about events so we do have
> to poll at some point. If, however, the VM does support async event
> notification, the semaphore can be used to signal incoming events. The
> design of the EventSensor allows for both mechanisms.
Just like the InterruptEventSensor class I included...

> 
> User interrupts. These are handled by the ioProcess running in EventSensor.
That's a good improvement, essential if we really want to use a process
to reap events. As I said in explanatory email.

> 
> I'm sending this CS as a base for discussions.
Ok, so it's fine so far as it goes. It'll certainly work ok on the
platforms I know anything about (though I _still_ can't find a way to
get my &^%^ing Acorn to give me mouseUp events!) pretty well.

I think the changes to HandMorph etc that I included to improve their
event behaviour are also very important. Without code analogous to that,
there is very little point ot having any sort of event handling in the
VM or anywhere else!

>  I'm still trying to
> figure out how to prevent the C support code from creating raw oops (another
> thing I don't like is that with Tims implementation you have to create oops
> yourself).
Huh? It makes SmallIntegers (or potentially LPIs I guess). What's the
problem with that? What else is one going to use? Just change the prim
I wrote for primitiveNextEventInto() to handle an eight element array.

I don't care much how the details are done so long as they work and we
get them into the system asap. The middle level details are important to
make any of it worth it. The higher level details of making a whole load
of code behave with events is much more work and much more important.

tim
-- 
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Useful random insult:- Several nuts over fruitcake minimum.