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>
It's quite flaky, and since we currently don't have FTP support
there's no point in making sure it works
Pick-to: 6.5 6.2
Change-Id: Ice01e8d36f2b7830813119da3513cc01ec005c46
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
MET is an alias for CET, so the test's attempts to detect whether it's
in CET can't distinguish them other than by checking the abbreviation.
Change-Id: Ibb467d9bb2d983ca16302111b54f664a614057c2
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
It turns out that Alaska and The Philippines had historical offsets
exceeding 15 hours, prior to day-transitions to bring their dates in
sync with their respective sides of the international date line.
Change-Id: I48fdf3aa6d8c0bacb368d08316733a10ee11a281
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The recorded images frequently show traces of a fading-out command
prompt window that is opened by the test execution. We evidently have
to wait longer for all window-level effects are finished.
Pick-to: 6.5
Change-Id: I50db54ff33bf4bb1ef7c480a4aede1d5de1618c3
Reviewed-by: Santhosh Kumar <santhosh.kumar.selvaraj@qt.io>
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
...so we have core profile compatible GLSL code
in them. Just so one can run e.g. triquadcube with
-g -c (OpenGL with a core profile context).
Pick-to: 6.5
Change-Id: I585d3b4f0c7cd71ce7fae1fff4bf9a84cb7410da
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
qtbase/c27d2a57a441f9a1ce760e71635bd4c96882249d caused the code
to go through QStandardItemPrivate::setItemData() which does
not handle the special treatment of Qt::EditRole completely.
In the constructor of QStandardItemData; map Qt::EditRole to
Qt::DisplayRole to fix this as is done in setData().
Adapt the existing tst_QStandardItemModel::getSetItemData() to check
whether both roles are received in the dataChanged() signal.
Pick-to: 6.5
Fixes: QTBUG-112326
Change-Id: I133d058bacc3388c612c5b4fb18b54f5ef5cb56f
Reviewed-by: Samuel Gaist <samuel.gaist@idiap.ch>
Reviewed-by: David Faure <david.faure@kdab.com>
Removing a few unused variables in auto tests that were triggering
`-Wunused-but-set-variable`.
Pick-to: 6.5
Change-Id: I74bd0d7335d8bddeb18687b18c8a8be965f9fa20
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This removes all uses of QDeadlineTimer::t2 member in the .cpp (so it
gets marked [[maybe_unused]]) and greatly simplifies the code.
Change-Id: Ieec322d73c1e40ad95c8fffd17465bd50c1113ea
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
You can't partially specialize a template function, so these
specializations for steady_clock only worked if the Duration parameter
was nanoseconds. This could have been solved with function overloads
instead, but I find the if constexpr code simpler to read.
Pick-to: 6.5
Change-Id: Ieec322d73c1e40ad95c8fffd17468bd73fc2fe24
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
This matches the work that was done for QElapsedTimer. The
QDeadlineTimer::t2 member is now always 0.
This also removes the last distinction of timer types. Originally I had
intended to use CLOCK_MONOTONIC_COARSE on Linux[1], but that created
more problems than was worth, so I abandoned the idea in 2016.
[1] https://codereview.qt-project.org/c/qt/qtbase/+/159933
Change-Id: Ieec322d73c1e40ad95c8fffd17468b313798ef79
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
This commit deletes the direct, low-level functionality that
QElapsedTimer has carried since it was introduced. Everything now uses
only std::chrono::steady_clock and std::chrono::nanoseconds.
QDeadlineTimer temporarily still uses qt_gettime(), which is moved to
qcore_unix.cpp.
Task-number: QTBUG-110059
Change-Id: Ieec322d73c1e40ad95c8fffd174641a469b1eee5
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Modeled after Metal's cb.GPUStart/EndTime. Implemented with timestamp
queries for other APIs.
Implemented for Metal, D3D11, Vulkan for now. No more callback, just
a getter on the command buffer which returns the latest known value,
referring to some previous frame. This makes it a lot more usable
than the original solution that is not really used anywhere at
the moment.
Now works for offscreen "frames" as well, this was not implemented
before.
Opt in with a new QRhi::create() flag because we cannot tell in
advance if the getter will be called or not, and this way we can
skip recording the timestamps by default. The cost is probably
minimal, though. Qt Quick will set this automatically when running
with QSG_RHI_PROFILE=1.
Change-Id: I903779984a4e0bbf1d03806d04bf61571ce23d72
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
...even when the QRhi is already gone. This should not happen in
well-written applications and libraries, but we handle this
gracefully in the regular dtor and destroy() for resources that
register themselves to their creator QRhi, so by registering
everything we can offer this to all QRhiResource subclasses.
We still want to differentiate between native resource owning
QRhiResources and others (that do not create native graphics
objects), so do this via a flag passed to registerResource().
This way the behavior with QT_RHI_LEAK_CHECK=1 does not change.
Pick-to: 6.5
Fixes: QTBUG-112914
Change-Id: I9bafc81ef7a4ae76f356fc5f6248628d1f8791e0
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Christian Strømme <christian.stromme@qt.io>
Avoid capturing the same property multiple times in a binding by
storing them in the BindingEvaluationState. We store them in a
QVarLengthArray array, as the number of properties involved in a binding
is expected to be rather low, so a linear scan is fine.
Avoiding double capture is a good idea in general, as we would otherwise
needlessly reevaluate bindings multiple times, and also needlessly
allocate memory for further observers, instead of using a binding's
inline observer array.
Even more importantantly, our notification code makes assumptions that
notify will visit bindings only exactly once. Not upholding that
invariant leads to memory corruption and subsequent crashes, as
observers allocated by the binding would get freed, even though we would
still access them later.
Fixes: QTBUG-112822
Pick-to: 6.5 6.2
Change-Id: Icdc1f43fe554df6fa69e881872b2c429d5fa0bbc
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Task-number: QTBUG-109779
Pick-to: 6.5
Change-Id: I21ecd4910ba3d699e44d9ea922093e98e0b8a335
Reviewed-by: Inho Lee <inho.lee@qt.io>
Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
Fixes compiler warnings about narrowing conversions.
Found by compiling with clang and -Wshorten-64-to-32.
Drive-by changes:
- use range-for instead of an iterator based loop
- use strlen("*.") instead of magic number 2
Pick-to: 6.5
Task-number: QTBUG-102461
Change-Id: I0bf2299049c0411ed496468238ca30b69946ffc2
Reviewed-by: David Faure <david.faure@kdab.com>
Similar to TableScope - create a helper class to make sure the
procedures are cleaned up on exit so they don't affect the result during
the next test run.
Change-Id: Ic5b02ca63e03f330392797ed22313767557fc548
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Equivalent to the test added to the QWidget test case, but since QtWidgets
code contains logic to both synthesize and compress/filter enter/leave
events, we can only verify that the QWindow does get the events.
The test is very flaky on Windows, so blacklisting it right away.
Change-Id: Ic1da9439f60f619a76a3653a23fef8e9ebc0e75d
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The classification of local time as ahead of UTC, behind it or equal
to it gets complicated by zones near the prime meridian - some of
which have varied which side of it they nominally are - or the
international date line, which a few zones have crossed.
So, instead of having one classifying variable, split to having three,
one for the distant past (when using local solar mean time), one for
the epoch and one for the distant future.
Change-Id: I7c0da376e1625372086dc51afa815756f0bde442
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This makes it possible, on a system with /usr/{lib,share}/zoneinfo/,
to systematically run a command with TZ set to each system-supported
zone. For example, it can be used to verify that a corelib/time/ test
passes regardless of the valid setting of TZ.
Change-Id: I6ea9a64d8bcb745aea80ab9ae431602d3e3265a1
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The stepIntoDSTGap() hour cases were already conditioned on hour > 0,
explain why. The month and year tests need similar checks for kindred
reasons; add and document those checks.
Pick-to: 6.5
Change-Id: Ibcb69449fcd572ee94306a805fd680e9b5155322
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The zone had a transition at the start of 1900, so QDTP's default date
ends up being 1900-01-01 at 00:02:20 instead of at 00:00:00; and any
parsing of date-time strings that doesn't set the minutes and seconds
consequently ends up "wrong" (about a field that wasn't specified).
Change-Id: If4b9864616fa08bc023a6974dae255f96ca90f83
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The zone had a transition at the start of 1900, used as default date
by the parser. This leads to the default minutes and seconds being 2
and 20, rather than 0. Since this test is parsing a date-only string,
only check the date of the result, to avoid failing in Cocos.
Pick-to: 6.5
Change-Id: Ifb307eadb747097988bcf0afc6f307835ff2c8ec
Reviewed-by: Konrad Kujawa <konrad.kujawa@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
America/Sao_Paulo was not alone in starting 2008-10-19 with a spring
forward. Include the other affected zones in the check to tune the
expected start-of-day time. See [0] for details.
[0] https://github.com/eggert/tz/blob/main/southamerica
Pick-to: 6.5
Change-Id: If251d8b715090319441790696983273637765d2e
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Some QDateTime tests get tripped up by a transition at the epoch in
Baja Mexico. For the operator_eq() and time-difference test, simply
using startOfDay() instead of QTime(0, 0) - which was skipped - solves
the problem. For addDays() and fromStringDateFormat(), skip the
affected tests.
Change-Id: I3620f0d1e4b05d9f799662eea96a40c8284de331
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The zones in Baja Mexico had a transition at the epoch.
Change-Id: Ic70e23bcc980bf371e925fcb8fb83ca5ef000c9f
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Given that QDTE only supports local time and UTC, using Europe/Oslo as
zone was disconnected from reality, especially as various QDateTime()s
were constructed using local time. Use the system zone.
Pick-to: 6.5 6.2
Change-Id: I95b3a6a6acf9ffc2b8c7f05d3dd9440ff173abfe
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The test wants to start shortly after the transition, then step an
hour backwards, into it, to check we land safely on the other side.
However, it assumed the gap witdh was an hour, which is not reliable.
Use the gapWidth already used in computing springGap instead.
The -3590 seconds in the result time is correct, as it's the ten extra
seconds we started beyond the gap, minus the hour we step backwards.
Pick-to: 6.5
Change-Id: I4399af7e54a60bd55ea51d054d3cd2ecfcb0e354
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The "{forward,back} to %s, correct to nearest" tests were reporting
the time of the transition as %s but, like the jump test, were using
the middle of the gap as the time to set. So compute that mid-time's
string once and use it in all three test names. Also renamed some
local variables to accommodate the new one for this text.
Pick-to: 6.5
Change-Id: Ic6c40c470fc74ae8bcfc0dc9d1596af06318a883
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Although the zone's daylight time offset is usually the width of the
gap, it's possible the transition is (or includes) a change to
standard time; so determine the actual gap width by comparing the
difference between time a day earlier and later to the usual duration
of two days. Also skip the test if the transition isn't really a gap.
Pick-to: 6.5
Change-Id: I56e381c9f74cfa1806d43b3ed5e4637436ebdf57
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The function is passed a zone to work in, so setting the transition to
local time made no sense; set to the given zone's time, instead.
Pick-to: 6.5
Change-Id: Icaa0955fe5fcd5bc257322afcb7e25e932dedd1b
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Mate Barany <mate.barany@qt.io>
We check three sample dates, in different years, so don't compare
their year() to 1970, but to their respective actual years. In the
process, package the arrays iterated for these checks into a constexpr
struct array and reverse them so that, instead of reverse-iterating
and indexing, we can use a ranged-for loop.
Change-Id: I214685346c637875a4ea31125c324851eb4308db
Reviewed-by: Øystein Heskestad <oystein.heskestad@qt.io>
Reviewed-by: Ievgenii Meshcheriakov <ievgenii.meshcheriakov@qt.io>
Reviewed-by: Konrad Kujawa <konrad.kujawa@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The name final is suboptimal, given that it's also a keyword.
Rename initial at the same time.
The local-time parts of the test are apt to fail if local time
coincides with the zone being tested, as previously noted. Document
known cases of such coincidences, to help someone studying a failure
to know why it happened.
Change-Id: I1f1f302f161373a154066df210e03725b9a5f9ed
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
When the test failed, it did so in triplicate.
Pick-to: 6.5
Change-Id: Ia871aed0a5960120a2659a6778c10dccd4b2953a
Reviewed-by: Jason McDonald <macadder1@gmail.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
In case FEATURE_timezone=OFF auto-tests should still be built successfully
Change-Id: I0226a7d7781a412bf9e9935c2cf1a48b1ce427b5
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Noticed the warnings when building the manual tests.
Pick-to: 6.5
Change-Id: I7f927f42f11d234ec3c980f36d8e12c0c49be712
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
It's unlikely we will ever use pro2cmake at this project stage,
so it doesn't make any sense to keep the 'special case' markers
in the CMake scripts. Remove them and replace with TODO where
needed.
Change-Id: I84290c20679dabbfdec3c5937ce0428fecb3e5a7
Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
We sometimes use Objective-C++ code in files with a .cpp extension,
to avoid the churn of adding a foo_mac.mm file. Instead of manually
telling the compiler to build these files in Objective-C++ mode, we
use CMake's intended mechanism, which means genex constructs such as
$<$<COMPILE_LANGUAGE:OBJCXX> will work for these files as well.
Pick-to: 6.5 6.2
Change-Id: If295c3f34f6bee9f4d9f877f519c9c7770665fee
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
When the DPI of a window changes due to being moved to another screen,
or the current screen reconfiguring, the mask we've set earlier is no
longer correct, as the mask was set based on the original screen's
scale factor and in relation to the former platform geometry of the
window, which now has changed.
Like the geometry of a QWindow, the mask is expressed by the user in
the QtGui coordinate system, so it's the platform's job to transform
this into the platform coordinate system and update it when needed.
Add a manual test that users a QWidget and a Q(Raster)Window side by
side.
There's still an issue with the screen change being triggered to
early, via QWindow::setGeometry, instead of when the window has
actually moved to the new screen, resulting in the paint event
flushing to a window and backingstore that is in the wrong state,
but this requires further research to fix.
Task-number: QTBUG-97642
Pick-to: 6.5 6.2
Done-with: Volker Hilsheimer <volker.hilsheimer@qt.io>
Change-Id: I7ab2d267fbaf6ac32b507d05a418eb025b354a0b
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
