[Qt-interest] QStateMachine API and design?

[Stephen Kelly]

Sean Harmer wrote:

> Hi,
> 
> On Thursday 04 November 2010 14:03:22 Stephen Kelly wrote:
>> Yes. I haven't figured out what parallel states are for though tbh.
> 
> We have mainly made use of them where in some hardware devices we have
> multiple subsystems which are more or less independent (although you can
> still have some dependencies between them using guardded transitions).
> 
> For example we have a SM with 15 subsystems representing 15 pieces of a
> type of pcb and an overall "system mode" state. All of these are arranged
> under a top-level state as 16 parallel states. Each of these then has
> substates in the usual manner. The system mode state and each pcb are
> mostly independent but are part of the same SM because the system mode
> initiates actions on each of the pcb's and the pcb's notify progress by
> posting events to the SM. Then all pcb's have performed a required task
> then the system mode gets updated.
> 
> NB: In turn each of the pcb's are QObjects that themselves contain a SM
> that manages the inner logic of the pcb's. I find it helps to keep the
> SM's relatively self-contained and as simple as possible rather than
> having a single monolithic one.
> 
> Applying this to a GUI, you could envisage using parallel states if you
> have several widgets on a form that are more or less independent. For
> example a dialog with two tab widgets on them. The current tab for each
> tab widget could be managed by a SM containing two parallel states.

Yes, I see what you mean and why parallel states could be useful in that 
situation. I think in my situation I don't need them, so it should make 
things a little simpler.

>> 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?v
>> iew=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.
> 
> OK. I'll see if I can put together a simple Qml + SM example. I may have
> some time this evening.
> 
> Here is a sample onEntry() implementation as an example. It is nothing
> special:
> 
> <snip>
> 
> Hope this helps a litle.

Yes, thanks. It's interesting to see a detailed description of how others 
use the state machine framework.

> 
> Cheers,
> 
> Sean