[Qt-interest] QStateMachine API and design?

Stephen Kelly steveire at gmail.com
Thu Nov 4 15:03:22 CET 2010


Sean Harmer wrote:

> Hi Steve,
> 
> On Thursday 04 November 2010 12:26:00 Stephen Kelly wrote:
>> After figuring out how to use QStateMachine to do what I want I have some
>> questions. I'm sure it's all deliberate, but I can't figure out why some
>> things are the way they are.
>> 
>> * Why is there no 'current state'? There is a configuration() which gives
>> me a set of QStates, but it doesn't tell me which one is the current one.
>> To get that I iterate over the set and analyse the parent() until I get
>> the 'most extended' state.
> 
> <snip>
> 
> I can see that you may expect this behaviour to be possible if only the
> deepest state was listed in the current configuration. However, it gets
> tricker when you start to consider SM's with parallel states in addition
> to the more usual mutually exclusive states.

Yes. I haven't figured out what parallel states are for though tbh.

> 
>> * Why is there no notification when the 'current state' is changed?
> 
> I have filed a bug for this after discussion with Kent:
> 
> http://bugreports.qt.nokia.com/browse/QTBUG-9380
> 
> Please vote for it or file a MR. It should be asimple change and it is on
> my list but time as always is short. A graphical SM debugger would also be
> *very* nice but that's a much larger task.

Done.

> 
>> My usecase is to create a state machine and expose it to QML so that I
>> can change the ui state on change of the application state.
>> Approximately:
>> 
>> Item {
>>   State {
>>     when : application.state == "connecting"
>>     PropertyChanges { target : myText; text : "Please wait" }
>>   }
>> }
>> 
>> I have that working by wrapping the statemachine and creating a
>> NotifyingStateMachine. I just wonder what the right way to do it is and
>> why there is no notification in QStateMachine. Am I missing the obvious
>> way to make application state available to QML through QStateMachine?
> 
> Another approach is to connect the entered()/exited() signals of QState or
> the triggered() signal of the transition. 

I connect to the entered() signal as you suggested and connect it to a 
custom stateChanged() slot on the statemachine itself, while the transition 
updates the state Q_PROPERTY of the state machine.

http://websvn.kde.org/trunk/KDE/kdepim/mobile/lib/statemachinebuilder.cpp?view=markup

> Or you can implement the
> onEntry()/onExit() functions in your own custom states. We have largely
> gone for custom states and used overridden onEntry() functions. Not sure
> if any of these would map cleanly onto a Qml scene though as I have not
> tried it in anger yet.

I would be interested in how you think it could work, or to see what one of 
your onEntry implementations look like.

All the best,

Steve.

> 
> Good luck,
> 
> Sean





More information about the Qt-interest-old mailing list