Hi,
It would be a pain if the buffer size is fixed. NeXTSTep/OpenStep had a limit of 50 events.
Sometimes 50 events was not enough - it is really annoying to have your keystorkes dropped - very confusing.
Other times there were too many event queued up (when the system was slow or not responding well) and you wish you had a way to cancel them all (when you make a mistake) - how about a special command key that erases the event buffer? "Cmd-ESC" or "Alt-ESC" if it's not used already by any operating systems or applications?
Could you make the "circular buffer" resizable by deallocating it and reallocating a new one if someone wanted it larger?
The linked list approach is still the best for unpredictable event list size. The size of the list shouldn't get too large, in normal usage, as the events would get "consumed" pretty quickly. If the old unlinked cells are kept on a free list then they can be reused over and over and a new one is only needed when the free list is empty. A number (128) of the them could be preallocated if needed.
If you do go with a circular buffer of a fixed size please make the size large - say 128 or 256 entries?
Peter William Lount peter@smalltalk.org http://www.smalltalk.org
---------- From: Tim Rowledge rowledge@interval.com
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.
squeak-dev@lists.squeakfoundation.org