[Qt-interest] The State Machine Framework - do's and don'ts

[Sean Harmer]

Hi,

On 19/04/2010 09:33, Mihail Naydenov wrote:
> Thank You for your answer, I will give it a thought. (It really needs :))
>
> Still, Im kind of waiting for some qt guy to give a concrete answer what Qt's SM are (best) designed for.
> The sub-attack *can't* be "best practice", *though* its cool!
> I guess Im waiting for conformation or denial of that...

As K Frank said it is one possible choice on how to implement a 
sub-attack application. There is no right or wrong, just a choice with 
pros and cons as always.

> Also Im really curious if they consider implementing fully state driven GUI (where every, easy-to-spot state of controls is indeed implemented as private state) and if its feasible one to implement with the current SM.

Well this is exactly what the new QtQuick and QML stuff does under the 
bonnet. As I understand it, QtQuick uses a QStateMachine to manage a 
QGraphicsScene and it is all declared using the Qml language.

So yes it is possible to control an entire application from a state machine.

In our particular case at work, we are using a QStateMachine to control 
interactions with some hardware devices (over TCP or serial). This has 
simplified our code so much it is not even funny. Plus it has the nice 
side-benefit that the entire bahvioural aspects of the system can now be 
shown very compactly in a state chart. We have encapsulated the state 
machine plus all of its states inside a concrete class that the client 
applications can simply pick up and use without ever knowing that it 
uses a state machine internally.

We then have another product that consists of 15 of the above devices. 
So we have created another state machine that synchronises the 15 
component devices and provides some other high-level behaviour on top - 
this state machine uses the parallel sub-states feature a lot! We have 
then encapsulated this in another concrete class.

So for the above we have a class that uses a state machine that contains 
a number objects each of which themselves contain a state machine. This 
is just the partitioning of functionality/behaviour that works for us. 
You could however, easily imagine implementing all of the above as one 
large state machine.

As far as performance goes, we have so far not encountered any problems. 
The way the algorithm works is to only check transitions that have 
source states in the current configuration so unless you decompose your 
system into states such that the current configuration gets very large 
then you should be OK.

K Frank mentions that the QtStateMachine framework may not be th emost 
light-weight implementation but it does have a very big feature that 
other state machines lack for the most-part: signals and slots. It is 
laughably simple to integrate existing Qt components into your state 
machines.

My advice is to try it out in some real applications. The Qt examples 
are great for showing you how specific features work but as with most 
programming paradigms you only get a feel for it once your have used it 
a few times and run into the problems yourself. Feel free to come back 
to the list with specific problems when you come across them.

Good luck,

Sean