| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
Result of API review.
|
|
|
|
|
| |
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.
|
| |
|
|
|