[Qt-interest] Qt State machine framework

[K. Frank]

Hello Mandeep -

You may be trying to do something that doesn't best fit the
state-machine approach.

On Wed, Mar 24, 2010 at 5:21 AM, Mandeep Sandhu
<mandeepsandhu.chd at gmail.com> wrote:
> On Fri, Mar 12, 2010 at 11:03 AM,  <noam.rosenthal at nokia.com> wrote:
>> Hi Mandeep
>> Actually both things are supported!
>>
>> 1. http://doc.trolltech.com/4.6/qabstracttransition.html#triggered: A signal that gets emitted when a transition is triggered. You can then query the tranistion's source/target properties.
>
> Actually this approach has a problem if transitioning to/from a super
> state or a history state. I'm actually interested in emitting
> transition info for lowest level child states.

Could you tell us a little about the concrete problem you are tying to solve?
Maybe there's a better way to map it into the state-machine framework, or
maybe a non-state-machine approach would be better.

> So eg if I return to a history state, my signal should tell which
> child state was entered and what was the source state. If the source
> state had children, then i need info about which child state was left.
>
> I can think of recording states on my own (using the onEntry/onExit
> fxns). Is there any other way?

I'm not knowledgeable about the Qt state-machine framework.  Perhaps
No'am could give you an informed answer.

> Thanks,
> -mandeep

I generally don't like answer the question "How do I do X?" with "You
don't really
want to do X."  (Especially on lists like this.)  It obviously doesn't
answer the
question, and it's kind of a cop-out.

But it does seem like you're trying to do something that doesn't fit perfectly
the state-machine philosophy.

In a very coarse, high-level sense, just as object-oriented programming is
about decoupling, encapsulation, and information hiding, state-machine
programming is to.

A core idea in state machines is that whether you transition from state
A to C or from state B to C, once you're in state C, you don't care where
you were before.

A core idea in hierarchical state machines (HSM's) is that from the outside
of a substate (or the history pseudo-state), you don't care about the internal
details of the substate (or about the actual state to which the history state
returns).

Following these principles is part of how you get decoupling and information
hiding.  (Of course, with real problems you can't always follow such principles
blindly.  I often find myself changing "private" to "public" in c++ classes.)

It seems that the way you're approaching your problem is pressuring you
to violate some of the state-machine principles.  Now in the real
world, sometimes
this is the best thing to do.  But if you would like to let us know a
little more
about the practical problem you're trying to solve, perhaps we might have some
ideas about how to better map your problem into the state-machine framework
or be able to suggest a different programming paradigm that would be a better
fit for your problem.

Good luck.


K. Frank


>> 2. http://doc.trolltech.com/4.6/qstatemachine.html#configuration: QStateMachine::configuration(), returns a set of current states.
>>
>> Hope this answers your question,
>>
>> Regards
>> No'am
>> ...