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

-- 
Useful random insult:- Kept an open mind -- and his brains fell out.
Tim Rowledge:  rowledge at interval.com (w)  +1 (650) 842-6110 (w)
 tim at sumeru.stanford.edu (h)  <http://sumeru.stanford.edu/tim>