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

[Mihail Naydenov]

Thanks for Your answer, it was helpful.

For now I decided to play it safe and not use a machine until I encounter a scenario where I need to do different things on the same object, based on some condition(s). (Basically waiting the nasty if/else and switches to start to appear, then I will refactor to state machine)

Before I was tempted to implement my controls as state aware (a button having "pressed" "released" internal state etc.), but this seams as overkill for now.

thanks
MihailNaydenov


----- Original Message ----
> From: Sean Harmer <sean.harmer at maps-technology.com>
> To: "qt-interest at trolltech.com" <qt-interest at trolltech.com>
> Sent: Mon, April 19, 2010 12:26:59 PM
> Subject: Re: [Qt-interest] The State Machine Framework - do's and don'ts
> 
> 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
_______________________________________________
Qt-interest 
> mailing list

> href="mailto:Qt-interest at trolltech.com">Qt-interest at trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-interest