[Qt-interest] QStateMachine API and design?

[Stephen Kelly]

K. Frank wrote:

> Hi Steve -
> 
> I would make a couple of philosophical comments:

Thanks. This is useful too. I'm unsure though if this is mostly a 
philosophical approach or if it comes from experience of trying to meld 
QStateMachine with QML?
 
> Similarly, in the state-machine paradigm, you don't really care what state
> you're in.

I think in this interacting-with-QML case, you do care, because the state 
you are in is part of how QML is used. Even if QStateMachine doesn't make it 
easy, to declare which state you are in or should be in, QML does, so 
interacting with QML in a similar way makes for an interesting way to 
implement serious-business applications in QML.

> 
>> My usecase is to create a state machine and expose it to QML so that I
>> can change the ui state on change of the application state.
>> Approximately: ...
> 
>>From the purist's perspective, the purpose of a state machine is not
>>merely
> to store state that some external entity monitors and responds to, but
> rather to manage the code that is executed in response to incoming events.
> 
> So you might consider elevating your state machine to a loftier role,
> and let it directly manage the dynamics of your program, rather than
> restricting it storing and updating the value of a state variable.
> 
> So suppose you have a state machine, "machine," and a button-widget,
> "widget."
> 
> Plan A:
> 
> machine::state1::onEntry() {
>   widget.notifyStateChanged();
> }
> 
> widget::onNotifyStateChanged() {
>   stateValue = machine.getState();
>   if (if stateValue == state1) {  // <-- if-then code...
>     setButtonColor (red);
>   }
>   else if (stateValue == state2) ...
>   else ...
> }
> 
> Instead you can replace plan A with
> 
> PlanB:
> 
> machine::state1::onEntry() {
>   widget.setButtonColor (red);
> }
> 
> I think of state machines as objects with dynamics, in a sense as
> control structures, rather than value objects, i.e. objects that store
> the value of a state variable.  Taking this to its logical conclusion,
> state machines should be elevated to a more central, controlling
> role.
> 
> And if they are, there is no need for them to offer query-state
> functionality, nor state-changed notifications.

What I currently have is something like this in your pseudo code:

application_state_machine::errorstate::onEntry() {
  ui_state_machine.setState(errorstate);
}

...

ui_state_machine::errorstate::onEntry() {
  errorScreen.setVisible(true);
}

So the ui state is dependent on the application state in some way. 

All the best,

Steve.

> 
>> All the best,
>>
>> Steve.
> 
> Good luck.
> 
> 
> K. Frank