It noted that an unspecified function claimed the offset it was
checking should be +1, while testing it against that or -1. The
function turns out to be QDateTime::addDays(), whose doc did indeed,
misleadingly, say that it lands after a gap it would have hit. It in
fact overshoots the gap in the direction of its change. Amend its
docs, likewise those of addMonths() and addYears(), to reflect the
true behavior.
Amend the test to look at the direction of the step its taking and
anticipate that the adjustment will be in the same direction; then
compare the actual adjustment to that.
Change-Id: I9ab918fac0ab2195ef014983f37fccc435bf0498
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
The implementation previously worked for non-short date-times, where
the offset has been remembered since construction. This included the
case of zoned times (and local times more than 2^55 msec away from the
start of 1970) that hit a spring-forward's gap; but excluded local
times that did the same (within 2^55 msec of the epoch).
This precluded an offset check in a spring-forward test, now added.
We can in fact determine the offset whenever we got a valid date and
time (we do so in the course of initializing the object, and when
asked for toMSecsSinceEpoch(), even when invalid), and we should not
use the value of the recorded offset if we didn't get a valid date and
time, so amend to always return 0 if we didn't get valid date and time
and always report the correct offset otherwise.
In the process, amend offsetFromUtc()'s computation to directly
resolve the date-time, rather than doing so via toMSecsSinceEpoch(),
which has to repeat decision-making offsetFromUtc() has already done
by the time it calls it. Also amend toMSecsSinceEpoch() to return 0 if
we didn't have a valid date and time to begin with, so it only
attempts to produce a useful result in the case where construction
attempted to resolve the date-time.
Change-Id: I6574e362275ccc4fbd8de6f0fa875d2e50f3bffe
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The resolution selects a point in time outside the gap, which will be
represented by toMSecsSinceEpoch()'s return, despite the QDT object's
isValid() returning false. Previously we retained the
originally-calculated msecs, so as to keep date() and time() matching
what was asked for. However, this required adjusting offset, which was
not remembered for local times within 2^55 milliseconds of the start
of 1970. This lead to an inconsistency between the offset from UTC
reported for the resolution for a local time further from the epoch,
or for a time-zone, and the actual offset from UTC at the time
indicated by the return from toMSecsSinceEpoch().
Instead, retain the actually calculated offset (even if we aren't
going to remember it) and adjust the msecs to the value that ensures
toMSecsSinceEpoch() will get the selected resolution. This
incidentally means that, when toMSecsSinceEpoch() has to re-resolve
(for a local time within 2^55 msecs of the epoch), it avoids
revisiting the complications of hitting the gap.
In passing, change internal stateAtMillis() to take the QTimeZone it
is passed by const reference, to save a copy (noticed during debug).
Also tweak a comment in a test to be explicit about a default value.
[ChangeLog][QtCore][Possibly Significant Behavior Change] When
QDateTime is instantiated for a combination of date and time that was
skipped, by local time or a time-zone, for example during a
spring-forward DST transition, the invalid result's time() - and, in
rare cases, date() - no longer match what was asked for. Instead,
these values and offsetFromUtc() now match the point in time
identified by toMSecsSinceEpoch().
Change-Id: Id61c4274b365750f56442a4a598be5c14cfca689
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Pass the pointer to the QWidget the icon is painted on to
QStyle::standardIcon/Pixmap().
Change-Id: If9dbc3acb621fb60152f2e12fc0080f354397a99
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The slider handle has a small bug not painting the underlying rectangle
with the correct direction which lead to a small visual glitch only
visible with a high-dpi screen.
Change-Id: Ie75e034b85542228ed7a8372dc7b9a419731630d
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
In gtk3 theme, the inactive color group had been set with incorrect
palette or not been set for some cases, which leads to glitch when
moving application window. This is because inactive group palettes were
applied during window movement and its expected to be set with correct
palettes.
This patch fixes this issue by setting correct palette for inactive
color group.
Fixes: QTBUG-112879
Pick-to: 6.6 6.5
Change-Id: I6658843626f322fee0ef99dfafb550956e3e0aee
Reviewed-by: Jonas Karlsson <jonas.karlsson@qt.io>
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
clang-format and the optimized SIGNAL/SLOT notation are not
good friends.
Change-Id: Id07936b4654e567b59af5a8b1d7baad000484931
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Mate Barany <mate.barany@qt.io>
If a QShortcut is registered with a QWindow as its parent, but QApplication
is used, we end up in QApplicationPrivate::createShortcutPrivate(), and
create a QtWidgetsShortcutPrivate that implements shortcut context matching
via qWidgetShortcutContextMatcher.
The problem is that qWidgetShortcutContextMatcher expects the windows
to be QWidgetWindows, which meant that plain QWindow based shortcuts
would always fail.
This can happen for example if a QApplication is used in Qt Quick
to provide dialog fallbacks, but QShortcuts are otherwise used
with plain QWindows, or QQuickWindows e.g.
We now defer the check of whether there's an active (widget) window,
and fall back to QtGui's simpleContextMatcher in case we don't find
a QWidget, QAction, or QGraphicsWidget shortcut owner to handle
the matching for.
Note: We don't support shortcut matching for QAction in QtGui,
but this is left for another day. There is also a discrepancy
between how QtGui and QtWidgets handles Qt::ApplicationShortcut.
The former will treat it as a match even if there is no active
QWindow, while the latter requires that there's an active widget
window.
Fixes: QTBUG-116221
Change-Id: I487995f2e660a40f6556828b84a521d81a58f1b6
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Amends 39294317e0, after which class names have to be slash-separated.
Change-Id: I5b8415b711f4deed9b6134eccd3232f299b1ef4d
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Reviewed-by: Juha Vuolle <juha.vuolle@qt.io>
A little code simplification. And we can enable exception handling
explicitly for GCC/Clang by adding "-fexceptions", it was missing
in the old code, add it as well.
[ChangeLog] [Build System] Qt explicitly pass -fexceptions now on
non-MSVC toolchains, if exception handling is not disabled in CMake
configure.
Change-Id: Id9d61d3ee8b7d490f4a743e34e8be321af080be0
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Q_GUI_EXPORT the private header to access it from outside Gui.
Task-number: QTBUG-116826
Pick-to: 6.6
Change-Id: I6aaabe2df7ebebd7b53662f47a52c748344067bc
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
Amends ef9fe7a99a and fixes some rare
cases where the macro argument wasn't a single token, such as what was
found in PySide code:
qCDebug(*category, "%s", %2);
Fixes: QTBUG-117153
Pick-to: 6.5 6.6
Change-Id: I85599ea5ca7a4b79a8bbfffd178a51023648f244
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Amends da95ad91b3. Caught by CodeChecker:
std::move of the const expression has no effect; remove std::move()
I'll instead remove the const.
Pick-to: 6.6
Change-Id: I8f3ce163ccc5408cac39fffd178ccec9fcc38e9c
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
The documentation above says it's intentionally not const and that's how
I had designed it. It was added by accident on with the noexcept
qualifier on commit c129362b4d ("Add a
couple of noexcept").
Change-Id: I8f3ce163ccc5408cac39fffd178c7fd237c6e079
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Testing for Standard Library features with compiler version macros was
incorrect. This commit fixes that to check the correct macros. That
fixes the use of Clang-cl / ICX because Microsoft STL doesn't have
support for 128-bit integers (because Microsoft's compiler doesn't) but
Clang does.
Amends 104a0a9ecd.
Fixes: QTBUG-117870
Pick-to: 6.6
Change-Id: I85599ea5ca7a4b79a8bbfffd178b9688e7c1bf42
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
MSVC also supports "-w" since at least 2015:
https: //learn.microsoft.com/en-us/cpp/build/reference/compiler-option-warning-level?view=msvc-140
Change-Id: If0775b1dd6e0785e2e42a25ed2b7f1346f7c345e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Generalized from the logging used in the Apple key mapper.
Change-Id: I61cc120e31b72995071756961d36f6a7fae14553
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Having the explicit type instead of the opaque int makes it clearer
what we're dealing with.
Task-number: QTBUG-116873
Change-Id: I19e42ed329e15ab25a958602ecfb99b1c9d52a99
Reviewed-by: Liang Qi <liang.qi@qt.io>
After d9bb8c0a17 we call inputDirection()
on the platform input context to initialize the direction at startup.
The test can't assume there are no other callers to the functions
in the QPlatformInputContext layer.
Change-Id: Ic1cecd608b2759e703a17838fcf24b4ff53ad07e
Reviewed-by: Liang Qi <liang.qi@qt.io>
The QtQuick3D semi-public headers were not installed correctly due to a
typo in QtModuleHelpers. This amends 9c3c87f6d0
Change-Id: Iec6ed4e1785fbb1189385104f476c37481ef47fb
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Several places already did, and it reads better, so be consistent.
Change-Id: Ic272b2d342cec06ec657c3d0995258b975e0bf87
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
It's possible, as was (and still is) documented, at least on Windows,
for the backend to determine the system local time zone's properties
but not its IANA ID. (That involves an update to Windows introducing a
Windows zone ID unknown to the CLDR with whose data Qt was compiled.)
Formerly this lead to systemTimeZoneId() and systemTimeZone().id()
being inconsistent. Furthermore, either in this case or when the
system zone can't be determined, passing the return from
systemTimeZoneId() to the constructor got a valid QTimeZone that did
not faithfully represent the system's local time or the return from
systemTimeZone().
[ChangeLog][QtCore][QTimeZone] When unable to determine the IANA ID of
the system's local time zone, QTimeZone::systemTimeZoneId() now
returns empty instead of the "UTC" it formerly, and misleadingly,
returned. Passing the return to the QTimeZone constructor now
consistently produces the same as calling QTimeZone::systemTimeZone(),
whose id() now matches the return from QTimeZone::systemTimeZoneId().
This is independent of whether QTimeZone::systemTimeZone() is valid.
Change-Id: I55bbe3ea407ca38343a09da353d9336708747bf1
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
It's very hard to test on Android otherwise: Creator isn't cooperating
well enough with Android Studio / SDK manager with where stuff is
installed, qmake doesn't build an apk, and qt-cmake-standalone-test
doesn't work wth Android either.
Renamed the executable to tablet_device_info so it's a bit less
confusing on device launcher UIs.
Task-number: QTBUG-86297
Change-Id: I3bb7f816e43f8df4183be1c0866e228befa9e8d9
Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io>
Windows are not always fullscreen: e.g. the widget gallery example main
window isn't maximized, and a popup window may open anywhere on the
screen. So we always needed to offset by the window position. But it's
better to use QPlatformWindow::mapFromGlobal() since we are working with
native coordinates here.
Pick-to: 6.2 6.5 6.6
Fixes: QTBUG-109025
Change-Id: Id3d139fad610bbbc67a394599570a309196ae64c
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
The factory cache registration functionality should belong to the
cppwinrt feature, so guard it with appropriate QT_FEATURE_ guard.
Change-Id: Icbadaa7ffb32a4e47fe3bbab90c37303fd787344
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Previously, windeployqt would recurse into subdirectories when copying
QML modules, even if those subdirectories were a nested QML module that
was not needed for deployment.
Since most QML modules are nested in the QtQuick and QtQml modules, the
old code effectively always copied *all* QML modules.
This patch adds guards that prevent recursing into subdirectories if
those subdirectories represent QML modules.
These nested modules will still be deployed, but only if referenced from
the QML application (as determined by qmlimportscanner).
Fixes: QTBUG-117459
Pick-to: 6.6
Change-Id: I4c0dfc15956ff40a0e8caec3fa334df10cc92ccd
Reviewed-by: Timothée Keller <timothee.keller@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The ACTION_POINTER_UP is used when a non-primary pointer (touch, mouse
stylus, eraser) goes up. Without handling this action in these
cases, the table event remains in 'down' state (misses the
QEvent::TabletRelease) and as a consequence when it is next put on the
screen, eg. a line will be drawn to the new position (in case of a drawing
application).
In addition use getActionMasked() to get the action; non-masked
events would contain the index of the pointer too, and wouldn't
match with ACTION_POINTER_UP whose numeric value is 6. Rather the
actions would be in the lines of:
261, // ACTION_POINTER_DOWN(1), 6 with getActionMasked()
517, // ACTION_POINTER_DOWN(2), 6 with getActionMasked()
And so on.
Pick-to: 6.6 6.5
Fixes: QTBUG-86297
Change-Id: I1b50ca4d19b611aec8a5c280ed0521e2f11797b0
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
This reverts commit 530d092eae.
Reason for revert: Moving transient children as a whole is too broad, and forces unrelated windows to have their position completely dependent on a transient parent.
Fixes: QTBUG-117779
Pick-to: 6.6 6.5
Change-Id: I01312e26e95c8144c392eca33aec41f54aaa40b0
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
We don't use va_list and don't have variadic functions in this file.
[ChangeLog][Potentially Source-Incompatible Changes] The header
qbytearray.h no longer includes the header stdarg.h.
Change-Id: I8f3ce163ccc5408cac39fffd178c7fb49d12b739
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
The local qreal to string conversion would fail and produce
unsyntactic output if the integer part exceeded the range of an
unsigned int. Introduce check for that, and fall back to just output a
0 value instead in such cases.
Testing indicates that there is no point in supporting values beyond
4G, as pdf readers do not seem to accept higher values anyway.
As a driveby, also extend the check to catch all non-finite real
values, not only nan.
As a second driveby, simplify the splitting of a qreal into integer
and fraction parts by just using the std library function for that.
Fixes: QTBUG-117740
Pick-to: 6.6 6.5
Change-Id: I247b0612bd565fb2e6f47a182e74f19b8bb0d683
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
.data() in both classes has a null pointer check so it will return non-
null even if the object is storing a null pointer, for compatibility
with Qt 5 (controlled by QT5_NULL_STRINGS). We don't need this in
first()/last()/sliced()/chopped(), so we can skip the test and pass
whatever pointer it is directly to the class constructor. Both of them
handle null pointers creating an isNull() object.
This is a minor performance optimization and interestingly makes these
functions now retain isNull() with the result. I'm not adding test for
that as I don't want to hardcode that they will do so.
Change-Id: Ifeb6206a9fa04424964bfffd17888d14ec8244ec
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The palette mapping table (as read from gtk widget) maintained in
QGtk3Storage misses information of QPalette::Button and
QPalette::ButtonText role for QPalette::Disabled color group. This
cause disabled button widget to be rendered with incorrect palette
(such as in dark color scheme, light palette had been used).
This patch fixes this issue by extending palette mapping in
QGtk3Storage for disabled color group of button role.
Fixes: QTBUG-113486
Pick-to: 6.6.0 6.6 6.5
Change-Id: Ied4b2650c92cc1cda58be69257945991013b276f
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Remove or replace links to examples that were removed or moved under
manual tests.
Replace code snippets that were quoting the now-missing examples.
Fix documentation of QSet::removeIf().
Fix typo in documentation macro: Unknown command '\examplecateogry'.
Add qtopengl, qtshadertools dependencies to Qt Widgets documentation
project to enable correct linking to those topics.
Mark all documentation sets in qtbase as free of warnings.
Pick-to: 6.6 6.5
Change-Id: I058cd5f2063aa933ea310bceff906f05422a7cb2
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
Mention the modules using it instead of claiming it is not used
in Qt.
Pick-to: 6.6 6.5
Change-Id: I8c9490dfd89444509961c73eeff2f8584e0c5df4
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
Include moc must be outside the namespace.
Pick-to: 6.6 6.5
Change-Id: Ibdd539b5fdd8ab4aeb0019bcbb62d5702c310065
Reviewed-by: Antti Määttä <antti.maatta@qt.io>
Since it hides QFile's overloads this was not supported for
QTemporaryFile.
[ChangeLog][QtCore][QTemporaryFile] Added support for passing
std::filesystem::path to rename and createNativeFile.
Change-Id: I909ff1d5b9c586824c9901d7dad278dfad09ffc3
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Destructing the QWindowsScreenManager might result in a
WM_DISPLAYCHANGE, at which point our QWindowsContext instance
is likely gone. We need to guard against that.
Fixes: QTBUG-117473
Pick-to: 6.6 6.5
Change-Id: If32941c5c11231f7c27e9dde54f4315f18da1100
Reviewed-by: Wladimir Leuschner <wladimir.leuschner@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Timothée Keller <timothee.keller@qt.io>
We were already doing this for a key combination without modifiers,
but now we do the same for e.g. Control+Unknown. This matches the
behavior we have for QKeySequencePrivate::decodeString(), where
we return Qt::Key_Unknown if we can't resolve the key, even if
we have resolved some valid modifiers, e.g. "Meta+Trolls" as in
the tst_QKeySequence::parseString() test.
Change-Id: I238e29276e6ce356ae60c67585739587fa388f07
Reviewed-by: Liang Qi <liang.qi@qt.io>
Being explicit about whether we're dealing with QKeyCombination or
a plain Qt::Key helps understand the code.
Keys are still stored as ints though.
Change-Id: I2cb7bf2c5fabcecbd4dd3e99ba6240fb1910dcc7
Reviewed-by: Liang Qi <liang.qi@qt.io>
The functionality is available in QKeySequencepPrivate still, if needed.
Change-Id: Iefa2e5b31a550fd2a419d2aee028ce4c1ddfb7a2
Reviewed-by: Liang Qi <liang.qi@qt.io>
