Pierre Lamot requested to merge qml/dsm-ci into master Oct 28, 2021

Hello,

This proposal is for the inclusion of the QtQml.MachineState to manage the state of items that have a

Note that this MR is not complete, it won't compile for windows or snap as-is

I tried to refactor some component that I found were good candidate

volume widget: edit and reactive state
player.qml: lots of state and interaction (audio, pined controls, control autohiding) + the playlist visiblity

pros:

better decoupling of behavior and presentation
States machines are usually easier
this avoid weird code structure such as (from the volume widget):
```
volControl._inhibitPlayerVolumeUpdate = true
volControl.value = _player.volume
volControl._inhibitPlayerVolumeUpdate = false
```
with the FSM, the controler value and the player volume can only be updated when in the right state
good extensibility, adding a new state or a substate is a matter of adding the entry and connecting the signals

cons:

This use the package QtQml.MachineState, so this adds yet another Qml dependency. This is a part of QtDeclarative, already in the contribs, so it's not really that exotic. This shouldn't be an issue for windows and snap version, but linux folks probably need to install it.
This tend to be a bit verbose, but the code is usually simple.
YAGNI: well, it already works without this.

FAQ:

Don't QML already provides states and transition?

QML states are a good tool to represent the visual properties and how they shoud animate between the states

It does not provide

I know its possible to translate hierarchical FSM to a flat one, though this often leads to a combinatory explosion of the number of states.
Do we need the QtQml.StateMachine package:

Qt provides different tool to work with state machines:
- We can achieve the same using , integration with Qml should be made manually on top of it.
- SCXML to C++ code conversion tool, the advantage is that this use a standard format that can be visually edited (or at least represented) using various tools. but this seems a bit overkill and would complexify the build process (more over it not available in meson yet), plus you have the same drawbacks as with the native C++ implementation
- QtQml.StateMachine, provides the "best" integration within QML.
- QQuickItem state & transitions: see previous question
should we use state machine for everything:

Hell no! QML property binding does a very good job at exposing orthogonal states. This is good tool for representing complex state, probably overkill and over-verbose for simple state.

Further documentation