[Qt-interest] QStateMachine API and design?

[Sean Harmer]

Hi No'am,

On 08/11/2010 18:39, noam.rosenthal at nokia.com wrote:
> I've prototyped an SCXML based implementation of this exact project a
> while ago. See
> http://qt.gitorious.org/qt-labs/scxml/commits/with-qml. That repo
> doesn't work now as QML was a moving target at the time, but it might
> give you some idea.

Ah cool. I was unaware of this.

> The main idea is that QML states/transitions and regular
> QStateMachine states/transitions are actually a different concept.
> You could have several "flow states" that actually affect a single
> "UI state" like the ones in QML.

Yes this did cause some confusion when I first started looking at QML. 
Once I understood the distinction then things became much clearer.

> In the prototype I mentioned above,
> you use properties and signals to bind the "flow states" to the "UI
> states", and I use the QDeclarativePropertyMap to allow a nice
> syntax, like binding to stateMachine.in.stateName.

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.

This is pretty much the same lines as I was thinking along.

> Unfortunately I don't have time to finish that project, but it looks
> like you guys are doing interesting stuff around the same problem
> space so maybe there's hope :)

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

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.

Thanks for the ideas regarding QDeclarativePropertyMap.

Sean