We currently have multiple state machine frameworks in Qt: QStateMachine in QtCore, then built on this the QML state machine framework, and finally the totally unrelated Qt SCXML module. Each of them has some features missing from the other. This state of affairs is rather confusing and frustrating to users, as has been expressed in many conversations I had.

In particular, QStateMachine and QML state machine provide:

• Programmatic construction of the state machine from C++ and QML
• Introspection: You can query the state machine for states and transitions

Qt SCXML on the other hand provides:

• Better performance, mainly because states are not QObjects and therefore the initialization is much faster
• Construction from an SCXML document

Because of the performance required from Qt SCXML and because of slight mismatches between the SCXML specification and the semantics of QStateMachine we cannot build Qt SCXML on QStateMachine.

But what about the other way around? We could certainly offer an API for programmatic construction of QScxmlStateMachine objects, and introspection would not be too complicated, either. We could mimic the original QStateMachine and QML state machine APIs, and eventually deprecate them. This would allow us to clear out the state machine mess in Qt 6.

In fact we already have some limited introspection capabilities in QtScxml. They are exposed as private API, for GammaRay.