On Jan 27, 2012, at 1:39 30PM, Guillermo Polito wrote: > "Event handling, and the philosopher's keyboard" > > I've downloaded Stef and Igor's EventModel to play with their new event model > :). I've created KeydownEvent and KeyupEvent in contrast to the generic > KeyboardEvent with all the information. It's very simple code, but, that is > the api I'm talking about. > > Gofer it > squeaksource: 'GuilleUtils'; > package: 'EventModel'; > load > > | ann evt | > ann := SystemInputEventAnnouncer new. > ann subscribe: SystemInputEvent send: #dispatchEvent: to: World activeHand. > > 10 timesRepeat: [ > 500 milliSeconds asDelay wait. > evt := Sensor nextEvent. > evt ifNotNil: [ > ann handleEvent: evt > ]. > ].
My 2c: To me, the events just look like thin wrappers around the buffers where you can get values by name rather than by index… You need to do the deconstruction of buffers to objects _somewhere_, personally I that place should be before they are handed to specific consumers (like Morphic). I mean, the types are defined by the VM, and not really up for individual interpretation by different frameworks... For SystemKeyboardEvent, that would mean: - Create subclasses of SystemKeyboardEvent, one each for KeyPressed/KeyDown/KeyUp. - Change SystemInputEvent to do newFromBuffer: instead of new initFromBuffer: - Change SystemKeyboardInputEvent to instantiate the correct subclass. Same applies for f.ex. SystemWindowInputEvent, where a consumer might look like: SystemInputAnnouncer subscribe: WindowMetricChanged do: [:ann| ...], and not SystemInputAnnouncer subscribe: SystemInputAnnouncer: SystemWindowInputEvent do: [ann | ann action = WindowEventMetricChange ifTrue: […]] Will there be duplication between Morphic and SystemEvent announcer in distinction of events? Yes, until Morphic is rewritten to use the announcements directly, instead of creating its own representation of the same classes. But removing that duplication (on the Morphic side of things) is a very natural next step... Cheers, Henry
