After selecting all (enabled) transitions for a microstep, filter out
any conflicting transition. The actual conflict resulution is done by
ordering the transitions in order of the states that selected them.
For example: if an event would trigger two transitions in a parallel
state where one would exit that state and the other would not, this
filtering prevents the state machine from selecting both states (as this
case is an invalid state of the whole machine).
This also fixes the exit set calculation for parallel states when one of
its substates is exited and subsequently re-entered in the same
transition. Previously, the parallel state was not exited, and
subsequent re-entry was ignored (because it was still active). Now it is
correctly exited and re-entered.
A side-effect of the transition ordering mentioned above is it also
fixes the non-deterministic behavior of which of the conflicting
transitions is taken.
[ChangeLog][QtCore] Fixed an issue where the state machine could end up
in an invalid state when transitions from a parallel state were not
checked for conflicts.
[ChangeLog][QtCore] Fixed a case where a parallel state was not exited
and re-entered when one of its substates was exited and subsequently
re-entered.
[ChangeLog][QtCore] Fixed the non-deterministic behavior of picking a
transition from a set of conflicting transitions.
Task-number: QTBUG-44783
Change-Id: I2ee72b6a2f552077bfa7aa4d369474ab62f4c2f0
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@theqtcompany.com>
Reviewed-by: Kevin Funk <kevin.funk@kdab.com>
When a history state is entered that has an actual saved history (so not
the initial state), the entry set was calculated wrongly in some cases.
See the bug report for the specific case.
The fix is to fully implement the standard, so method names in the
private class are updated to reflect the names as used in the standard.
Note that, as mentioned in the bug report, the algorithm as described in
http://www.w3.org/TR/2014/WD-scxml-20140529/ has a bug. What is
implemented is the fixed algorithm as described in the current working
draft as of Friday March 13, 2015. This draft can be found at:
http://www.w3.org/Voice/2013/scxml-irp/SCXML.htm
[ChangeLog][QtCore] Fixed an issue where a history state restore would
activate too many states, possibly putting the state machine in an
invalid state.
Change-Id: Ibb5491b2fdcf3a167c223fa8c9c4aad302dbb795
Task-number: QTBUG-44963
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@theqtcompany.com>
- removed an unused field
- initialized variable that might be used uninitialized.
Change-Id: I7a7a063f025ecc32fa462dd8d5e2485c2ba52eb8
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@theqtcompany.com>
Qt copyrights are now in The Qt Company, so we could update the source
code headers accordingly. In the same go we should also fix the links to
point to qt.io.
Outdated header.LGPL removed (use header.LGPL21 instead)
Old header.LGPL3 renamed to header.LGPL3-COMM to match actual licensing
combination. New header.LGPL-COMM taken in the use file which were
using old header.LGPL3 (src/plugins/platforms/android/extract.cpp)
Added new header.LGPL3 containing Commercial + LGPLv3 + GPLv2 license
combination
Change-Id: I6f49b819a8a20cc4f88b794a8f6726d975e8ffbe
Reviewed-by: Matti Paaso <matti.paaso@theqtcompany.com>
Added the function pointer to addTransition to take
advantage of the new connect syntax.
[ChangeLog][QtCore][State Machine] Added an addTransition() overload that
takes a pointer-to-member for the signal triggering the transition.
Change-Id: Ic97f7983839217ca0c8484b269d38221cbe804e3
Task-number: QTBUG-40293
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Benign, but easy to avoid by allocating objects on the stack.
Change-Id: I1933d0abb2ebd53bcf0402f392e7e3c201756b9e
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Manually included changes from
3a347a4e70
in src/opengl/qgl.cpp.
Conflicts:
src/opengl/qgl_qpa.cpp
src/plugins/platforms/android/androidjnimain.cpp
Change-Id: Ic26b58ee587d4884c9d0fba45c5a94b5a45ee929
This commit reverts c4cef6fae9.
The above fix for QTBUG-25958 (cloned in QTBUG-40219) is not
complete and introduces the regression QTBUG-30049.
Task-number: QTBUG-30049, QTBUG-25958, QTBUG-40219
Change-Id: I3c4b774dce06c13cb4e089f8413a7747cedfd212
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
It is needed to control a QStateMachine object from QML.
Change-Id: I19271d97718af2d688c477647d6341f70fdef3ea
Reviewed-by: Alan Alpert <aalpert@blackberry.com>
The intent is to provide compile time validation of signals and to help
detect signal overloading in the future.
Change-Id: I9d5d46ed4b70c5d0cd407deb5928b1e76d37e007
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@digia.com>
Remove all trailing whitespace from the following list of files:
*.cpp *.h *.conf *.qdoc *.pro *.pri *.mm *.rc *.pl *.qps *.xpm *.txt *README
excluding 3rdparty, test-data and auto generated code.
Note A): the only non 3rdparty c++-files that still
have trailing whitespace after this change are:
* src/corelib/codecs/cp949codetbl_p.h
* src/corelib/codecs/qjpunicode.cpp
* src/corelib/codecs/qbig5codec.cpp
* src/corelib/xml/qxmlstream_p.h
* src/tools/qdoc/qmlparser/qqmljsgrammar.cpp
* src/tools/uic/ui4.cpp
* tests/auto/other/qtokenautomaton/tokenizers/*
* tests/benchmarks/corelib/tools/qstring/data.cpp
* util/lexgen/tokenizer.cpp
Note B): in about 30 files some overlapping 'leading tab' and
'TAB character in non-leading whitespace' issues have been fixed
to make the sanity bot happy. Plus some general ws-fixes here
and there as asked for during review.
Change-Id: Ia713113c34d82442d6ce4d93d8b1cf545075d11d
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
this is much more elegant than the so far propagated !isEmpty(QT.foo.name).
also replace feature-specific tests (no-gui and no-widgets) and the
obsolete contains(QT_CONFIG, foo) syntax.
Change-Id: Ia4b3c8febcabf9eeca67b1f9173a523820b1038b
Reviewed-by: Sergio Ahumada <sergio.ahumada@digia.com>
Reviewed-by: Tasuku Suzuki <stasuku@gmail.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Normalise all signal/slot signatures in tests/*/corelib,
except in tst_QObject, where they might be test data.
Change-Id: Id4e101f285b1676bb583b0afae06d235e599e24b
Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Change copyrights and license headers from Nokia to Digia
Change-Id: If1cc974286d29fd01ec6c19dd4719a67f4c3f00e
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Reviewed-by: Sergio Ahumada <sergio.ahumada@digia.com>
Changing it outside of the test function definition to avoid running
empty/inapplicable test functions.
Change-Id: I713560cde7f715696984ed082d682900f5f1bcdd
Reviewed-by: Qt Doc Bot <qt_docbot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Caroline Chao <caroline.chao@nokia.com>
Commit f9a17d7f0f fixed it for the case
where the sender object is in a different thread at transition setup
time. However, it still didn't work if either the sender object or the
state machine was moved to a different thread at some later time,
before the machine was started.
Therefore: Bite the sour grape and traverse all the machine's
transitions when the machine is being started, registering those
signal transitions whose sender objects are in other threads.
This will increase the machine's startup time (proportional to the
number of transitions), but at least it works in all known scenarios,
meaning we don't have to document weird restrictions regarding the
order in which the user's operations have to be done.
Task-number: QTBUG-19789
Change-Id: I5f1dd1321994e49635f52be65cf56d2678ed1253
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@nokia.com>
Qt 5.0 beta requires changing the default to the 5.0 API, disabling
the deprecated code. However, tests should test (and often do) the
compatibility API too, so turn it back on.
Task-number: QTBUG-25053
Change-Id: I8129c3ef3cb58541c95a32d083850d9e7f768927
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
The SCXML spec states that entry order should be equivalent to
"document order" and exit order should be "reverse document order".
Since QStateMachine uses child order for the entry order, the exit
order should be reverse child order.
Change-Id: Ia7b05fdd5c9261ccf202f64f8d23f5c88b20a8c3
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@nokia.com>
This makes it possible to add API for setting the restore policy
per state, or even per property assignment (QTBUG-17861).
This change is fully source compatible with Qt4.
Change-Id: I53628546b070f6fc84891f86e7ad7bd8ef5ba285
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@nokia.com>
Back when QStateMachine was changed to inherit QState, this
constructor was conveniently left out because setting the state
machine (root state) to be a parallel state group didn't actually
work. But as of commit d281aa6936,
it does work, so add the missing constructor.
Task-number: QTBUG-15430
Change-Id: I68c599baa0ef1bfc869195140cf5daf645e75b8b
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>
Some of the transition constructors didn't call the maybeRegister()
function, causing the transitions to be ignored if they were created
when the state machine was running and the transition's source state
was active.
Added tests that cover all possible cases.
Change-Id: If1b593b127bd719e3be4e5a2e6949a780c4e97c3
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>
Use the same trick as used for private signals in the models.
Change-Id: I4235788490cae0e3d554565621d145652dc5b0ca
Reviewed-by: Olivier Goffart <ogoffart@woboq.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>
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 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>
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>
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>
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>
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>
tst_QStateMachine::postEventFromOtherThread() assumed that 10,000
iterations of the event loop in a separate thread could always be
completed successfully within the default QTRY_COMPARE timeout.
This may be false if the CPU load is already high - such as when running
other tests concurrently.
Decrease the iteration count.
Change-Id: I780523f73c0c16fa0b2ab3201b2b0affdebc198d
Reviewed-by: Toby Tomkins <toby.tomkins@nokia.com>
Reviewed-by: Kalle Lehtonen <kalle.ju.lehtonen@nokia.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>
When using QSignalSpy, always verify that the signal spy is valid. This
will cause the test to give a meaningful failure when spying on a
non-existant signal. Without this change, tests that spy on a signal to
ensure that it is not emitted (i.e. by comparing the spy count to zero)
could pass erroneously if something went wrong when creating the signal
spy, as an invalid QSignalSpy will always return a count of zero.
Change-Id: I41f4a63d9f0de9190a86de237662dc96be802446
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Rohan McGovern <rohan.mcgovern@nokia.com>
