[Qt-interest] QStateMachine API and design?

[Sean Harmer]

Hi,

On 08/11/2010 18:00, Mihail Naydenov wrote:
> Considering qml has native states support, what is the need to hide a state
> machine behind a bool property?
> I am really asking, because I am learning still.

Well this is just my first attempt at doing it with a trivial example. 
It may be that as I make the example more complex and representative of 
a real world use case a different approach may be needed.

The shortcomings with the QML states are:

* Lack of hierarchies of states
* No guarded transitions
* No history states
* Difficult to do extra work other that GUI manipulations from QML

> Why not write a custom QDeclarativeItem with already predefined list of states
> ("application states" the OP needed)?
> Then anyone can hook to item.state and app states switching is handled behind
> the scenes in item.
> Isn't it possible?

Yes that may be possible. Yet another approach would be to expose the 
interesting QState objects themselves via properties on the containing 
object. Of course you only need to expose the states that the GUI 
potentially cares about. Many deeply nested states may of course only be 
an implementation detail for marshalling other blocks of work that the 
gui doesn't care about at all (e.g. writing to some registers of a PCB 
controlling the real traffic light system and then verifying the the 
write was successful).

> Just the whole example feels like some workaround of something QML should excel
> in.
> The fact that QML does not even see states does not feel right...

Yes I know what you mean. My alternative approach may overcome this. 
I'll give it a try in a more detailed example. These are early days for 
QML and not much best practise is yet available in the community.

Thanks for your feedback,

Sean