| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
| |
The state machine decides when these signals are emitted.
|
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
| |
Reviewed-by: Thierry Bastian
|
|
|
|
| |
We won't release another Qt Solution, so the define is no longer needed.
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
It's useful and it's simple for us to expose, so let's.
|
|
|
|
| |
Doesn't belong in the abstract base class.
|
|
|
|
|
|
| |
use case for this, so it has been removed. If the requirement arises we can
add it back in later. Since it no longer makes sense to have it in
QAbstractState, the RestorePolicy enum has been moved to QStateMachine.
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|