Hi fernando can you have a look at EventModel on squeak source because we are cleaning the evtbuf and creating systemInputEvent and we will integrate that soon.
STef On Jan 23, 2012, at 1:18 AM, Fernando Olivero wrote: > Hi, in the context of the new UI framework i'm developing for Gaucho, > i've decided to design the event handling part as follows: > > The entry point to the framework is an instance of aGUserInterface , > which collaborates with a set of peripherals: in the standard case it > holds a: 1)aGDisplay 2) aGMouse and 3) aGKeyboard. > > The GUserInterface listens to VM events, and process them as they arrive. > > GUserInterface>>process: aSensorEvent dispatches to either the mouse > or the keyboard. > GKeyboard>>process: distinguishes between keyDown, keyUp, and > keystrokes, and reacts accordingly. > GMouse>>process: finds the proper reaction depending on the context > of the mouse. > > The keyboard handling logic is quite simple. > > The mouse is significantly more complicated, because the mouse events > produce a different action depending on the current "mode" of the > mouse. I modeled this problem, using the State pattern, depicted by > the attached FSM. For example: if a #up: 10@10 arrives, and the mouse > is on "dragging mode", would result in the evaluation of the message > GMouse>>dropped: aGShape at: aDisplayPoint. > > The usage of the state pattern, simplifies the coding of the reaction > to each of the mouse events (#up:, #move:, #down:,#secondaryDown:), > according to the mouse's context. And provides a hook for > altering/augmenting the behavior as well. > > There's no need to reify the events in the design, events are > generated by the user, encoded by the VM, decoded by the > GUserInterface and dispatched to the proper peripheral device. > > Other Peripheral devices can be easily be attached, for now i'm > sticking to the standard display, keyboard and three button mouse. > Changes to the VM may still be needed to encode the User actions of > the external device, but in the image would be straightforward to > "plug and unplug" devices. > > I'm interested in hearing your opinions or remarks on the design, or > if i've omitted a state or transition from the FSM. > > Thanks in advance, > Fernando > > pd: An intersesting side effect is that i can test low level mouse > actions, such as drag and drop, hovering and unhovering, etc.., > resulting in a more robust framework. > pd: Soon i will release the framework, still working on make it render > with Athens. > <mouseFSM.png>
