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 <[email protected]> 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 <[email protected]> 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.
