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.