[Qt-interest] QStateMachine API and design?

[Mihail Naydenov]

O, my. Just noticed that QML state objects are NOT QStates :)
Not even a subclass of them. AND the QDeclarativeState is private.

So long about "native support of (q)states" and "custom QDeclarativeItem with 
predefined states". 

Hopefully this will change and both will merge because right now situation is - 
you ether do it in c++ (qstate) and be cool or in qml (private 
qdeclarativestate) and be cool there. Mixing these will get ugly.


I am a bit disappointed
MihailNydenov


----- Original Message ----
> From: Sean Harmer <sean.harmer at maps-technology.com>
> To: noam.rosenthal at nokia.com
> Cc: qt-interest at trolltech.com
> Sent: Wed, November 10, 2010 1:30:01 PM
> Subject: Re: [Qt-interest] QStateMachine API and design?
> 
> 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
> _______________________________________________
> Qt-interest  mailing list
> Qt-interest at trolltech.com
> http://lists.trolltech.com/mailman/listinfo/qt-interest
>