Tim Rowledge rowledge@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
On Wed 30 Jun, Lex Spoon wrote:
I believe we are working on different things. You did up a general event
system, righ
t? All I wanted was to tunnel up a handful of specific kinds of events.
I _think_ they're the same, but I have been wrong on several occasions this century :-) I did a quick example that handled the 'screnn size has changed' event, just to show how it wokred and to illustrate the possibility of events other than key/mouse being useful.
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.
Nothing wrong with that at all; the stuff I wrote uses a simple circular buffer for exactly the same reasons. The one advantage I can see with a fixed circualr buffer is no need to allocate new chunks; the obvious disadvantage is the chance of overflowing.
Also, I didn't talk about it, but the requirements on the platform-specific
part of th [SNIP]
How much less than this can you get away with?
It's not a huge difference, but putting the queue and handling in Interpreter does mean that nobody else has to implement it, makes it simulatable, provides at least a modicum of documentary facility and means less C code to suffer from. I really, really, hate having to write C when I can make the code generator do the scut work. I'd rather extend the CCodeGenerator than manually write C...
I quite like your image side stuff as a way of expressing the events. Looks like it could extended to ScreenSizeChange, ExternalFileSystemChange, and various other useful outside events quite nicely.
tim
squeak-dev@lists.squeakfoundation.org