thanks tim
this looks indeed serious.

Just the name of  CurrentProjectRefactoring reveals that this class 
should not survive

Stef

On 12 févr. 04, at 06:03, Timothy Rowledge wrote:

> 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'
>
>