OS-level input events

Lex Spoon lex at cc.gatech.edu
Tue Jul 13 19:04:24 UTC 1999



I posted a newer version of my input events project to the swiki.

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


Things that have changed:

	- a timestamp is recorded on each event
	- a couple of access methods have been added such as #keyValue
	- for compatibility, processEvents will manufacture mouse motion events if the queue is empty
	- a performance bug was fixed in the sqXWindow.c file
	- I posted a patch in addition to the big C file :)


Some things that need to be done for this to be widely usable:

	- finish up the accessors
	- port to at least one other platform :)


Some possible enhancements that might yet be made:

	- modify the morphic loop to actually *use* the semaphore that the platform specific handlers signal :)
	- allow the image to set/query the size of the platform-specific queue?
	- pass double-click information up, on platforms that support such a thing?



So let me toss out a couple of questions, to maybe spur the other parties into discussion.

First, does the interface described seem workable on other platforms?  (and, Ian, does it seem like not too gory of a hack to sqXWindow.c? :)).  You can get an idea what's needed by reading the Unix platform's patch, but to put it in English, the platform-specific files would have to do the following:

	- store input events into a platform-maintained queue
	- implement "peekevent" and "getevent" functions that store the events into a 6-element word array (type, keyOrButton, cursorX, cursorY, buttonStates, time)
	- modify the keyboard peek and get primitives to use this queue instead of the one they have now (for compatibility)
	- leave the mouse-position and mouse-button-state primitives alone


Second, does this whole approach seem like a worthwhile endeavor to others out there?  IMHO, it is.  In particular, the bottom of Morphic is based on mouse/keyboard events, and the top of most OS's provides such events.  This approach seems to me the shortest possible path to getting input via OS input events.

One argument against this approach is the desire to eventually have a more general event system for Squeak.  However, such systems are still being hashed out, as far as I understand, and in any case the platform-specific work would be about the same in either case.  There would be little waste even if Squeak starts using a more general event system at some point.

Third question, what do people think of the compatibility system and arguments I proposed?  The basic mechanism is, don't change the traditional mouse primitives, but do change the keyboard primitives.  The new keyboard primitive should search for key-down events in the input queue.  Furthermore, the keyboard primitives should *dump* mouse events until a keyboard event is found in the queue, instead of just skipping over them.  One result is that, so long as a compatibility-interface program queries the keyboard every once in a while, the input queue will not grow arbitrarily.  Another nice result is that when you switch from MVC to Morphic, you don't have a big queue of mouse click events that immediately get fired.

By the way, whatever it's theoretical properties, this compatibility scheme seems to work fine on at least one system--mine. :)  I can switch between morphic and MVC without trouble, and I can run my image on an unmodified Windows VM without trouble.


Any other thoughts aside from the above questions?


Lex


PS -- if you want to see a truly unrecoverable crash, try ruining both mouse and keyboard input at the same time!





More information about the Squeak-dev mailing list