After some excellent feedback on Kent and Eskil’s state machine framework, and on the old-time Qt-SCXML project, we now present the updated version, with the latest and greatest of both. Qt State Machine Framework Solution 1.1 now includes not only carefully designed API adjustments and bug fixes to the main state/transition classes, but it now also includes the Qt-SCXML functionality, loaded into the Qt State Machine Framework with the QtScriptedStateMachine class.
What does the SCXML part add?
With both SCXML and the State Machine C++ API, you can choose whether your design calls for Qt/C++ style initialization of the state machine, or for loading external SCXML files that access Qt through scripting. The SCXML part also contains a few additions that are not implemented in the C++ API, such as anchors, and the ability to use scripted conditions to guard transitions (even without loading a whole SCXML file, with the QtScriptedTransition class).
Even with the aforementioned features, the SCXML support is a pretty thin layer on top of the C++ State Machine API, as it is basically some standard QXmlStreamReader code for parsing the SCXML file, QtScript for ecmascript transitions and actions, and a couple of additional goodies like menu/message-box and anchors.
Note that there might be a few minor discrepancies between the SCXML spec and what’s supported in the implementation. That’s due to the fact that the SCXML specification itself is still evolving. We’re also participating in the group that makes that happen.
A feature that didn’t make it to the release
During the development of this solution, we made an attempt at creating a compiler similar to uic (the QtDesigner form compiler), that would generate C++ Qt State Machine code from the SCXML files, and thus reduce the load time of the state machine. We solicit feedback as to whether such feature is needed.
Note to users of the original Qt-SCXML project
Some of the original features of Qt-SCXML have been enhanced, removed or modified in this spec. For example, instead of using the custom <Qt:property /> tag, we enable an invoke tag <invoke type=”q-bindings” /> that does virtually the same thing. See the ported examples and you’ll get the picture 
Also, Qt-SCXML now supports only QtScript, and not the “native” sort-of-expression-syntax it supported before as an alternative. If you’re interested in using Qt state-machines without using QtScript at all, We hope that the C++ API is an adequate answer.
If a removed feature from the old Qt-SCXML is extremely close to your heart, please speak your mind!
Feedback Please
Any bug, question, suggestion or interesting use you have: qt-solutions@trolltech.com or here.
Link to the solution: http://www.qtsoftware.com/products/appdev/add-on-products/catalog/4/Utilities/qt-state-machine-framework/
Enjoy
No related posts.
10 comments
> and thus reduce the load time of the state machine.
Where is the time spent? If it is parsing the XML and Qt ends up handling large XML files in a lot of places I wonder if it adding support for a binary XML format would help.
Awesome!!!
The state machine framework and SCXML combined are perfect for my current distributed multimodal HMI project!!!
Thanx a lot!!!
Nik
@Robert: Yes, it’s about XML parsing. Binary XML would probably be somewhere in the middle between standard XML parsing and compile-time code generation. I’m interested to know if XML loading time is an actual problem for anybody in the SCXML case.
Can’t speak for the SCXML case, but I was running a test script recently where the XML parser was being overworked and it was taking 90% of my CPU cycles just to parse the XML looking for each expected answer… I turned the test around and generated the answers in the order they appear in the XML “expected answers” table and now it’s fine (like less than 2%, I think), but for large repetitively parsed XML tables, the parser can be a huge timesink.
I would hope the SCXML reading code is reasonably efficient in only reading through the definition file a time or two, and doesn’t have any n-squared complexity cases like my test code used to.
re: compiler for SCXML files to C++: yes please; this is the only way I would use this functionality.
@RazrWire: The parsing code only goes through the XML file once, nothing n-squared etc.
@timdewhirst: Thanks for the feedback. can you elaborate a bit about why C++ code generation would work better for you than runtime XML parsing?
The most obvious reason is to avoid shipping XML files with the application.
@Adam: There’s no need to ship XML files with the application. You can compile the XML file into the binary using the Qt resource system – That’s how we do it in the examples.
@No’am: re: SCXML compiler: reasons for preferring c++: no XML to parse at runtime, no QtScript, compile time type checking. This is possibly over cautious however I’ve worked with Mozilla extensively in the past and was scarred by the experience
.
@timedwhirst: Thanks for the elaboration. I’ll see if a compiler can be included in the next version, maybe with scripts in the state-machine being optional.
Comments on this entry are closed.