[Qt-interest] QStateMachine API and design?

[noam.rosenthal at nokia.com]

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

> 
> 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 :)
No'am