| 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
|
| |
|
|
|
|
|
|
|
| |
"Polished" was never a very descriptive word, and it already has a
meaning attached in the QStyle API. Additionally, "propertiesAssigned"
has the benefit of giving the relation to the assignProperty() function
as part of the name.
Reviewed-by: Kent Hansen
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This is the same type of optimization as that done for transitions in
commit 5d8dcd57cd13fdd9c8643fa3bdda9f197a4351ff. The idea is to avoid
calling qobject_cast() because it's very expensive.
Obtaining child states needs to be as fast as possible because it's in
the critical path of the state machine algorithm; it's called by a ton
of internal functions, like isCompound(), isAtomic(), isInFinalState().
It's also called heavily for parallel state groups.
Reviewed-by: Eskil Abrahamsen Blomfeldt
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Transitions are children of their source state. We use
QObject::children() and qobject_cast() each child to a
QAbstractTransition to see if it is indeed a transition. However,
calling qobject_cast() is very expensive. This commit introduces
a cached list of transitions. The list is invalidated after a
child object has been added or removed.
In the typical case we expect the object hierarchy to remain fairly
constant once the state machine has been started (states, child states
and transitions are usually "static"), in other words the cached list
is not likely to be invalidated much.
Obtaining a state's transitions needs to be as fast as possible
because it's in the critical path of the state machine algorithm.
Reviewed-by: Eskil Abrahamsen Blomfeldt
|
| |
|
|
| |
Reviewed-by: Trust Me
|
| |
|
|
| |
Reviewed-by: Trust Me
|
| |
|
|
| |
Reviewed-by: Trust Me
|
| | |
|
| |
|
|
| |
Reviewed-by: Trust Me
|
| | |
|
| | |
|
| |
|
|
| |
...hopefully
|
| | |
|
| |
|
|
| |
Result of API review.
|
| |
|
|
| |
Doesn't belong in the abstract base class.
|
| |
|
|
|
| |
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.
|
| |
|
