On 27 January 2012 14:25, Henrik Johansen <[email protected]> wrote: > > 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...
Indeed. This is what we done for SystemXYZEvents. There can be various ways how you can represent "events" in your framework, but it doesn't changing the interface between VM and language side, and those thin wrappers serve as a clean and simple layer. Simply because we don't want a smelly code to spread around in image, which deals with bits and bytes generated by VM. > > 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... > Morphic can wrap system events (so you can always access the original in case if you really want them), or convert them into own. For instance , there is no "double-click" events generated by VM, while morphic having them. There can be other examples, like mouse gestures.. so morphic events are operating at completely different level than basic system events and while for some of them there can be straight correspondence between them, for some of them, obviously not . -- Best regards, Igor Stasenko.
