| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
Updated version of LGPL and FDL licenseheaders.
Apply release phase licenseheaders for all source files.
Reviewed-by: Trust Me
|
| |
|
|
| |
Reviewed-by: Trust Me
|
| |
|
|
| |
Reviewed-by: Trust Me
|
| |
|
|
|
|
| |
"Signal" and "Wrapped" is too generic; prefix with StateMachine.
Reviewed-by: Eskil Abrahamsen Blomfeldt
|
| |
|
|
|
|
|
|
|
| |
Those two classes are specific to the state machine framework, but
their names were so generic that we felt they were polluting the
Q-namespace. They are now QStateMachine::SignalEvent and
QStateMachine::WrappedEvent.
Reviewed-by: Eskil Abrahamsen Blomfeldt
|
| |
|
|
| |
Reviewed-by: Trust Me
|
| |
|
|
| |
Reviewed-by: Trust Me
|
| |
|
|
|
|
| |
eventObject was a horrible name. The documentation already used the
term "event source", so let's call it that.
Agreed with Eskil.
|
| |
|
|
| |
Reviewed-by: Trust Me
|
| |
|
|
|
|
|
| |
The constructors that take a list of target states produce
hard-to-read code, and they're rarely useful in practice since
99% of transitions take a single target state; so it's better
to enforce that setTarget{State,States}() be used instead.
|
| |
|
|
| |
Reviewed-by: Trust Me
|
| |
|
|
| |
Reviewed-by: Thierry Bastian
|
| |
|
|
|
|
| |
When the eventType or eventObject is changed while the state is active,
the transition needs to be unregistered _before_ either property is
changed, only _then_ can it be re-registered.
|
| |
|
|
|
| |
We decided to remove the const of the eventTest() since some transitions
have dynamic conditions and need to update when eventTest() is called.
|
| |
|
|
| |
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.
|
| |
|
|
| |
Result of API review.
|
| |
|
|
| |
Result of API review.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
