On May 6, 2013, at 2:31 AM, Carla F. Griggio <carla.grig...@gmail.com> wrote:

> Hello everyone!
> I'm here to tell you that I started experimenting with a Pharo implementation 
> of this idea: http://swingstates.sourceforge.net/. For those into UI 
> programming I really recommend reading the first paper cited in that page. 
> It's for programming user interface interactions with state machines, an 
> approach to avoid the classical "callback spaghetti" that sometimes we get 
> with event handlers everywhere.

This is looking interesting. Now we should check how it works with inheritance. 
Keep us posted about your progress.

Stef

> I have a tiny first step that shows an example for changing the color of a 
> button on mouse over and changing it back to the original color on mouse out.
> 
> You can download the code from: 
> http://smalltalkhub.com/mc/CarlaGriggio/StateMachines/main
> 
> Evaluate this for executing the example:
> 
> SMButton openWithStateMachineInteraction
> 
> And here is the code of the state machine for that example:
> 
> SMButton class >> openWithStateMachineInteraction
> |button stateMachine iddle hover |
> button := self new.
> stateMachine := SMStateMachine newForWidget: button.
> iddle := (SMState newWithName:'iddle')
> enter:[:stMachine | stMachine widget color: Color yellow ];
> addTransition: ((SMTransition forEvent: 'mouse enter' withOutputState: 
> 'hover')
> transitionAction: [:stMachine | stMachine widget color: Color red ]).
> hover := (SMState newWithName:'hover')
> addTransition: (SMTransition forEvent: 'mouse out' withOutputState: 'iddle');
> addTransition: (SMTransition forEvent: 'mouse enter' withOutputState: 
> 'hover').
> stateMachine addState: iddle; addState: hover.
> stateMachine attachTo: button.
> ^button openInWorld
>  
> That code corresponds to the following states diagram:
> 
> <Screen Shot 2013-05-06 at 2.27.20 AM.png>
> 
> I will keep experimenting with this during the next weeks, and specially try 
> to compare the pros and cons with regular event handling.
> 
> Something cool about this approach is that the same widget could change its 
> interactive behaviour on the fly by just attaching a different interaction 
> state machine to it :) 
> 
> Also, I'm doing this for programming user interface interactions, but it 
> could be useful for anything that can be modelled with a state pattern.
> 
> Is there something similar out there already working? I was so eager to try 
> this that I didn't look for related existing projects.
> 
> Cheers!
> Carla.

Reply via email to