Details
-
Suggestion
-
Resolution: Unresolved
-
P2: Important
-
None
-
None
Description
Users suggestion:
"
Hello,
A recent article creates a high level overview of the differences between SCXML and QML/QStateMachine.
https://www.qt.io/blog/state-machines-in-qt-6.2
I would like to add the succession that the state machine editor could somehow be modified or extended to generate QStateMachine c++ code or QML StateMachine code rather than SCXML class derivatives.
By the article's own admission, while QML/QStateMachine classes can give a lot of encapsulation and re-use which is something that is missing from SXCML, but yes, as it grows, it is difficult to visualise as the machine gets larger.
I have recently gone through a number of projects and actually removed the SCXML and replaced it with QML StateMachine - quite simply because it is easier to integrate. I find that the sendEvent("") API and extraordinarily simple boolean state properties are too difficult to reasonably integrate with QML in a nice QML way. I ended up creating an intermediate class to hook everything up for me by subclassing the generated classes. For example, it handled some basic SCXML data property changes and converted them to bindable properties. Likewise, it wrapped the send event boiler plate code into to nicer slots. When I rewrote the whole lot in QML (using SCXML editor drawing as a convenient guide) I could get rid of all that silliness and use QML for its merits. The only obvious step there was - hey, wouldn't it be good to just take the same diagram and generate the QML from it?
Configuration example:
- you could add a flag to encapsulate composite states to separate files if desired
- you could add a flag to add state aliases to the root (similar to how Qt Design Studio exposes inner components to the root of .ui.qml files. This is necessary for example for something like:
Loader {
sourceComponent: SettingsPage { id: settingsPage active: MyStatemachine.settings.active // settings is a child state of the root statemachine (a singleton) nextButton.onClicked: MyStateMachine.next() // a signal defined at the root of the statemachine and handled internally in various transitions }This example is really cool because it maps straight from the loader to the statemachine with almost no effort.
So I suppose I'm wondering that if QML Statemachine is actually based on the fundamentals of SCXML (https://doc.qt.io/qt-6/qml-qtqml-statemachine-statemachine.html#details) then how much of a useful, interactive QML statemachine could actually be generated from an SCXML document and possibly include internal data models perhaps, but all generated out to QML?
As QML will ultimately be generating c++ in the future, this code would perform pretty well going forward.
I realise the suggestion may encounter the argument "just do it in SCXML" but from experience - and I have done it - but I have switched to QML sacrificing the diagram because the code base is just better.
There needs to be a way to define re-usable encapsulated composite states (so that only one QML file is generated and re-used). This is something I've wanted to so in SCXML but have not worked out how to do. Writing the state machine in QML makes this immediately possible and is a very natural thought process to do in the QML mindset.
Thanks for your consideration
"