Questions about QStateMachine
-
Hi,
I have read about QStateMachine in Qt docs and would like to try it out. However, the introduction is rather rudimental and I am missing some do's and don'ts.
I have drawn a little picture:Transition from S2 to S21, S22, S23 and S25 shall work by pressing a button.
Further buttons transitions go from S2 to S241, S242, ... S245.
S24 is only (a virtual group) to change menu entries, or toolbar buttons in the status.Same is true for status change from S23. From S23 a button press should lead to S2311, S2312, S2313, S2314 or the start of S232.
A button press with target of S241-S245 terminates S231 or S232 (where 232 can be exited first at process end). Ending S241-S245 should lead to S2 or S23 (depending on the active state before entering S241...). Guess I could solve that with QHistoryState.
According to the introduction of QStateMachine, no child state can be addressed directly from the parent state.
So, how else can I do addressing and grouping of target states like drawn in the picture?
-
Hi,
Are you using only buttons to go from one state to another ?
-
Hi and thank you for your attention.
From users point of view each state change is based on button press. From developers point of view - only few state changes are really button actions. Standard workflow is: user presses button, button sends message to backend, backend sends response, response triggers state change.
The problem is, that a single state change could cause lots of UI-elements change visual state and content (i.e. about 10 buttons at once). Actually I solved that by custom action class that listens on property change events.
But current implementation is far from reliable. One problem is probably that I don't really understand plugins behaviour.... so my hope was, that statemachine could help me improve reliability. But actually I don't know, how to solve complexity of requirements.
-
What do you mean by plugin behaviour ?
-
Hm, actually I wanted to learn more about Qt's Statemachine. From your distraction, I gather that Qt's implementation of a statemachine is unsuitable for my purposes. Seems like hierarchical statemachines are not supported.
I guess I'll have to implement my own.Very well - so to the plugins. At first I had lots of crashes with the plugins, until I learned here that plugins probably run in their own address space. I then changed my code and since then the plugins work. Unfortunately, however, only limited.
The event processing works only sometimes and I have no idea why.
Even if I generate GUI elements of the plugins from the MainWindow, they don't work reliably. Therefore I want to change my code again. -
Can you give a bit more informations about your application structure ?
I wouldn't think that mixing the use of plugins and state machine would be problematic.
AFAIK, Qt's QStateMachine should be hierarchical. QStateMachine is itself a QState.
-
@SGaist said in Questions about QStateMachine:
I wouldn't think that mixing the use of plugins and state machine would be problematic.
I don't have a statemachine in use yet.
The problems I have with the plugins stem from the fact that each plugin is loaded into its own address space.
I was able to get rid of some issues, but I know far too little about the side effects of Qts architecture. I only see the effects in the application and that bugs me a lot.The plugins are individual pages of the application, or parts of a page, which are loaded dynamically (they are independent projects, so everyone can decide which plugins are loaded). Some of these plugins have toolbar buttons and they don't work properly in interaction with the application. As mentioned before, I had rearranged the code so that the toolbar buttons of the plugins are generated from the main application. I think the problem is that PropertyChangeEvents are not being processed properly.
Unfortunately, I lack the knowledge, or the tools, to track down the root cause of the problem.I thought, I had finished development of the application, but in many corners it does not work reliably, so I decided to start redesign. I hope, that statemachine will bring the desired improvements.
So much for the theory ...@SGaist said in Questions about QStateMachine:
AFAIK, Qt's QStateMachine should be hierarchical. QStateMachine is itself a QState.
Is no longer important. I asked for information about Statemachine, because I didn't want to reinvent the wheel. But since I couldn't solve my ideas with the Qt classes, I wrote my own Statemachine. It already works very well and so I can start to redesign application.
I don't know yet how I will solve the problems with plugins, but maybe I will think of something. -
Are you using Qt's plugin classes to work with your application ?
-
Sure!
If you're curious, you can recreate the prototype's behavior with Qt.
by the way ...
the app with plugin issues is Falconview
