| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
|
|
|
|
|
|
| |
The state machine algorithm frequently needs to know what type a state
is, e.g. if it is atomic, final or a history state. We were using
qobject_cast() to determine this, but that function is expensive.
This commit introduces an internal StateType to be able to differentiate
between the different types of state. This vastly improves performance.
Reviewed-by: Eskil Abrahamsen Blomfeldt
|
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
| |
Reviewed-by: Thierry Bastian
|
| |
|
|
|
|
|
|
|
|
|
| |
Accessing the event can be useful. E.g., onEntry() can do some
common event processing regardless of which transition caused the
state to be entered; onTransition() can be used in combination
with eventTest(), where eventTest() would first check that the
input matches some criteria, and then the actual processing of that
input would be done in onTransition.
|
|
|
|
|
| |
Not worth it having two public classes when the same can be achieved
by having a signal.
|
|
|
|
|
|
|
|
|
|
|
|
| |
It just didn't give us that much.
Typically you just reimplement onEntry/onExit/onTransition
when you want to do something.
We go back to the signals-and-slots approach: states have
entered() and exited() signals that you can connect to.
It's still possible to have an action-based API, but then
you build it on top of the core API, which is OK.
Replacing 4 public classes (and one layer in the hierarchy)
with 2 signals feels good.
|
| |
|
|
|