It's silly to call one virtual function plus one function that
walks the inheritance chain, on every signal transition connect
and disconnect, when the method offset of the internal
QSignalEventGenerator class cannot change.
Change-Id: Ic4e83bdc6ab445ea8ca00f3d8da3031250621e2f
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@nokia.com>
This is much faster than the string-based api.
Change-Id: Id7ba76aee3346dd90412ec5c8505329360aae937
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@nokia.com>
Since Qt's connections are thread-safe, QStateMachine's plumbing
around them should be thread-safe too.
Change-Id: I8ae91c2edc2d32ca4ed4258b71e5da22de30ed91
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@nokia.com>
By default, QStateMachine lazily registers signal transitions (i.e.,
connects to the signal) when the transition's source state is
entered. The connections are established in Qt::AutoConnection mode,
which means that if the sender object lives in a different thread,
the signal processing will be queued.
But if a sender object's signal is used in an out-going transition
of the target state of the queued transition, it's possible that a
second signal emission on the sender object's thread will be
"missed" by the state machine; before the machine gets around to
processing the first queued emission (and registering the
transitions of the new state), a sender object on the other thread
could have emitted a new signal.
The solution employed here is to eagerly register any signal
transition whose sender object is on a different thread; that is,
register it regardless of whether the transition's source state is
active.
Conversely, when a machine's transitions are unregistered (i.e.,
because the machine finished), signal transitions with sender
objects on other threads should be left as-is, in case the machine
will be run again.
This doesn't solve the case where the sender object is moved to a
different thread _after_ the transition has been initialized.
Theoretically, we could catch that by installing an event filter
on every sender object and handle the ThreadChange events, but
that would be very expensive, and likely useless in most cases.
So let's just say that that case isn't supported for now.
Task-number: QTBUG-19789
Change-Id: Ibc87bfbf2ed83217ac61ae9401fe4f179ef26c24
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@nokia.com>
Split the guts of registerTransitions() into a registerTransition()
function. This allows a particular transition to be registered,
instead of walking the source state's whole list of transitions
every time.
Move the logic for determining whether a transition should be
registered to the state machine, since that's also where the actual
registration takes place.
Change-Id: I0496dee9454cd77b62cf2768942a82a96b320744
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@nokia.com>
If the sender object was set, but not the signal signature, the
registration would proceed anyway, producing a strange warning like
QSignalTransition: no such signal: MyObject::
Change-Id: If0b113bdb60dd770d60b0d38d509b673e9d8c5eb
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@nokia.com>
The originalSignalIndex member was not set if the signature had to be
normalized. This caused the SignalEvent passed to onTransition() to
report a signal index of -1.
Improve the signal transition tests so they check both the event
passed to eventTest() and onTransition().
Change-Id: I5331fd1944d53310b6d11eb2fd8713b80faa53a1
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@nokia.com>
The SCXML spec had a bug that would cause the initial state of a
compound state within a parallel state group to be entered even if
the transition specified another (non-initial) state of the compound
state as its target. This only happened if the transition had
multiple target states.
The bug has been fixed in recent revisions of the SCXML spec. This
commit implements the fix, which is to walk the ancestors of the
transition's target states only after all the target states
themselves have been added, so that the default initial states are
correctly overridden/ignored.
Task-number: QTBUG-25958
Change-Id: Iac532047678c483a4a3996e24dacf30e00f6bbe0
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@nokia.com>
The lca variable doesn't change inside the loop. Comparing our
implementation to the algorithm in the SCXML spec reveals that this
check should indeed be done outside the loop.
Change-Id: I5e9824758fd147766e975d107a73561bd7f5a190
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@nokia.com>
QStateMachine inherits from QState, so it should be possible to set
its childMode to ParallelStates, and it should behave as expected
(the machine should emit the finished() signal when all its child
states are in final states).
Task-number: QTBUG-22931
Change-Id: Ic436351be0be69e3b01ae9984561132cd9839fa7
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@nokia.com>
It's legal to set a QFinalState as the initial state. The state
machine should correctly emit the finished() signal upon entering
such a state in the initial transition, and don't do any further
processing.
Change-Id: Ica8d3fadbbde604512ea1136624af54eb3b13b11
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@nokia.com>
In preparation of supporting parallel root states, which will make
the initial transition creation slightly more involved.
Change-Id: Iad996eb4db248842c1a2088430c13bd5c953c374
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@nokia.com>
The hidden start state was used as a mechanism for performing the
initial transition (to the real initial state,
QStateMachine::setInitialState()), but it mutated the state machine
in a way that causes problems when the root state is a parallel
state group (see future commit).
Change-Id: I41ac4f6bcabf3bec0a412e46282a1373928105a3
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@nokia.com>
In the old implementation, property assignments
(QState::assignProperty()) were "second-class citizens".
Assignments were not really integrated into the state machine
algorithm, but rather done as a separate step
(QStateMachinePrivate::applyProperties()). While that was
convenient for SCXML spec transcription purposes, it resulted
in some pretty poor semantics on the user side:
* Properties were not assigned until _after_ both the
QAbstractState::onEntry() function had been called and the
QState::entered() signal had been emitted.
* Automatic property restoration (QStateMachine::RestoreProperties)
did not play nice with nested states (and parallel states, in
particular).
The proper fix is to refactor the implementation to make
property assignments first-class in the core state machine
algorithm (QStateMachinePrivate::microstep()).
In practice, this meant splitting some steps. Instead of calling
exitStates() straight away, we now first only compute the states
to exit (without actually exiting them), and use the resulting set
to compute which properties are candidates for restoration.
Similarly, instead of calling enterStates(), we first only compute
the states to enter (without actually entering them), and use the
resulting set to compute which properties are assigned by the
entered states.
With that in place, the rest was a matter of moving the various
chunks of the old applyProperties() logic to the place where they
belong in the per-state entry/exit.
All existing autotests pass. Added several tests that verify the
desired semantics in more detail.
Task-number: QTBUG-20362
Change-Id: I7d8c7253b66cae87bb0d09aa504303218e230c65
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@nokia.com>
Move the computation of the sets of entered/exited states to
separate functions.
This separation is done in order to facilitate the integration
of property assignments (QState::assignProperty()) into the
core state machine algorithm.
Change-Id: I5b7084e0e37037eb64909d217856746d81bf1878
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@nokia.com>
If the transition has no target states, that means the current state
won't change; hence, property assignments should not be performed.
In particular, properties should not be restored to the values they
had before the state was entered.
Change-Id: I237bbb541f939c272777e70c5f26c886ec457a17
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@nokia.com>
QStateMachinePrivate::applyProperties() is an epically long function.
Move the code for selecting animations to a separate function, in
preparation of a larger refactoring.
Change-Id: Ic5846db97dd0cb0d6ad01740f413b233d2a66975
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@nokia.com>
Previously, a registered restorable property would only be
unregistered if the property was animated (see
QStateMachinePrivate::_q_animationFinished()).
But if a property is set directly, it should also be unregistered;
otherwise, the state machine would use the previously saved (stale)
value the next time that property should be restored.
Change-Id: I5d246aa5355ddd0ba5f81b0186a9f0e4f3bbaa3f
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@nokia.com>
This allows QPropertyAssignment to be smarter (caching the
property index, for example).
Change-Id: Ib6d302f46f784219b6b3f07784e5c31dd7288c6e
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@nokia.com>
Do like QPropertyAnimation and store the QObject in a QPointer.
Purge the assignments list upon state entry and property restore.
Change-Id: I54a56885a2905178ab6aa5cf292b3d25c86b7a97
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@nokia.com>
goToState() is an internal function. Allowing both goToState() and
machine.setInitialState() to be used to set the initial state of the
machine complicates the logic of QStateMachine::start().
The existing tests for goToState() still pass.
Change-Id: Ie831b4c869848f7f4c3e6bd576cf298a9799eb22
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@nokia.com>
postDelayedEvent() and cancelDelayedEvent() are marked as thread-safe
in the documentation. Unfortunately, they didn't actually work when
called from another thread; they just produced some warnings:
QObject::startTimer: timers cannot be started from another thread
QObject::killTimer: timers cannot be stopped from another thread
As the warnings indicate, the issue was that postDelayedEvent()
(cancelDelayedEvent()) unconditionally called QObject::startTimer()
(stopTimer()), i.e. without considering which thread the function
was called from.
If the function is called from a different thread, the actual
starting/stopping of the associated timer is now done from the
correct thread, by asynchronously calling a private slot on the
state machine.
This also means that the raw timer id can no longer be used as the
id of the delayed event, since a valid event id must be returned
before the timer has started. The state machine now manages those
ids itself (using a QFreeList, just like startTimer() and
killTimer() do), and also keeps a mapping from timer id to event
id once the timer has been started. This is inherently more complex
than before, but at least the API should work as advertised/intended
now.
Task-number: QTBUG-17975
Change-Id: I3a866d01dca23174c8841112af50b87141df0943
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@nokia.com>
The documentation says that started() "is emitted when the state
machine has entered its initial state", but the implementation
didn't adhere to that.
The consequence is that if you e.g. emitted a signal from a slot
connected to started(), and that signal was used by a transition
from the initial state, the signal would effectively get ignored and
the state machine would remain in the initial state.
Task-number: QTBUG-24307
Change-Id: Ibbeb627d517eaff821d88e256a949eacf6aae350
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@nokia.com>
A QObject can't be a child of itself, so the comparison always
returned false. In practice, this was causing the entry/exit order
of parallel states to be random.
QObject::children() is documented to contain the children in the
order in which they were added, so this fix actually achieves
deterministic behavior.
Task-number: QTBUG-25959
Change-Id: Id3f12d6bfbc249f1d4fed0bafb7d0217093e458e
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@nokia.com>
The desired method is already stored in a local variable.
Change-Id: Ibf0078813c7aebc83604b9c7ad9a8b6c596c5c65
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Move runningTimers, eventFilters and objectName data members to
ExtraData. Saves 12 bytes per QObject for 95% of use cases
(QObjectPrivate goes from 76B -> 64B).
Change-Id: I5648c89f65a7be3ea51bd703ee8a9dcff6222c3c
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Reviewed-by: Roberto Raggi <roberto.raggi@nokia.com>
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
QMetaObjectExtraData was added when support for QMetaObject::newInstance
was added. One needed a place to put the pointer to static_metacall in
the QMetaObject.
But as we break binary compatibility, one can change the size of
QMetaObject, and put everything back inside QMetaObject's own structure.
Meaning it is not required anymore to have one QMetaObjectExtraData
instance per QMetaObject anymore.
Change-Id: If0b8f586cbaf633eed10045adee3ba3366826c86
Reviewed-by: Bradley T. Hughes <bradley.hughes@nokia.com>
Reviewed-by: Kent Hansen <kent.hansen@nokia.com>
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@nokia.com>
This change fixes most qdoc errors in QtCore. There are about 900 left.
The main thing this change does is moving documentation from qtcore from
/doc/src to /src/corelib/doc.
Other issues resolved are mis-use of qdoc commands.
Change-Id: I002d01edfb13575e8bf27ce91596a577a92562d1
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
Reviewed-by: Jason McDonald <jason.mcdonald@nokia.com>
Reviewed-by: Jerome Pasion <jerome.pasion@nokia.com>
This enables easier updating of those structs, by reducing the amount of
code that needs to be fixed. The common (and known) use cases are
covered by the two macros being introduced in each case.
Change-Id: I44981ca9b9b034f99238a11797b30bb85471cfb7
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Regenerate the moc output so that it's in sync with the latest moc.
Change-Id: Ic347f7cd030248da431070bf3307950df30edd66
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@nokia.com>
In Qt5 the meta-data format will be changed to not store the
method signature string explicitly; the signature will be
reconstructed on demand from the method name and parameter type
information.
The QMetaMethod::signature() method returns a const char pointer.
Changing the return type to QByteArray can lead to silent bugs due to
the implicit conversion to char *. Even though it's a source-
incompatible change, it's therefore better to introduce a new
function, methodSignature(), and remove the old signature().
Task-number: QTBUG-24154
Change-Id: Ib3579dedd27a3c7c8914d5f1b231947be2cf4027
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: João Abecasis <joao.abecasis@nokia.com>
We want to drop support for old revisions in Qt 5.
This commit brings the QSignalEventGenerator meta-object in sync with
current moc output.
Change-Id: Id5f4954b08cf49169850bd77543b2a7ab8274c18
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
As in the past, to avoid rewriting various autotests that contain
line-number information, an extra blank line has been inserted at the
end of the license text to ensure that this commit does not change the
total number of lines in the license header.
Change-Id: I311e001373776812699d6efc045b5f742890c689
Reviewed-by: Rohan McGovern <rohan.mcgovern@nokia.com>
This is the beginning of revision history for this module. If you
want to look at revision history older than this, please refer to the
Qt Git wiki for how to use Git history grafting. At the time of
writing, this wiki is located here:
http://qt.gitorious.org/qt/pages/GitIntroductionWithQt
If you have already performed the grafting and you don't see any
history beyond this commit, try running "git log" with the "--follow"
argument.
Branched from the monolithic repo, Qt master branch, at commit
896db169ea224deb96c59ce8af800d019de63f12
Kent Hansen
Martin Jones
Olivier Goffart
Casper van Donderen
João Abecasis
Teemu Katajisto
Jason McDonald
Jyri Tahtela
Qt by Nokia