The old docu could be mis-read as: "When singleShot is true [...]
this is equivalent to calling setInterval(interval) and start()".
But what was really meant is that start(interval) is equivalent to
calling setInterval(interval) and start().
Amends 2c86903704
Pick-to: 6.8 6.10
Change-Id: I58d36ba0ed2f32e26618ad3260f9f7684be03db0
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
QTimer stores the interval in an int, a milliseconds interval that is
too-large will overflow and the value becomes negative. Clamp the
interval to INT_MAX ms. This also matches what QTimer::from_msecs()
does.
Amends f1f610bc67.
Change-Id: Id925827f632e8a8d8b8b65e6a41e8f8722344c26
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
As disccussed in the code review. Replace negative values with 1ms (not
0ms as that would spin up the event-loop too many times).
Move QTimer::start(std::chrono::milliseconds msec) API docs next to the
method definition so as to not forget changing it when the
implementation changes.
Drive-by, qWarning() and co. are marked cold so there is no need to use
Q_UNLIKELY in an if-condition leading to calling these methods.
[ChangeLog][QtCore][Important Behvaior Change] Timers with negative
intervals aren't allowed anymore, that is, if you try to start a timer
(or set the interval) with a negative value, that interval will be set
to 1ms. Previously Qt timers would let you set the interval to a
negative value, but behave in surprising ways (for example stop the
timer if it was running or not start it at all). This change affects
QTimer, QChronoTimer, QBasicTimer and QObject::startTimer().
Fixes: QTBUG-132359
Change-Id: I09309063665db051337f91160971993d9ce7911e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This de-inlines destuctors of classes whose vtables are proven to be
duplicated by -Wweak-tables using the upcoming headersclean for _p.h
feature.
Since these are all private API classes, we can pick all the way back
to 6.2, and we don't need the comment that the dtor must always stay
empty, like for public classes.
Task-number: QTBUG-45582
Task-number: QTBUG-126219
Pick-to: 6.8
Change-Id: I8c864c0d2ed3ca20d20d5cfc356290eb529edf6c
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Deduplicate some API docs.
Mention that it's a RAII class, to make it more appealing to users.
Copied the "RAII" note and link from QSemaphoreReleaser's API docs.
Pick-to: 6.8
Change-Id: I53ced6eb7c2ab55ffc04e70c250b5f5639406911
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
... since no consensus has been reached about what to do in Qt7 (whether
to fold QChronoTimer back into QTimer or let QTimer be as-is to not
break any existing code and use QChronoTimer in new code).
Pick-to: 6.8
Task-number: QTBUG-128426
Change-Id: I7d09b803b4f0df3ea7f48a5d900d0ae4be721d7b
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The range guaranteed by std¹ for nanosecond resolution is ±292 years,
not ±292 million.
¹ https://eel.is/c++draft/time.syn,
https://en.cppreference.com/w/cpp/chrono/duration#Helper_types,
std::cout << chrono::floor<years>(nanoseconds::max()) << '\n';
Since, in general, there is no integer type with ≥ 45 bits, but < 64
bits, the practical limit for milliseconds remains, indeed, ±292
million, so the QDateTime docs don't need fixing.
Pick-to: 6.8
Change-Id: I5ae7f9706f147c6f490ba17b10cebe96426bbba2
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Port the new-style singleShot() static methods from milliseconds to
nanoseconds resolution.
This matches what QChronoTimer provides, but we want to minimize
porting for users come Qt 7, so we don't want users to first have to
port to QChronoTimer::singleShot() and then back to
QTimer::singleShot(); we want them to continue to use QTimer.
The only reason QChronoTimer is a separate class from QTimer is that
the latter has an int interval property and we can't just port it to
milli- or nanoseconds chrono types if we want users to actually access
the extra range or precision afforded by the chrono types. But that's
not an issue for the singleShot() static methods, as they never return
an object that could be asked for its timeout.
The old-style static methods were already ported in the first step,
which also contain the ChangeLog common to both patches.
Pick-to: 6.8
Task-number: QTBUG-128426
Change-Id: I1899465c3b852ab546983a0bf35853fdd3f91ef3
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Port the string-based singleShot() static methods from milliseconds to
nanoseconds resolution.
This matches what QChronoTimer provides, but we want to minimize
porting for users come Qt 7, so we don't want users to first have to
port to QChronoTimer::singleShot() and then back to
QTimer::singleShot(); we want them to continue to use QTimer.
The only reason QChronoTimer is a separate class from QTimer is that
the latter has an int interval property and we can't just port it to
milli- or nanoseconds chrono types if we want users to actually access
the extra range or precision afforded by the chrono types. But that's
not an issue for the singleShot() static methods, as they never return
an object that could be asked for its timeout.
The new-style static methods will be ported in a second step.
[ChangeLog][QtCore][QTimer] The singleShot() static methods now
operate with nanoseconds resolution, like QChronoTimer. The rest of
QTimer remains milliseconds; use QChronoTimer if you need a QTimer
with nanoseconds resolution of more than INT_MAX milliseconds
range. Beware overflow that may occur when passing large milliseconds
objects that may overflow nanoseconds::rep when converted.
Pick-to: 6.8
Task-number: QTBUG-128426
Change-Id: I11e1ad8529c67b4018f6325ac408686799475823
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
It will need to be called from removed_api.cpp once we widen
QTimer::singleShot() from ms to ns.
Don't use the QAbstractEventDispatcher::Duration typedef in qtimer.h
to avoid including the resp. header. Keep the typedef as the return
value on the definition of from_msecs(), though, as a static assertion
that they're identical.
Pick-to: 6.8
Task-number: QTBUG-128426
Change-Id: Ib59895f4441e92813fe39778bb3836b039fdfbf0
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Unify the wording "running" and "active".
"Running" seems more natural, so keep that wording,
and replace "active" with "running" in API docs.
Pick-to: 6.8
Change-Id: I300f530d1cfe789f74ed32f57afe9388f2127ead
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Despite using different code paths, both stop and then
re-start an already active timer, which invalidates
the id().
While at it, port the occurrences of timerId() to the
modern function id(), which exists in both QTimer and
QChronoTimer
Pick-to: 6.8
Change-Id: I5db099b198b1c11e1cdbd0fbb30ecece5d0135c8
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
Move the implementation of fromSecs() from the header to the
qtimer.cpp file and make it file-static. There are no callers of the
function outside qtimer.cpp.
Amends e0573e7364.
As a drive-by, rename the function to snake_case to indicate that it's
a file-static.
Pick-to: 6.8
Change-Id: Ifa32df8a28816cd9cae44cdb9d481df94d33d741
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
QChronoTimer is in Qt 6.8.
Found in API review.
Pick-to: 6.8
Change-Id: I7f20958948cb635ccd1f4cef383aed810a188f12
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Converting from int milliseconds to int64_t nanoseconds can't overflow
(it won't even for picoseconds, so we'll be fine for a couple more
decades), so we only need to address the cases where the millisecond
value was passed in int64_t: that is, in the std::chrono::milliseconds
overloads. For the other cases, I added a comment.
Amends bfc7535a10 to not allow the
detected overflow to happen at all, which could cause the timer to
become very small. Instead, we saturate to the maximum, which is about
292 years (just under 106752 days). That's longer than computers have
existed, so the chance that some Qt application is still running on a
computer without any reboots from today to 24th century is remote at
best.
This parallels QDeadlineTimer, which already has code to saturate when
using milliseconds.
Change-Id: I6818d78a57394e37857bfffd17b9b1465b6a5d19
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Which will be used to represent timer IDs. Thanks to Marc for the idea
to use "a strongly typed int".
QTimer got a new id() method that returns Qt::TimerId (can't overload
timerId()). Various classes in qtbase have a member named timerId(), but
a new method is needed anyway in QTimer so id() it is (this is the
reason QChronoTimer only has id() and no timerId()). Besides
timer.timerId() has an extra "timer".
This commit fixes the inconsistency between QObject using `0` timer id
to indicate "failed to start", while QTimer::timerId() returned `-1` to
indicate "timer is inactive". QTimer::id(), being a new method and all,
now returns Qt::TimerId::Invalid, which has value `0`, so that the
values match between the two classes. Extend the unittests to ensure
QTimer::timerId()'s behavior is preserved.
[ChangeLog][Core][QObject] Added Qt::TimerId enum class, that is used to
represent timer IDs.
Change-Id: I0e8564c1461884106d8a797cc980a669035d480a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Q{Chrono}Timer::isActive() has to use isActiveData so that the bindable
property is correctly queried. However in other places in the code we
can take a shortcut by checking id > 0.
So rename QTimerPrivate::isActiveActualCalculation() to make it more
palatable and use it throughout the code.
Change-Id: I3378233e553fd860d9f105bba013dc9ffc31a2ba
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The interval in QTimer is a QProperty of type int, which means it's
limited to the number of milliseconds that would fit in an int (~24
days), this could cause overflow if a user constructs a QTimer with an
interval > INT_MAX milliseconds. And it can't be easily changed to use
qint64/std::chrono::nanoseconds:
- changing the getters to return qint64 means user code would have
narrowing conversions
- the bindable QProperty interval can't be changed to qint64 during
Qt6's lifetime without the risk of breaking user code
- adding a new bindable QProperty that is qint64/nanoseconds is an
option, but it has the complication of what to do with the int
interval; set it when setInterval(milliseconds) is used by using
saturation arithmetic? and what about notifying observers of the
changed interval?
Thus the idea of creating a new stop-gap class, QChronoTimer, as a
cleaner solution. Both classes use QTimerPrivate.
During the lifetime of Qt6, QTimer's interval range is about 24 days,
whereas QChronoTimer's interval range is about 292 years
(duration_cast<years>nanoseconds::max()).
Currently the plan is to fold QChronotTimer back into QTimer in Qt7.
Mark all QPropertyS in the new class as FINAL since they aren't
intended to be overridden; this offers a performance boost for QML[1].
[1] https://lists.qt-project.org/pipermail/development/2024-February/044977.html
[ChangeLog][QtCore] Added QChronoTimer, which uses a
std::chrono::nanoseconds intervals, as a replacement for QTimer.
Fixes: QTBUG-113544
Change-Id: I71697f4a8b35452c6b5604b1322ee7f0b4453f04
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
singleShot() (static) methods:
QSingleShotTimer's interval isn't limited by the `int` interval in
QTimer, so this is OK, no narrowing.
start(int)/setInterval(int):
Techincally it makes no difference which overloads delegate to which,
because QTimer stores the interval in an `int` (QProperty); so any
{int interval,chrono::milliseconds.count()} > INT_MAX is narrowing
anyway. But it's less confusing and matches what has been done in other
classes when porting them to chrono, int overload delegates to chrono
overload.
Change-Id: I5ae0888f16130ae28a74be4498a180485fa34550
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Also de-duplicate the code by using defaultTypeFor() in singleShot(),
this way the comment and the calculation are done in one central place.
Pick-to: 6.7
Change-Id: Ib822cae0e9228e546b664fbac728a60d65c4bbc3
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
QObject::startTimer() returns 0 in case of failure, for example when
someone tries to register a timer with a negative interval.
However, QTimer internally uses -1 as an invalid timer id.
This could lead to a situation when the timer was not really started,
but QTimer::isActive() returned true.
This patch fixes it in two ways:
- check the return value of QObject::startTimer() and treat 0 as an
error.
- do not treat 0 as a valid timer id when calculating the active state.
As a drive-by: move the `using namespace std::chrono_literals;`
declaration to the top of tst_qtimer.cpp, so that we do not need to
repeat it in each test case.
Fixes: QTBUG-122087
Pick-to: 6.7 6.6 6.5
Change-Id: I0e21152b2173ebb5fb0dada1b99a903a321ca9c4
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Use std::chrono::ceil<milliseconds> to match what
QDeadlineTimer::remainingTime() did.
Drive-by change: make a method private instead of protected, nothing
inherits from this class anyway
Change-Id: I605b7c25ea7501ee92518ec9f0ff049ed810bfb4
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
So that it can be used in QTimer and soon-to-added QChronoTimer, this is
less code duplication.
Change-Id: Icc5f2028d776a34c06ba20fe41f571cd3821c64c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The bindable property tests were not using the QTestPrivate helpers, so
add a new test which uses them.
The new tests revealed a binding loop for the interval property.
Fix it in a usual way by explicitly removing the binding and using
{set}ValueBypassingBindings() in the setter.
Task-number: QTBUG-116346
Pick-to: 6.6 6.5
Change-Id: If94f57938da449a68e3527aead5ebd55ba410adb
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
It was introduced in 4368179c37
Use QBAV to trim operation and then make QBA
Change-Id: I578305e5b5254c66052d8a11815aaa7209e629bb
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
I thought it went without saying...
Fixes: QTBUG-116218
Pick-to: 6.6
Change-Id: I964c2b1e6b834feb9710fffd177c8338f8f1e618
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
This was missing for a while, and there is nothing fundamentally
missing for it to work.
With the more recent work around slot objects and invokeMethod in
general, it is a good time to add support for this.
In this patch, when connecting to a functor, it automatically deduces
the overload to call based on the arguments passed to invokeMethod.
Sharing code with QObject::connect could be done, but they have a
key difference that makes it harder:
With signal emissions we throw away trailing arguments that are not
used: i.e. `signal(int, int)` can be connected to `slot(int)` or
`slot()`. With invokeMethod that's not a thing. So we will need a way
to toggle that behavior during resolution.
[ChangeLog][QtCore][QMetaObject] Added support for passing parameters
to the overload of QMetaObject::invokeMethod that takes a functor. These
new overloads must have the return-value passed through qReturnArg().
Change-Id: If4fcbb75515b19e72fab80115c109efa37e6626e
Reviewed-by: Ievgenii Meshcheriakov <ievgenii.meshcheriakov@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The was introduced with the rewrite of QMetaObject::invokeMethod() in
commit 0f76e55bc4, because we have an
optimization for zero timers to avoid creating a temporary
QSingleShotTimer object. The old implementation did attempt to normalize
the target slot name, but did so because it looked metamethods up using
QMetaObject::indexOfMethod:
int idx = meta->indexOfMethod(sig.constData());
if (idx < 0) {
QByteArray norm =
QMetaObject::normalizedSignature(sig.constData());
idx = meta->indexOfMethod(norm.constData());
}
The new implementation does not use this method so it didn't need to
attempt to normalize.
I am fixing this only in QTimer and not in QMetaObject::invokeMethodImpl
(even though it is trivial to do so) because I don't believe spaces in a
pure string to invokeMethod were ever expected to work:
QMetaObject::invokeMethod(obj, "slotName ", Qt::QueuedConnection);
The Q_ARG and Q_RETURN_ARG (for code not recompiled) still does
normalization inside QMetaType::fromName().
Fixes: QTBUG-116060
Pick-to: 6.5 6.6
Change-Id: I964c2b1e6b834feb9710fffd177cac60c83ef413
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Drive-by change: use \code, better formatting especially for longer
lines of code.
Change-Id: I90dbde17a5bea276c86304bff64027dd9d248a21
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
It actually takes one parameter, because in this overload the connection
type can't be specified, for example:
QTimer timer;
timer.callOnTimeout([]() { qDebug() << "slot"; });
The call chain is:
QObject::connect(timer, &QTimer::timeout, functor);
connect(const typename QtPrivate::FunctionPointer<Func1>::Object *sender, Func1 signal, Func2 &&slot)
connect(sender, signal, sender, std::forward<Func2>(slot), Qt::DirectConnection);
the connection type is always DirectConnection.
Spotted by Giuseppe in code review.
Pick-to: 6.6 6.5 5.15
Change-Id: Ia8bbd91e98a357244cbfae4e3ed63d4c73038fa2
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Amends recent changes that added std::chrono support by making
the duration type of QTimer::singleShot a template parameter.
Change-Id: If3b5f0ad99304cb292412bb8467ba6852e47654f
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Implicit capture of *this by [=] is deprecated in C++20, and the
replacement [=,this] is not available in C++17. We also can't use [&],
because of QueuedConnection, so need to bite the bullet and list all
captured variables separately.
Amends 87535e4e43.
Change-Id: I5b3a713bf9220746d10d594d1a248028157ad170
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Amend 4d90c4e74a by clarifying why
moving the QSingleShotObject to the receiver's thread is a good
idea. Move that logic into a separate function and use that also
for the string-based connection.
Optimize the implementation by delaying the timer creation until
after we have moved the QSingleShotTimer object to the target
thread, using a queued metacall if needed to create the timer.
This avoids the creation of the timer in the wrong thread and
then the recreation of the timer in the new thread when QObject
handles QEvent::ThreadChange.
To avoid that the timer is created when it has already expired in
real time, use a deadline timer and fire timeout immediately when
it has expired by the time we get the metacall.
Since the timerId might now not be initialized in the constructor,
initialize it to -1.
Augment the crossThreadSingleShotToFunctor test function by
deliberately not starting the thread until the deadline expired.
[ChangeLog][Core][QTimer] Single-shot timers with a string-based
connection are now started in the receiver's thread, not in the
thread that creates the timer.
Task-number: QTBUG-112162
Change-Id: I3fc94c34c21d9f644da41a2e4c2da479980b8580
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
For single-shot timers, at least. QSingleShotTimer had either an
optimization or the only way to make new-style slot invocations by
storing the QSlotObject pointer and calling it directly. Instead of
doing that, let's just actually connect and let QObject handle the
actual delivery.
[ChangeLog][QtCore][QTimer] Fixed a bug that caused slots connected to
single-slot timers using the new-style connection mechanism to be
delivered in the wrong thread.
Fixes: QTBUG-112162
Pick-to: 5.15 6.2 6.5
Change-Id: Idd5e1bb52be047d7b4fffffd174eadb227ab65ee
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
I.e. use chrono first, this means the API isn't limited by the size of
int, but by the size of whatever chrono::milliseconds uses (typically
int64_t), and chrono units are much more readable as well.
Task-number: QTBUG-110059
Change-Id: Ie7f2d90864782361a89866693011803be6f8545e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
It demonstrates timerEvent() and some QFontMetrics
There are other examples that demonstrates this
Pick-to: 6.5
Change-Id: I4ad6f30c8ef93c995f980545ed88ab13b9aa9c7d
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Replace the current license disclaimer in files by
a SPDX-License-Identifier.
Files that have to be modified by hand are modified.
License files are organized under LICENSES directory.
Task-number: QTBUG-67283
Change-Id: Id880c92784c40f3bbde861c0d93f58151c18b9f1
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Keeping the event loop busy with a zero-timer like
that is bound to cause trouble and highly erratic behavior of the UI.
Fixes: QTBUG-96869
Pick-to: 6.1 6.0 5.15
Change-Id: Idf02a7a7e0689c59e1223610a6525262ead56d8d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Too much of the existing code in Qt requires eager evaluation without
large scale modifications. Combined with the fact that supporting both
eager and lazy evaluation has a high maintenance burden, keeping lazy
evaluation, at least in its current state, is not worth it.
This does not diminish other benefits of the new property system, which
include
- a C++ API to setup and modify bindings and
- faster execution compared to QML's existing bindings and the ability
to use them without having a QML engine.
We do no longer benefit from doing less work thanks to laziness. A later
commit will introduce grouping support to recapture some of this
benefit.
[ChangeLog][Import Behavior Change][QProperty] QProperty uses always
eager evaluation now when a dependency in a binding changes.
Change-Id: I34694fd5c7bcb1d31a0052d2e3da8b68d016671b
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Andreas Buhr <andreas.buhr@qt.io>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
After 2ffb91ac59 we manually call notify()
for QObjectCompatProperties. Currently we always call it when setting
values to compat properties, even if the value hasn't actually changed.
Fixed to call notify() only if the value is being changed.
Task-number: QTBUG-85520
Change-Id: I385db84c4009c45406e204b96e0e37ce5fa8882b
Reviewed-by: Andreas Buhr <andreas.buhr@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Andre Hartmann
Ahmad Samir
Marc Mutz
Thiago Macieira
Ivan Solovev
Anton Kudryavtsev
Mårten Nordheim
Tor Arne Vestbø
Volker Hilsheimer
Jan Arve Sæther
Konrad Kujawa
Lucie Gérard
Edward Welbourne
Fan RuiJie
Lars Knoll
Sona Kurazyan