The QFontMetrics documentation has been wrongly stating that the
the horizontalAdvance() gives the width of a string, dating back
to when the function was misnamed as width(). This can cause issues
e.g. when using the value as input to eliding or clipping, since the
advance may be smaller than what is actually drawn.
This tries to clarify the term a bit.
Task-number: QTBUG-90036
Change-Id: I8ed82fa14fe26c2a20cdbee9f2097a0aa4cc3925
Reviewed-by: Lars Knoll <lars@knoll.priv.no>
This spams the console with "writeStackCookie"/"checkStackCookie"
messages, which makes finding relevant debug output harder.
Pick-to: 6.4
Change-Id: I352b633f02f9ecc1333d1d91f5ffc21a4a937e53
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Mikołaj Boc <Mikolaj.Boc@qt.io>
The screen geometry can not affect the logical DPI of the screen,
Change-Id: Id71b72ed2f26d0371ea7c2d2951426d2616dafd1
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The function updates the cached QScreen geometry; rename
it to updateGeometry().
Change-Id: I56077807baa6c515769017dbb842eed10b1d1357
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Having the logic in QPlatformScreen was inconsistent with how the
high-DPI scaling logic sits on top of the platform layer, and also
made the implementation of QScreenPrivate::updateHighDpi() a bit
inconsistent in how the geometry vs available geometry was resolved.
Change-Id: I683ab34dfc8579e2c887cb8fe3059c9c9fdb71a7
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
... and in turn remove the manual Q_UNLIKELY() leading to its callers.
Paths to Q_DECL_COLD_FUNCTIONs are implicitly [[unlikely]].
This is in preparation of changes where the extra Q_UNLIKELY markup
gets in the way.
Pick-to: 6.4 6.3 6.2
Task-number: QTBUG-104972
Change-Id: I2cba5103854bf356ed841e1957a5ef143f8d3823
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Make it easier to reason about the flow of high-DPI scaling when the
implementation is not "hidden" away in a private header.
Change-Id: I6350798c43ead213323f8e01d9761f2d185c6b00
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Using [NSAutoreleasePool showPools] to debug auto release pools
should now show the call site that allocated QMacAutoReleasePool,
instead of the QMacAutoReleasePool constructor, i.e.:
################ POOL 0x7f844c80c050
0x600003644190 ^-- allocated in function: QCoreApplicationPrivate::init()
0x600003a41080 __NSArrayM
0x60000345cca0 __NSCFString
0x600003a410e0 NSPathStore2
0x600002141680 NSPathStore2
0x6000036441b0 __NSSingleObjectArrayI
Change-Id: I52d22503c1d3de5a9dbae9939569d0836cc1a840
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
popup() is generally better but it has a certain advantage that it does
not require a run loop to work, therefore platforms (like WASM) can use
it without resorting to extra measures (like asyncify).
Task-id: QTBUG-106389
Backport-to: 6.4 6.4.0
Change-Id: I87bde677f84048af82cc9aadd982284bdba41e69
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The context menu event created in QWidgetWindow::handleMouseEvent
does not forward its acceptance flag on which a client may rely.
Task-number: QTBUG-106389
Backport-to: 6.4 6.4.0
Change-Id: I17a53ebd23b4ae0a2721c629f3ecc7aeec56233d
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Avoid adding module header files to a PUBLIC/PRIVATE_HEADER for the
modules. All header files are installed using install(FILES call, but
not as a part of install(TARGET
Amends 8539e641f6
Task-number: QTBUG-103196
Change-Id: Ib95295112c74f74f237e3738d2532f9049d26ce6
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
If Qt itself is built without the deprecated APIs, so should be the
tools and apps.
This patch makes sure that the specified QT_DISABLE_DEPRECATED_UP_TO
and QT_WARN_DEPRECATED_UP_TO values are correctly used in the internal
tools and apps.
Fixes: QTBUG-105102
Change-Id: I7a51bddbd839c7b71efa0bff8ec959df64c53b82
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The indentation is only required for C++.
Pick-to: 6.4 6.3 6.2
Change-Id: Ie861b12ba262fd56995c11d883129bafd11eface
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
When a QDateTime is constructed it determines whether daylight-saving
time is in effect and records it in its status field. So consult that
cached answer first, before asking the time-zone backend to work out
the answer the slow way.
Change-Id: I1d380d41f28a9b866216ac0f65425c30a8988cac
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
They are no longer needed. The global static will only ever be
instantiated if and when the QSystemLocale stack is empty; it will
then survive to the end of run-time, serving as a bottom-of-stack
instance that will always be fallen back to after any other instances'
lifetimes. It can thus be a local static of the only function that
accesses it.
Change-Id: I21a1623728b25b46da6e25db9bb973c507a39ca3
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
The collection of translations available to us need not have anything
to do with whether CLDR has matching data, so preserve the system UI
language list's entries as they are, rather than forcing them through
the QLocale constructor's exercise of likely sub-tag rules.
Instead, simply parse the given locale tags to QLocaleId instances and
use these in the likely-subtag processing to determine what other
entries to add to the list in addition to those supplied by the
operating system. Since going via QLocale did usually supply a
territory, that was included in the BCP 47 name, it's now possible for
the given entry to lack the language_territory name, so be sure to add
that if missing.
This incidentally reduces heap traffic and saves a fair deal of hidden
likely-subtag processing in calls to the constructor and bcp47Name().
Expand testing of QLocale::uiLanguages(), both plain and system. In
the process, cross-link the two closely-related tests, move a comment
on one's _data() to the other's, where it really belongs, and add
reporting of the actual lists on failure. Enable MySystemLocale to
remember the requested locale's ID, before likely sub-tag processing,
so that we can make query() report results for language, script and
territory as requested, to ensure the fake system locale really does
match what was requested. The new german-britain test failed without
it, because there is no de-GB locale in CLDR.
Task-number: QTBUG-99531
Change-Id: Ide041577772c442a4413e3b9a590e11140c48f49
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Have QSystemLocale manage a stack, so that tests can install an
over-ride for the actual system-specific one reliably and restore the
system-specific one when finished. Leave the QSystemLocaleSingleton
out of the stack, all the same. In the process, mark the QDoc comments
for QSystemLocale all as \internal, since this is not public API.
Change-Id: I8faed49780215e42f32be10cf936c32bb46105bf
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
When the system locale is en_DE, macOS seems to think we should use
en_GB as the right translation. While that probably is a sensible
choice in the absence of an en_DE translation, we should definitely
use the en_DE translation if available, especially if en_GB isn't
available (which lead to a fall-back to de_DE, given later entries in
macOS's list). So prepend the system locale's own pcp47Name() if it
(isn't the C locale and) is missing from what we would otherwise have
used for uiLanguages(), after likely sub-tag perturbations.
Add a test simulating (some approximation to) what macOS was doing
that would have caught this case; and add a scope-guard reporter to
the test to report what shows up when lists don't match.
Fixes: QTBUG-104930
Pick-to: 6.4 6.4.0 6.3 6.2 5.15
Change-Id: I116234708067e1717d9157aebc84da76e04a9f38
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Also follow this best practice in testlib's own documentation and
examples.
Pick-to: 6.4
Change-Id: I8b57dfa8f88835adae8fceeb122a16635708e338
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
In the same file, errno and EACCES are passed unadorned to
qt_error_string(), proving the int casts on the other calls aren't
necessary.
Remove them; ints are a code smell these days.
Pick-to: 6.4 6.3 6.2
Task-number: QTBUG-103525
Change-Id: I7209a209141195090878944ae66da3c85bbe4135
Reviewed-by: Mate Barany <mate.barany@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The debugBinaryString() function is a hexedit-like pretty-printer
which prints in increments of 16 octets, so it can go forever.
The old code had an overload set (QByteArray) and (ptr, qint64 size),
but made the (ptr, n) overload construct a QByteArray to call the QBA
overload. That's a narrowing conversion right there, except it can't
trigger because no machine can hold that much memory. But it may warn.
The code inside went on with further narrowing conversions to int,
this time, which does have an effect on 64-bit. Granted, you'd wait a
long time for this inefficient pretty-printer to write out more than
16Mi lines of hex dump, but it's wrong nonetheless, because narrowing
conversions work with modulo arithmetic and not saturation arithmetic,
so passing a buffer of INT_MAX + 1 size would print nothing, which
would probably cause some time lost hunting unrelated bugs.
So, fix the whole thing as follows:
- remove the QBA overload, it was never called
- loop over the full range of up to LLONG_MAX characters; if
developers pass too much data, that's SEP
- remove the narrowing casts to qsizetype at the call sites (avoids
modulo arithmetic)
As a drive-by, make the function static, and to get compilers to
actually see all this, make it [[maybe_unused]] instead of ifdef'ing
out.
Not picking back, as it's debug-only code.
Task-number: QTBUG-103525
Change-Id: I8b06466365d8c57b14535d8752428a614f244297
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
[ChangeLog][QtCore][QDir] The count() function now returns, and the
indexing operator now takes, qsizetype (was: uint and int,
respectively).
[ChangeLog][Potentially Source-Incompatible Changes][QDir] The count()
function now returns qsizetype (was: uint).
Task-number: QTBUG-103525
Change-Id: Ib84af36f6a95d9a0d1090a2d6fb973a4e363550c
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Certain masks are not supported outside 32-bit x86, and will assert on
x64.
Pick-to: 6.2 6.3 6.4
Fixes: QTBUG-106000
Change-Id: Ic9f58e5a19c1db3309edeb5ec529e7a78c929665
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Add an atomic state variable to perform early return without taking
a recursive lock after ensureCiphersAndCertsLoaded() is complete.
Make related mutex and state variable function-local static because
they are not used anywhere else.
Taks-number: QTBUG-103559
Change-Id: I1e4c9c4f73204885bce82ba7f2b5e64548c3aac3
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
This reverts commit 756c65d367.
"justified_worry" is an incorrect workaround which attempted to silence
tracegen when invalid types were being used. This caused Qt to compile,
but with broken/invalid tracepoints.
The proper solution involves fixing the tracepoints in question.
Change-Id: I96de254944f0367808527d215e87a5d66bb442f4
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Use CMake source tree when installing header files instead installing
all header files that syncqt.pl produces. This avoid adding header
files which cannot be used because of platform or feature
incompatibility with Qt version. Since syncqt.pl doesn't respect CMake
build tree when generating master header and CaMeL case header files,
these header files still will be installed regardless platform or
feature limitations. This will not be the case once we switch to
syncqt.cpp, which will install only headers that are relevant to the
selected platform and enabled features.
Task-number: QTBUG-103196
Change-Id: I7d64754648747bee700d96f2fd6228fe7248512e
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Zlib uses ulong in the interface, which, at least on Windows, is a
32-bit type, so qCompress cannot consume input and qUncompress cannot
produce output greater than ULONG_MAX, even on 64-bit platforms.
Document this limitation.
Pick-to: 6.4 6.3 6.2
Task-number: QTBUG-104972
Change-Id: I56c926a67f8705ef773977a86e157e6eb26aa585
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
... because the limit we check against, doubled, is still within the
range of size_t.
Took me a while to prove this to myself, so document the finding in a
static assertion.
Pick-to: 6.4 6.3 6.2
Change-Id: Ib2d1bb825c1693ccc4ffa1d8fc0bd455a170337f
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
These cause Coin to spawn VM for setting one env variable.
Change-Id: I3ef87092107394b1d985e7549c3d3ca7dc509156
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The deviceIndependentSize() function of QImage and QPixmap was added
in Qt 6.2 but their docs are missing this information, so add them.
And it seems the QImage docs were copied from QPixmap, so it still
reference to pixmap, not image, fix it as a drive-by.
Pick-to: 6.4 6.3 6.2
Change-Id: Ic3d0a2019b5e9b89bd8723d994d7ae54f2cb5257
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
We only want to enable writing BOM if we have _not_ started
writing.
Fixes: QTBUG-106279
Pick-to: 6.2 6.3.2 6.4 6.4.0
Change-Id: Ibcbc101b931615fddb2507f01307bf9619772d7b
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
In f082458c46 a fix attempt was made
and in a lucky example on Mac it worked well. However, the logic was
still not correct and that could be seen in other systems/examples.
This patch updates the logic to be the correct behavior in
general.
Pick-to: 6.4 6.3 6.2 5.15 6.4.0
Fixes: QTBUG-106064
Change-Id: I3b098be9942d37c367b146a7359185bcfd127762
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The qt_deprecates pragma indicates that the file passed as argument
is deprecated and supposed to be replaced by the file where the pragma
is defined. Syncqt procedure generates the file passed as argument
automatically with the deprecation warning. After the deprecation
period the pragma should be removed and the deprecated file will not
be included to the Qt installation too.
The pragma is only handled by the cpp version of syncqt cpp and
supposed to replace the 'deprecatedheaders' record in sync.profiles.
Change-Id: Ibe69423a5de67f58907a3edbc5961f5ab63944de
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
I noticed that the QtCore version file had several entries for
13QObjectPrivate, which turns out to be for all the nested structs
inside. That's not harmful for QObjectPrivate, since that is itself a
private, but would be a problem for a nested struct of a public class.
I'm sure those exist.
Pick-to: 6.4
Change-Id: Ic6547f8247454b47baa8fffd170ea79360aaa615
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Unexported structs do mark private API too. This change necessitated fixing
the negative-lookahead, because otherwise we'd match a line like:
class QVariant;
With $1 = "QVarian" and the "t" stood for the negative lookahead.
Pick-to: 6.4
Change-Id: Ic6547f8247454b47baa8fffd170bba2c68c29dbc
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
If Qt itself is built without the deprecated APIs, but the tests are
not, tests will fail to compile and/or link.
This patch makes sure that the specified QT_DISABLE_DEPRECATED_UP_TO
and QT_WARN_DEPRECATED_UP_TO values are correctly used in the tests.
The definitions are propagated to tests, batched tests, manual tests
and benchmarks.
Fixes: QTBUG-104858
Change-Id: Idf15accaf96c47599084426ba625b985f507ca8b
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
It's good to use a pre-allocated set of points that never changes,
because queryPointById() returns a pointer to the stored instance.
If the flatmap's values are in a QList, and a mouse event comes in at
the wrong time while touchpoints are already stored there, causing
the QList to be resized, the returned pointer can become garbage.
The pointer returned from queryPointById() is never retained for long,
but in practice it turned out this could still happen, at least on X11
(perhaps because of X11 synthesizing mouse events from touch).
Using a pre-allocated QVarLengthFlatMap is also an optimization: events
on single-user systems are unlikely to ever cause memory allocation in
this part of the code.
Many touchscreens support up to 10 touchpoints, but the user might
have some other input devices, plus the "core pointer" (mouse).
The user could also have two touchscreens and try to use them
simultaneously.
d4611ba3a5 added QVarLengthFlatMap along
with a test using int keys; so we expect that will keep working now.
There was some issue in 2020 which is why I didn't use QVarLengthArray
for the QFlatMap key and value containers to begin with.
Pick-to: 6.2 6.3 6.4 6.4.0
Fixes: QTBUG-106223
Change-Id: I588f66f07126b9551937a369df44f045759b473d
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Replace the deprecated operator*() calls with various
overloads of QMatrix4x4::map()
Add a separate test for deprecated API and guard it with
QT_DEPRECATED_SINCE checks.
Task-number: QTBUG-104858
Change-Id: Ief2e03198696382dc626f01b209614fe320e70b2
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Not clearing the target time makes the subsequently created timers not
get their time ticks, as no actual timeout will be registered as the
dispatcher wrongly assumes there will be a tick fired, which there isn't.
Since there are no updates, the WASM compositor enters an infinite
window update loop where it requests an update on a window, and the
window requests an update on it, getting the update request back due to
an animation running forever.
Pick-to: 6.4 6.4.0
Fixes: QTBUG-105347
Fixes: QTBUG-102004
Fixes: QTBUG-104518
Fixes: QTBUG-106153
Change-Id: I14b8dd08df81852e28e8527545c8530e0656990d
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Previously _qt_internal_collect_apk_dependencies() only collected
targets that were built by the current project and informed
androiddeployqt their directory paths for deployment consideration.
The libraries would be bundled into the apk based on whether
the application links to any of those libraries directly,
e.g. via target_link_libraries.
CMake 3.21 added a new feature that allows us to query all IMPORTED
targets in a directory scope. Using this information we can now tell
androiddeployqt about these libraries as well, of course only when a
new enough CMake version is used. Introduce
_qt_internal_collect_apk_imported_dependencies_defer to do that.
In contrast to _qt_internal_collect_apk_dependencies(), the IMPORTED
libraries are collected by recursively looking at a target's directory
scope and its parent directories, rather than child subdirectories.
Also, the collection / deferral is done when the target's directory
scope has finished processing, rather than when the root project
has finished processing.
Why? IMPORTED libraries are usually non-global, which means we can't
refer to them in parent scopes using functions like
get_target_property, the targets don't exist in those scopes.
Note that the code only covers IMPORTED target libraries. It
does not cover INTERFACE libraries, plain library names or
file paths specified in target_link_libraries.
It also doesn't account for loadable libraries (dlopen()ed ones).
In such cases, projects still need to manually specify the library
paths in the executable's QT_ANDROID_EXTRA_LIBS target property.
To prevent the deployment json file from being extra long when
looking for IMPORTED libraries, filter out paths to Qt modules or
plugins by checking for the _qt_package_version property.
These are handled via a different code path in anddroiddeployqt,
so there's no reason to duplicate the information.
Added documentation for how to opt out of this new behavior.
Amends d20f4ae706
[ChangeLog][CMake][Android] Imported targets are now considered
during Android deployment when using CMake 3.21+.
Fixes: QTBUG-94714
Fixes: QTBUG-105165
Change-Id: I9f01cdc4e63004e4768027e412899e441e72bf04
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
