[Interest] QStateMachine as C++ (or Python) backbone of QML app

[Elvis Stansvik]

2016-05-08 20:57 GMT+02:00 Elvis Stansvik <elvstone at gmail.com>:
> 2016-05-07 22:12 GMT+02:00 Elvis Stansvik <elvstone at gmail.com>:
>> 2016-05-07 21:39 GMT+02:00 Elvis Stansvik <elvstone at gmail.com>:
>>> Hi all,
>>>
>>> Back in 2010 there were a couple of interesting threads on this list
>>> regarding the use of state machines:
>>>
>>>     http://comments.gmane.org/gmane.comp.lib.qt.general/29861
>>>     http://comments.gmane.org/gmane.comp.lib.qt.general/36760
>>>
>>> In the second one, which was about using a C++ QStateMachine based
>>> design for the backend logic, and making it available to QML, Sean
>>> Harmer describes his approach in a very good post.
>>
>> To clarify, I'm talking about this answer:
>>
>>     http://permalink.gmane.org/gmane.comp.lib.qt.general/36869
>>
>
> Sorry for replying so much to myself here, but a question about the
> approach you show in your trafficlight example:
>
> In the example, you expose a QObject representing the traffic light,
> with a single boolean property `powered` which, instead of being
> represented by a boolean variable, is represented internally by the
> state in which the internal state machine is in (the OnState or
> OffState).
>
> This seems very pure so to speak, but I was thinking, could this be
> extended so that the QObject is given a general `state` QString
> property (since I see you've given the states string names), so that
> you could use property bindings like:
>
>     color: trafficLight.state = "On" ? "green" : "red"

Or rather, I guess it would be a function (e.g.
trafficLight.inState("On")), since the machine is hierarchical and can
be in multiple states, which would check if the state named "On" is in
the current configuration... maybe this idea is starting to smell a
little..

Elvis

>
> ?
>
> Is there something "bad" with an approach like that? I find myself
> thinking that if I'd use an approach like this, there would be a lot
> of boilerplate code to do all posting of events and emitting *Changed
> signals on behalf of the QObject for all the states I want to model,
> when I would rather be focusing on the state machine (it's logic and
> actions) instead.
>
> Hope I'm somewhat clear in what I mean.
>
> Elvis
>
>> Elvis
>>
>>>
>>> Sean, you mentioned back in that thread that you would polish up what
>>> you had written and put it up on the Nokia blog (or the wiki?). Do you
>>> remember if you ever got around to this, and if so, if that material
>>> was lost when Nokia sold Qt? (or if Sean is not here, does anyone else
>>> know?).
>>>
>>> I'm very much interested in real-world examples/stories of using a
>>> state machine-based C++ (or Python) backend for the logic, and QML for
>>> the UI, especially embedded/hardware control use cases.
>>>
>>> Cheers,
>>> Elvis