I worked some the last two weekend on a system to tunnel OS-level events up into Squeak, at least when using Morphic.  It functions on Unix, though it can use some more work.  Hopefully it can be a starting point for a more complete system (I plan to finish up the image support, but it takes extra code on the individual ports to make this useful).
 
The relevant files are on the swiki at:

	http://minnow.cc.gatech.edu/squeak/attachment/Input+Events.cs
	http://minnow.cc.gatech.edu/squeak/attachment/sqXWindow.c-events

I started to post them to the list, but read some light flamage and decided against it :)

In the middle, I mean, remainder, of this message, I will describe why one would want such a system, describe how the system works, and finally, address compatibility with MVC and with old images.


WHY BOTHER?

In short, it sucks to click too fast and for Squeak not to notice, or to double click on something and it triggers as a single click.  It also sucks having to hold the mouse button down half a second on buttons and menus to make sure they trigger.  Since most OS's supply mouse events anyway, and since Morphic is already built on top of (internally-generated) events, it seems blindingly appropriate to tunnel the OS-level events up and have Morphic use those instead of it's own internally-generated events.


Also note, the keyboard already works using events.  Squeak doesn't constantly poll the keyboard state to see if any keys are pressed down; it assumes the VM has a keyboard buffer, and it sends queries to the buffer instead.  The real effect of the below changeset is to do the same thing for mouse actions.



THE SYSTEM

By "input event" I mean one of the following five kinds of events:

	1. Mouse move, mouse down, mouse up
	2. Key down, key up


The first piece in the changeset below, is a hierarchy of classes used to represent these events in a Squeak image.  They are missing some obvious functionality, but they do implement the critical functionality of creating a MorphicEvent that contains the same information.

The second piece is an image-VM interface to poll the events.  The way this is done below is by:

	1. Adding a few methods to Interpretter (and regenerating interp.c).  The new methods call new io* functions in platform-specific files.
	2. Adding methods to InputSensor which use these new primitives.  I used name-based primitives, which may cause problems on some platforms, but which is really cool for experimental work :)

The io* functions fill in an array of five integers.  I figure it is easier to let Squeak code in the image build up real objects from these five integers, rather than trying to do something similar in the C files.


After that, the final piece was to actually add support to the platform specific files for events.  I did this for Unix, because that's what I use all the time.  The sqXWindow.c file in the next message, records all keystroke and mouse events that come in, and adds the needed io* methods to go through that queue.


Finally, a quick change to MorphicHand.handleEvents to use "Sensor nextEvent asMorphicEvent" instead of deriving MorphicEvents from the mouse states, and it all actually works.



COMPATIBILITY

The core of the traditional input interfaces are:

	1. Queries directed specifically to the keyboard, ie "keyboard peek" and "keyboard next"
	2. Queries to the mouse position and button state


First, the latter is actually useful even when you are using events.  I simply left that interface alone, and had it report the latest state of the mouse (even if there are events of the queue that report an earlier state).

Dealing with the keyboard is trickier.  If someone reads a key via the old interface, the key really should be taken off the input queue, so that the same key doesn't show up twice if you switch to an events-using Morphic project.  Furthermore, if the image uses only the traditional interfaces, then the input queue needs to be trimmed down at some point so that it doesn't grow forever.

The solution used in following sqXWindow.c is simple: stop using the old keyboard buffer, and instead have traditional keyboard queries simply drop events from the front of the stack until a key event is found.  The assumption behind this scheme is, if someone is using the traditional keyboard interface, then they aren't going to be interested in the mouse events anyway, and so dumping them is safe and even recommended.  If they break this assumption, then they are screwballs and deserve the chaos that they get :)




Lex Spoon