This is not a changeset of code implementing a new sensor class. I 
don't have time to tackle that right now! However, since I had been 
looking at the classes and worrying about them recently I though I 
should write down my thoughts in the hope that someone might find them 
useful.


InputSensor/EventSensor notes

Variables

InterruptSemaphore - EventSensor has interruptSemaphore as an ivar as 
well. Mixed initialise and references (see users of both).
EventPollFrequency - unused after Andreas' removal of inputProcess. 
Remove.
mouseButtons - used to hold latest state of mouse buttons. Updated in 
processMouseEvent: and processKeyboardEvent:
mousePosition - holds latest position of mouse. Updated in 
processMouseEvent:
keyboardBuffer - appears to be unused given event handling VM. 
primKbdPeek & Next seem to work from eventQueue. procesKeyboardEvent: 
explicitly ignores when eventQueue is non-nil (always)
interruptKey - see note B.
interruptSemaphore - signalled when interrupt key pressed. Current VMs 
seem to do that and pre-empt the processEvent: method? See also 
InterruptSemaphore class var in InputSensor.
eventQueue - seems to be used in all cases now.
inputSemaphore - seems to be used ony as a flag for the VM. Some VMs 
signal it for each event, some for 'some events happened' and some 
don't bother. Purpose?

Methods

EventSensor> startUp
- sends #shutdown but EventSensor>shutdown does not send super shutdown.
InputSensor>shutDown terminates the InterruptWatcherProcess twice but 
seems to be unused. InputSensor>installInterruptWatcher seems to handle 
it ok.
- sends super startUp to use InputSensor>startUp which 
installInterruptWatcher (which uses the class var form of the 
interruptSem reference above).
- sends flushAllButDandDEvents, which the #initialize has already done.

EventSensor>initialize
- sets interruptKey but doesn't use prim to tell VM about it. The prim 
method claims to be obsolete. VMs seem to still have it. It ought to be 
set from a platform preference or attribute or similar.
- it further appears to have old back-compat code wrt 
specialObjectsArray? Should the interrupt sem still be there?
- sends #flushAllButDandDEvents AND EventSensor>startUp sends Smalltalk 
isMorphic ifTrue:[self flushAllButDandDEvents]. Seems a bit messed up.

EventSensor>primGetNextEvent: - are there any VMs that do not have 
event prims? If not, dump the backup code and stop having to support 
it.

EventSensor>processKeyboardEvent: - since 
EventSensor>flushAllButDandDEvents makes sure that there is always an 
eventQueue, we can never get to code that expects it to be nil. See 
#queueEvent:, primKbdPeek, processKeyboardEvent:, primKbdNext, 
flushEvents, flushNonKbdEvents, peekEvent, nextEvent (implies 
nextEventSynthesized should go) and of course flushAllButDandDEvents.

Notes

A) no need for class variable InterruptSemaphore.
B) setting of interruptKey and the prims to set it and the sem should 
be looked into
C) if the sensor is really a singleton, then make it a clean one.
Somebody needs to exorcise 'CurentProjectRefactoring'