Tim Rowledge <rowledge at interval.com> wrote:
> On Tue 29 Jun, Lex Spoon wrote:
> [SNIP]
> 
> You could have saved one of your weekends by grabbing the event stuff I did
> months ago! I think it's better to get as much as possible into the generated
> code, so I put the event queue handling in Interpreter. It also reduces the
> load on the platform code files.
> See http://sumeru.stanford.EDU/tim/pooters/SqFiles/deltas/sq23Events.zip
> 
> tim
> 

I believe we are working on different things.  You did up a general event system, right?  All I wanted was to tunnel up a handful of specific kinds of events.  Since I don't know how general event systems work, and since I *do* understand how semaphores and linked lists worked, I went with what I know.  

This is not to say rolling input events up into a more general system would be a bad idea--I really have no idea.  Can you elaborate on how a general event mechanism would be useful here?  What other kinds of events might we want to use, where raw semaphores don't cut it?


Also, I didn't talk about it, but the requirements on the platform-specific part of the VMs are about as low as I can imagine them being.  Individual platforms must implement code to record input events into a queue, and code to do various queries on that queue.  Preferably they also rewrite the keyboard queries to use the new event queue, so that MVC and Morphic can coexist.

How much less than this can you get away with?  I guess you could try to put the queue in the platform-generic section, but it's not a huge win.  It might even be a loss, on systems where the OS already has a nice queue to use.  (I didn't use the OS-level queue in XWindows, because that same queue has other kinds of events like window redraw requests, but it might be more convenient on other platforms).



Lex