[Pharo-project] Rethinking the event's handling in Gaucho/Morphic

Stéphane Ducasse stephane.ducasse at inria.fr
Mon Jan 23 05:21:26 EST 2012

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.

Now more time to answer.
Indeed HandMorph looks to me like having too many responsibility
	- transform low level event into high level
	- manage the Morphic interaction loops
	- looks like a cursor

> The GUserInterface listens to VM events, and process them as they arrive.
> GUserInterface>>process: aSensorEvent dispatches to either the mouse
> or the keyboard.

	in what we are putting in place we use double dispatch because 
	we want to be able to plug new event

> 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.

interesting. Indeed it looks to me that using a state pattern should be a nice way to 
handle the Morphic logic 

Now I do not understand the arrows to the big Mouse.

> For example: if a #up: 10 at 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.

Yes I really want to see that.

BTW benjmain should contact you about the eventHndling in Morph because you show me at Edinburgh that 
you put in place a different way to model them using a kind of strategy pattern. 

> 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.

I like the idea that you dispatch to the peripherals now what we encounter 
with igor is that handMorph need to keep the previous system event and modifiers
so is the distribution to Mouse, Keyboard supporting that?

For example, the recent bug in taskList anyModifiersKeyPressed was due to the fact that 
TaskLIst was asking inputSensor directly and not handMorph and that handMorph did not have the 
same API. We fixed part of it.

(Morphic code should go via HandMorph and not directly to the low level input sensor).

> 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.

Fernando if you have a look at EventModel
we are asking ourselves the following questions:
	- HostMenu management looks not the way we want (right now it hijacks low level event and produce event to simulate)
	we are thinking that the HandMorph (or User Interface in your case should be responsible for deciding to publish menu 	
	as host menu and host menu should be able to call the same code than default menu.

	- We want to look at the API of InputEventSensor (using event but)  and SystemInputEventAnnouncer (using events!)
	and check the various users and fix them because we do not want the system to rely on InputEventSensor and its eventBuf

> 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,

We should sync because we really want to finish to clean the eventBuf handling 
so if you can have a look it could help us. We can do a chat if you want.

> still working on make it render
> with Athens.
> <mouseFSM.png>

More information about the Pharo-dev mailing list