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
squeak-dev@lists.squeakfoundation.org