| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Reviewed-by: Trust Me
|
| |
|
|
|
| |
Reviewed-by: Trust Me
(cherry picked from commit ac5c099cc3c5b8c7eec7a49fdeb8a21037230350)
|
| |
|
|
|
|
|
|
| |
For introspection purposes. It's nicer than having to qobject_cast
the state's children().
Task-number: QTBUG-7741
Reviewed-by: Eskil Abrahamsen Blomfeldt
|
| |
|
|
| |
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
|
| |
|
|
|
|
|
|
|
| |
Returning the input argument in a function can lead to confusion and
serves no purpose here. Instead, we'll mirror the API from
QMenu::addAction() overloads, where the overload that takes a
preconstructed object has a void return type.
Reviewed-by: Kent Hansen
|
| |
|
|
| |
Reviewed-by: Trust Me
|
| |
|
|
| |
Reviewed-by: Trust Me
|
| |
|
|
| |
Reviewed-by: Trust Me
|
| | |
|
| |
|
|
| |
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.
|
| |
|
|
| |
Result of API review. Don't need them (for now).
|
| |
|
|
| |
Result of API review.
|
| |
|
|
|
|
|
|
|
|
|
| |
Decided in API review. The intention of QHistoryState not being
constructible was so that people wouldn't subclass it and reimplement
onEntry()/onExit(), thinking that those functions would actually get
called (which they won't). However, we recently added the entered()
signal to QAbstractState, so people are going to connect to it and
ask why they never get the signal for a QHistoryState. We might as
well make QHistoryState constructible and just document that it
doesn't make sense to subclass it.
|
| |
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
| |
when it is added. Reduces the number of temporary variables you have to declare
in your code since you can do things like:
state->addTransition(new Transition())->addAnimation(new Animation());
Could also be used for error checking.
|
| |
|
