Nothing prevents from registering an instance of UserInterruptHandler , outside the Sensor code. But i've noticed that this registering was done in #installEventSensorFramework:, and no reference to the interrupt handler was kept by the Sensor. So made me think that Sensor should keep a reference to it. The question is wether we need a special case for the UserInterruptHandler, i think we should not. By special case i mean, an extra single purpose "Sensor". It could be done more transparently by relying on a single Sensor. Evidence of it is that UserInterruptHandler can be customized for any keystroke, yet the settings are called CmdDotEnabled. Using the new Event-Model, user interrupts can be customized by the client processing the system events, no need to have a special user interrupt handler class. The client would process a normal SystemKeyboardInputEvent, and do whatever it wants in case the keystroke was the current user-interrupt keystroke. For example, in Gaucho : GKeyboard>>keystroke: aGKeystroke …. aGKeystroke isUserInterrupt ifTrue:[ userInterface processUserInterrupt ]. ... In Morphic, the HandMorph would have this responsibility. Or we can push this bypassing of the keystroke handling to the SystemEventsAnnouncer. Does it make sense? Fernando On Wed, Feb 1, 2012 at 4:13 PM, Igor Stasenko <siguctua@gmail.com> wrote:

err... you seems like crossing multiple layers by doing that.

Because before you were able to have interrupt handler without having a sensor. Now you cannot have interrupt handler without having sensor installed.

On 1 February 2012 14:14, Fernando Olivero <fernando.olivero@usi.ch> wrote:

...

Please integrate/review this one.

In the context of replacing the current event handling mechanism, for the new Event-Model using announcements, i found out that the UserInterruptHandler is somehow treated as a global.

See

 InputEventSensor>>installEventSensorFramework: fetcherClass.     ….    "Register the interrupt handler"     UserInterruptHandler new registerIn: InputEventFetcher default.     …….

What if you want to replace the user interrupt handler for another? It cant be done transparently.

I've added the userInterruptHandler as an ivar of the current Sensor, so when it registers and unregisters, it takes care of registering and unregistering its user interrupt handler.

So you can plug different user interrupt handlers to the current sensor.

Fernando

-- Best regards, Igor Stasenko.