By writing a small demo to complete my post, I found the issue. As it might be helpful to somebody else, here it is:

demo.scxml:

<?xml version="1.0" encoding="UTF-8"?> <scxml xmlns="http://www.w3.org/2005/07/scxml" version="1.0" binding="early" xmlns:qt="http://www.qt.io/2015/02/scxml-ext" name="plop.scxml" qt:editorversion="4.7.1"> <state id="State_1"> <qt:editorinfo scenegeometry="144.50;162.05;84.50;112.05;120;100" geometry="144.50;162.05;-60;-50;120;100"/> </state> </scxml>

demo.py:

#!/usr/bin/env python import sys from PySide2.QtCore import QObject, QCoreApplication, SLOT, Slot from PySide2.QtScxml import QScxmlStateMachine class Backend_1(QObject): def __init__(self, machine): super(Backend_1, self).__init__() self.machine = machine self.machine.connectToState("State_1", self, SLOT("s1_active(bool)")) @Slot(bool) def s1_active(self, active): if active: print('Backend_1::State_1: enter') self.submachine = QScxmlStateMachine.fromFile('demo.scxml') b = Backend_2(self.submachine) self.submachine.start() else: print('Backend_1::State_1: exit') class Backend_2(QObject): def __init__(self, machine): super(Backend_2, self).__init__() self.machine = machine self.machine.connectToState("State_1", self, SLOT("s1_active(bool)")) @Slot(bool) def s1_active(self, active): if active: print('Backend_2::State_1: enter') else: print('Backend_2::State_1: exit') if __name__ == '__main__': app = QCoreApplication(sys.argv) machine = QScxmlStateMachine.fromFile('demo.scxml') b = Backend_1(machine) machine.start() sys.exit(app.exec_())

If you run this, you expect to see:
Backend_1::State_1: enter
Backend_2::State_1: enter

But, the second statemachine does not seem to start. To fix it, you need to store the instance of Backend_2 (eg: self.b = Backend_2(self.submachine)). I guess it was garbage collected, so all the states/events connections were broken.

Meanwhile, if you think my design patter is bad, I'm willing to learn :)

Have a look at the State Machine Framework documentation here.

Basically make one state with your defined transition, and create your other states accordingly with the parent state that has your single transition defined.

Good luck.

If you want to connect for particular signal, first define the function in QML and use Connections object or <id>.signalName.connect(..) to connect with particular handler.

Think of 'entering' a state as crossing the boundary between the outside into the box that corresponds to the new state. Or even more concrete, think of a state 'InsideTheHouse', and entering that state as going through some door. You need to enter before you are actually in the new state, just as you have to pass the door, in order to get to the actual state of 'InsideTheHouse'.

This is a quite general pattern used by any state machine implementation I ever came across. I'm not entirely sure though whether the default texts about software patterns explain this very clearly though, as it really is more of an implementation detail than a generic pattern.

Hi,

The only good answer is: benchmark.

In any case, Qt's State Machine Framework is not know to be slow so unless you're expecting speed of light it should run well enough.

Yes that is correct. Every of the 8 custom gestures defines its own set of data in addition to the QGestureState, which is set by the according gesture recognizer.

I now implemented an abstract superclass for all these gestures with a method getGestureData(). This method basically wraps all the data in a QMap<QString,QVariant> to make a general gesture treatment possible. The custom event GestureEvent now takes gesture type, the Qt::GestureState and the mentioned gesture data map.
It was a little bit circumstantial, but now it works.

Thanks again,
Malte

Then you should either check the code where they do that and integrated it to your project or add the image saving feature to GammaRay