[Qt-interest] QStateMachine API and design?

[noam.rosenthal at nokia.com]

Hi guys
I've prototyped an SCXML based implementation of this exact project a while ago. See http://qt.gitorious.org/qt-labs/scxml/commits/with-qml.
That repo doesn't work now as QML was a moving target at the time, but it might give you some idea.

The main idea is that QML states/transitions and regular QStateMachine states/transitions are actually a different concept. You could have several "flow states" that actually affect a single "UI state" like the ones in QML.
In the prototype I mentioned above, you use properties and signals to bind the "flow states" to the "UI states", and I use the QDeclarativePropertyMap to allow a nice syntax, like binding to stateMachine.in.stateName.

Unfortunately I don't have time to finish that project, but it looks like you guys are doing interesting stuff around the same problem space so maybe there's hope :)

No'am

________________________________________
From: qt-interest-bounces at trolltech.com [qt-interest-bounces at trolltech.com] On Behalf Of ext Sean Harmer [sean.harmer at maps-technology.com]
Sent: Monday, November 08, 2010 10:20 AM
To: qt-interest at trolltech.com
Subject: Re: [Qt-interest] QStateMachine API and design?

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
_______________________________________________
Qt-interest mailing list
Qt-interest at trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-interest