[Qt-interest] QStateMachine API and design?

[Sean Harmer]

Hi,

On Wednesday 10 November 2010 17:13:35 noam.rosenthal at nokia.com wrote:
> On Nov 10, 2010, at 3:30 AM, ext Sean Harmer wrote:
> > Ah I see. I wasn't aware of the existence of QDeclarativePropertyMap
> > (I'm still new to QML). Looking at the repo you linked to I see that you
> > essentially collapse the named states in the state hierarchy into the
> > flat QDeclarativePropertyMap where the key is the state name and the
> > property is a simple boolean to say if the corresponding state is in the
> > current configuration or not.
> 
> At least in SCXML, state IDs are unique throughout the document. Therefore
> the "flattened" approach made sense to me. 

OK. After thinking about it some more it may still do, see below.

> Also, at least at the time, the
> binding engine couldn't handle a complex hierarchy and the flat property
> map is the only way I could get away with dynamic bindings like the ones
> in this SCXML/QML integration. But maybe this has changed :)

I do not know. I've not looked behind the scenes at QML bindings yet.

> > I'll keep mulling this over as it is an interesting problem and the
> > solution is potentially very reusable. Some potential
> > issues/improvements that I cant think of are:
> > 
> > * Maintain some indication of the hierarchy in the state names that go
> > into the QDeclarativePropertyMap. Sometimes you may have several states
> > with the same name in different sub-trees of the state hierarchy -
> > especially when using similar parallel states. For example,
> > "redLight->on", "amberLight->on" and "greenLight->on" where all the
> > nested states are called "on" which would lead to degeneracy in the
> > list. What might be nice is if we can come up with a way of having a QML
> > syntax that models the state hierarchy in the C++ side. Something like
> > this:
> > 
> > State {
> > 
> >    name: "on"
> >    when: controller.inState.greenLight.on
> >    ...
> > 
> > }
> 
> Another issue I've had with using hierarchy like that is that sometimes you
> want to change your state hierarchy (e.g. putting greenLight inside a
> trafficLight state etc.), and you don't want to start modifying your QML
> bindings when you do that... if you work by flat unique IDs you can work
> around that problem.

Hmmm yes that is true. I was thinking about mature state machines rather than 
ones in a state of flux. I see how exposing the hierarchy may introduce an 
undesired level of coupling between the logical state machine and the QML 
states that bind to it.

Perhaps we could allow the SM writer the ability to specify what to expose the 
state as in the property map. I guess that is essentially what your prototype 
was doing by using the object name. It might be an idea to decouple it from 
the object names of the states though - of course the SM author is free to use 
the object names if they do not conflict so the behaviour of your prototype is 
still possible.

> > I guess this may need something new like a QDeclarartivePropertyTree.
> > I'll investigate if this is needed or if it can be done with existing
> > classes.
> > 
> > * Possibly allow the C++ developer to register which states in the
> > hierarchy should be exposed via the property map. This will allow the
> > C++ developer to only expose the parts of the state hierarchy that are
> > actually necessary for reflecting operational state in a GUI. This could
> > be a performance boost as sometimes you do not need to expose all of the
> > states.
> > 
> > For example we have a pretty complex SM used to control some data
> > collection devices. All the GUI and end/user need to know is what mode
> > the device is in (Idle, Measuring, Moving etc). However, the internal
> > state machine has many many states inside of each of these modes that
> > are used to control the actual hw. The GUI does not and should not know
> > anything about these deeper states.
> > 
> > I can think of 3 ways of exposing the state hierarchy:
> > 
> > 1). Completely automatic as you have done in the above prototype
> > 2). Automatic with some filtering e.g. down to a maximum depth
> > 3). Manual registration of which states to expose.
> > 
> > Of course if we can maintain the state hierarchy as proposed above then
> > option 3) would also have to expose the parent states of any manually
> > registered state if the parent had not already been exposed.
> > 
> > I think what I will do is to carry on with this traffic light example
> > (it's as good a place to start as any) and extend it to see if I can get
> > the above ideas working. Then if it looks OK (I'll ask for feedback)
> > then I can try to abstract the mechanisms into a reusable class that can
> > be picked up and used to very simply expose a SM to QML.
> 
> Awesome ideas; Good luck :)

Thanks. I'll make a git repo at some point and try some of these ideas out. 
I'll keep you posted.

ATB,

Sean