[Qt-interest] State Machine implementation

[Mandeep Sandhu]

>
> 2) regarding the state machine, I'm not sure how to implement it...
>  - each state should contains what I want to display ?
>    ie I will have a displayState class which inherits from QState (or
> QAbsctractState ?) and the onEntry() will show the objects I want to display
> ?
>  - or I create what I want to display somewhere, and use the state machine
> on those objects to display them ?
>    Like in the Qt example, they create a QPushButton, and the states are
> linked to the button and its signals.
>

I might have some thoughts on this point :)

We're using state machine in our application as a 'controller' component in
an MVC design.

Here's how we use it:
* Transitions (or navigation) from one screen to another is controlled by
the SM. The SM transitions use our own custom events to decide which state
to go to.
* Each 'state' of the SM represents a viewable screen. BUT, the screen
itself is implemented as a QWidget (it's not a QState subclass) and we have
a way of 'registering' such 'screen widgets' to the SM.
* This 'registration' ensures that the appropriate 'callbacks' (like
enter/exit state) are called on the screen widgets to let them know when a
screen becomes visible and when its' not.
* We also control the 'visibility' property of the screen widget using the
property assignment feature of QSM. This means that screen-widget A, is
visible when SM is in state A and hidden when in state B (correspondingly
screen widget B would be visible in state B and hidden in state A).
* The actual display elements are implemented as independent QT components
(using Qwidgets etc) and each screen 'has a' component for displaying the
actual UI. eg: if I have to show a table in a screen/state, then I'll use a
QTableView which is created by the screen widget it represents. The screen
widget is set as the parent widget of all the component widgets used inside
it. This ensures that when a screen is not visible, all its sub widgets are
hidden as well.
* We code the SM to react to our own custom QEvents. Each screen component
informs its parent screen of an action, by regular signals/slots. The
handlers for these signals then decide what 'SM event' to post to the
machine. We could have directly used QSignalTransition and friends, but in
some cases this was not possible and hence we chose to post our custom
events manually.
* We also have a way of passing arguments from one state to another so that
the receiving state can take certain specific actions based on what was done
in the previous state.

HTH,
-mandeep



>
>
> I have more questions regarding the state machine (like QSignalTransition
> and stuff), and about QML-3D, but I think I'll start with that :)
>
> Thanks for your help !
> cheers
>
> _______________________________________________
> Qt-interest mailing list
> Qt-interest at qt.nokia.com
> http://lists.qt.nokia.com/mailman/listinfo/qt-interest
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.qt-project.org/pipermail/qt-interest-old/attachments/20110202/b14b1634/attachment.html