Required for porting away from QLatin1Char/QLatin1String in scope of
QTBUG-98434.
As a drive-by, fix qsizetype -> int narrowing conversion warnings for
the touched lines.
Change-Id: I121f87214b77aeab1dfd3e62dc5adaa6255cc0e0
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
If the user supplied a content-length, and we also know the size of the payload
then we would set the content-length again, which is a remove + add on a QList.
This is completely avoidable if we are setting the same size anyway.
Fixes: QTBUG-102495
Change-Id: If62739cadb453dbda4c21e858ba3a17baaf71fb4
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
A loop variable could just as well be declared in the loop.
The startPos variable sits more naturally just before its first use
than where the removal of the loop variable's declaration left it
isolated.
Change-Id: I4754b9dfe4b142e5a183a0d9555c9d3237bc6bbd
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Since 5.6.0, Qt's serialization of QDateTime in QSettings files has
had special-case handling to use a newer QDataStream version than the
one QSettings uses for most other types. This was handled in the
serialization and parsing, but not taken into account in the code that
turned binary data into content suitable for saving to an ini file.
In Qt 5 this caused no problem when no iniCodec was set on the
QSettings object but Qt 6 now uses UTF-8 as (in effect) codec on every
QSettings object. This lead to the binary data encoding QDateTime
being encoded as if it were Unicode, instead of using \x tokens where
suitable. This lead to an unintended incompatible change in how
QSettings stores QDateTime values: Qt 6 was still able to read Qt 5's
values, but Qt 5 was unable to read Qt 6's settings files (unless it
sets its iniCodec to UTF-8, which works round the problem).
The code to convert raw binary data to ini-file-friendly value texts
had a special case for ByteArray and Variant values, to ignore the
codec and use \x tokens: when support for QDateTime was split from
Variant, it gained a DateTime prefix in the parsing code that wasn't
included in this special handling. So add that now.
The resulting DateTime values now match Qt 5 so are readable by it and
by Qt 6 (including versions prior to this change); and the code to
read a DateTime can still read what earlier Qt 6 versions have been
writing. It is likely a Qt 5 QSettings with an iniCodec other than
UTF-8 may have problems with the result, but that was already true.
This amends commit 73b8cd879c
Fixes: QTBUG-102334
Pick-to: 6.2 6.3 5.15
Change-Id: Icc44a33db3dcc6400144bc001710b400ee883c90
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
When composition is activate and the user switches from one window to
another we get callbacks that the original window resigned key and the
new window became key, which gets propagated as window activation
events.
QGuiApplication reacts to this by sending a QEvent::FocusAboutToChange
event to the window that lost activation, which QWidgetWindow then
responds to by committing the current input method.
Unfortunately, at the time we get the key window callbacks from AppKit
the keyWindow of NSApplication has already changed, so technically the
QEvent::FocusAboutToChange event is too late and not in sync with the
system state, manifesting in a bug in the input context and Text
Services Manager (TSM) subsystem on macOS.
In response to the commit of the input context we unmark (accept) the
current composition, and then tell the NSTextInputContext of the focus
view about this fact by calling discardMarkedText on it. But since the
NSApp.keyWindow has already changed at this point, the focus view's
input context is no longer the NSTextInputContext.currentInputContext,
and as a result discardMarkedText will activate and deactivate the TSM
document to ensure the right TSM document's marked text is discarded.
This leaves things in an inconsistent state, as the current input
context document, which was activated when the key window changed,
is no longer active.
We can work around this by manually calling activate on the original
NSTextInputContext.currentInputContext. The documentation notes that
this API should not be called directly, but unfortunately there are no
other call sites in AppKit that end up in ActivateTSMDocument.
A longer term fix would be to add plumbing to QWSI and QGuiApplication
to allow notifying the application about the upcoming window activation
before it happens, so that the FocusAboutToChange event and corresponding
commit comes in at the right time (before the current input context has
changed).
Fixes: QTBUG-102083
Fixes: QTBUG-101278
Pick-to: 6.2 6.3
Change-Id: I8d369d1ca87cbb74a168ff3082bd0ab58eb391c5
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
This patch amends a374d59abc.
That commit introduced refactoring of A11Y object description
announcements that also took a value into account.
However for the elements without values (like QPushButton), an unused
space is added at the end of the description.
This patch fixes the issue by explicitly checking that the value
interface exists and that the value string is not empty.
Fixes: QTBUG-102744
Pick-to: 6.3 6.2 5.15
Change-Id: Ic1ba50859fb91c871c242189967dcce35723a0b2
Reviewed-by: Andreas Buhr <andreas.buhr@qt.io>
Added QFuture::unwrap() for unwrapping the future nested inside
QFuture<QFuture<T>>. QTBUG-86725 suggests doing the unwrapping
automatically inside .then(), but this will change the return type
of .then() that used to return QFuture<QFuture<T>> and might cause
SC breaks. Apart from that, QFuture::unwrap() might be helpful in
general, for asynchronous computations that return a nested QFuture.
[ChangeLog][QtCore][QFuture] Added QFuture::unwrap() for unwrapping the
future nested inside QFuture<QFuture<T>>.
Task-number: QTBUG-86725
Change-Id: I8886743aca261dca46f62d9dfcaead4a141d3dc4
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Instead of having Q_UNUSED and QSKIP in the test itself, we just skip in
the _data function.
Change-Id: I9da3d3104ec25e2645e5770e6392bd46958da072
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
The work done by QGuiApplicationPrivate in response to a theme change
goes beyond notifying.
Change-Id: I27c74adf6549c553e659c7b8e271945ce753031c
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Problem: if you create a hybrid Widgets and Quick Controls
application, you would need to use QApplication rather than
QGuiApplication. But in that case, the QQuickWindows would
never receive window activation events from QApplication.
And this causes problems for controls, since, for example,
the palettes in use there will never update upon activation
changes, and instead sometimes get stuck as e.g QPalette::Inactive
after application startup.
This patch will make sure that we send out activation events
also for QWindows that are not QWidgetWindows.
Pick-to: 6.3 6.2
Change-Id: I649f5c653081c0c5249f4faf28a7de2c92f17421
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Turns out there is a fillModeNonSolid in VkPhysicalDeviceFeatures,
so to be true to the spec we need to enable that when setting the
polygonMode in a QRhiGraphicsPipeline to something other than the
default Fill. This way the validation layer won't bark at us.
Change-Id: I41f561a1796ba1d45229dc20bf1fb7bae3c43f48
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
When QT_USE_BOOTSTRAP_SOURCE_COPY is ON, there are situations where
includes like
"../../3rdparty/sha1/sha1.cpp"
in qcryptographichash.cpp cannot be resolved. For example,
out-of-source MSVC builds are affected.
In-source builds are working by accident, because we're adding the
include path "<qtbase-build-dir>/src/corelib/global", and
<qtbase-build-dir> is <qtbase-source-dir>.
Linux/macOS builds are working by accident, because we're adding the
include path "<qtbase-source-dir>/src/3rdparty/forkfd".
Fix this by explicitly adding the directory where qcryptographichash.cpp
resides to INCLUDE_DIRECTORIES.
This amends commit 743bb66744.
Fixes: QTBUG-102720
Change-Id: I55fcc186ea4c81134c39023ced3f04458230109b
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
New upstream release.
[ChangeLog][Third-Party Code] PCRE2 has been updated to 10.40.
Pick-to: 5.15 6.2 6.3
Change-Id: Ice0516604259ad9fd36fe2708aa0239aafe381ca
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Move shellquote helper functions into a common place instead of having a
copy in each tool's code.
Change-Id: I9723c11f894a211864788a7635773610c0fde739
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Instead of having to do that each time for multiple paths, a common
helper function is better.
Change-Id: Ice2499f390a5790c5768eca037d186ad2e656ec7
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
The "android" tool is deprecated and never used now, and this function
is not called by anything either.
Change-Id: I6fdb09934c93f5bc03610bcc4fd677f8bb2d4189
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
The file is going to be remove anyways in the next build, so just delete
it once we're done with it, this also makes the build folder doesn't
have files that are not needed.
Pick-to: 6.2 6.3 5.15
Change-Id: I948f028e9151b38a3ccc1ec628239ac91397e0d0
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Tag passed to __android_log_print shouldn't contain spaces because
filter-spec used by adb logcat expects space-separeate list of
tag:priority specifiers. Effectively, its not possible to filter tag
using logcat if Qt's application name has spaces.
Pick-to: 6.2 6.3
Change-Id: I52b706b7a368d0700db45c0406bbfef279bc61fb
Reviewed-by: BogDan Vatra <bogdan@kdab.com>
Not every id is an NSObject, and even those that are are sometimes
passed around as id<SomeProtocol>, in which case we still want them
to have pretty debug descriptions.
Change-Id: I50a02cd8fb9d6a2cbde3c4aef81116033d10b72c
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The change
0ec75f4b99
missed adding specialHTMLTargets for qmake
Also add warning to keep QtWasmHelpers in sync with qmake.conf
Change-Id: Idb363e77f0cecb4f125d3cb4f7507899149a3bac
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
We were requesting to activate the window too soon, when the window was
still in the initial size of 600x600, in which case, the paint event was
not getting called. This would require the user to have to click the
window in order to see it.
Removal of this does not seem to effect showing of tooltips, which it
was added initially.
Change-Id: I3efa86be99a3d9e1d9eda87b7537fff1e96e6774
Fixes: QTBUG-102005
Pick-to: 6.3
Reviewed-by: Aleksandr Reviakin <aleksandr.reviakin@qt.io>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Reviewed-by: David Skoland <david.skoland@qt.io>
Some netWmState needs to be set during unmap/hide(), which is too
difficult to follow, and causes m_mapped status out of sync very easily
sometimes, which we had tried in
e946e6895a .
Destroy the xcb window and recreate new could make the thing
much easier. This practice is also used in other platforms, such
as cocoa plugin.
In Qt 4, the platform window was destoryed and re-created in this
situation on all platforms, which was not ported into Qt5.
See also the code between setWinId(0) and createWinId() in
QWidgetPrivate::setParent_sys() in qwidget_x11.cpp/qwidget_win.cpp/
qwidget_mac.mm.
Fixes: QTBUG-69515
Fixes: QTBUG-73485
Fixes: QTBUG-81341
Pick-to: 6.3 6.2 5.15
Change-Id: If55c57a198bc785719b61b8748dabd8281c9639d
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
This reverts commit e946e6895a.
It clears the duplicate show() and hide() too aggressive in
handleDeferredTasks() and can cause visible states out of sync between
qt and system(x11) when user switches visible on and off very
frequently.
This change also reverts 28138aa80a.
Fixes: QTBUG-101347
Fixes: QTBUG-99810
Task-number: QTBUG-69515
Pick-to: 6.2 6.3 5.15
Change-Id: I419c324634be8ee6884e02032bb53a42738305ac
Reviewed-by: Liang Qi <liang.qi@qt.io>
Required for porting away from QLatin1Char/QLatin1String in scope of
QTBUG-98434.
As a drive-by, fix qsizetype -> int narrowing conversion warnings for
the touched lines.
Change-Id: I03477e645a94948cac3e3e2abca52aa4e3e2efff
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Required for porting away from QLatin1Char/QLatin1String in scope of
QTBUG-98434.
Change-Id: Ia186ed178239796bdf19db5b35a36ea606baf937
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Describe enum usage in QDockWidget::isAreaAllowed() as well as meaning
of enum members.
Pick-to: 6.3 6.2 5.15
Change-Id: Ib88509feb001be27c11fd167c9009da50ce1b851
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Check DockWidgetArea permissions of QDockWidgetGroupWindows with single
dock widget. Obtain a dock widget's tab position from a dock widget
group window if it can't be established otherwise. Remove hardcoded
assumption that a dock widget is in the left dock. Both cases have lead
to inconsistent entries and dangling pointers in
QDockAreaLayoutInfo::item_list.
Remove warning: QMainWindowLayout::tabPosition called with out-of-bounds
value '0', which becomes obsolete by the fix.
Create a QDockWidgetGroup window prepered to become a floating tab,
whenever a dock widget is being hovered over. Store it in item_list so
it can be found and deleted when required.
No longer call e->ignore() after propagating close events to the first
dock widget and thus preventing others from receiving the event.
Add logging category qt.widgets.dockwidgets
Update dock widget autotest with tests to check the fixes mentioned:
plugging, unplugging, hiding, showing, closing and deleting.
Blackist closeAndDelete, floatingTabs test on macos, QEMU, arm, android
due to flaky isFloating() response after a dock widget has been closed
or plugged.
QSKIP dockPermissions and floatingTabs test on Windows due to mouse
simulation malfunction.
QSKIP hideAndShow test on Linux in case of xcb error (QTBUG-82059)
Fixes: QTBUG-99136
Pick-to: 6.3 6.2
Change-Id: Ibd353e0acc9831a0d67c9f682429ab46b94bdbb0
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
There should be no need for CMake to add rpaths pointing to
directories outside of the build tree to the installed libraries.
All relevant install rpaths are handled by qt_apply_rpaths().
Change-Id: If554b1e3c790c2bb04a34e8b0524aab3febf5afc
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
There were a few things that were not ported correctly.
Make sure to disable rpath manipulation if the rpath feature is
disabled.
Fix if(IS_ABSOLUTE) conditions to actually take values.
Don't embed bogus relative rpaths if the platform does not support
it. QNX is such a platform, it does not support $ORIGIN (at least from
my scouring of QNX documentation and manual testing via QEMU).
Handle the extra rpath case where they are relative, but the platform
does not support relative rpaths, by transforming them into absolute
ones.
Amends 67ee92f4d8
Change-Id: I04168633ec51b3cc5d580b738a7dc280fe6e0d2d
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Previously if
-extprefix /tmp/sysroot (CMAKE_STAGING_PREFIX)
-developer-build (FEATURE_developer_build)
were specified, but
-prefix (CMAKE_INSTALL_PREFIX)
was not,
the build system would set the CMAKE_INSTALL_PREFIX to the
qtbase build dir.
Then, if targeting desktop, this would be considered a non-prefix
build (ninja install would refuse to work), whereas in a cross-build
it would be considered an installable build.
In both cases though, the rpath of installed binaries would point to
the qtbase build dir (because CMAKE_INSTALL_PREFIX would be set to the
qtbase build dir).
This is quite confusing behavior, in more than one way.
Change the build system to consider that an explicit -extprefix should
cause Qt to always be installed, even if -developer-build is
specified.
This means the installed rpaths and on-device install prefix
(CMAKE_INSTALL_PREFIX) will now use the default computed install
prefix, e.g. /usr/local/Qt
It also means that to get a non-installable developer + custom staging
and install (on-device) prefix build, users will have to be explicit
and set all the options
-extprefix ~/qt/qtbase_build_dir
-prefix /usr
-developer-build
Pick-to: 6.2 6.3
Change-Id: Ib560452a4b4778860e0fd7666c76f8a6745773ee
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Allow such a combination
- staging prefix (CMAKE_STAGING_PREFIX / -extprefix) set to the
qtbase build dir
- install prefix (CMAKE_INSTALL_PREFIX / -prefix / on-device prefix) set
to some custom location
even for non-cross builds.
An example would be
configure -prefix /usr \
-extprefix ~/qt/qtbase_build_dir
CMake will put the Qt libraries in the qtbase build dir, ninja install
will not be required, but ultimately in order to run applications,
the Qt libraries are expected to be in /usr.
Support for this scenario was originally added for cross-builds in
062318feb2 , but not desktop builds.
Such a build is useful when you want to have install rpaths different
from where Qt is initially installed to (the staging prefix).
This case doesn't really happen often when targeting desktop
platforms, it's mostly used for cross-compilation (e.g yocto).
Being able to have the same setup with a desktop build is nevertheless
useful for faster iteration on build system issues in such a scenario.
Amends 062318feb2
Pick-to: 6.2 6.3
Change-Id: I42be3628a30025f14eebaf0a79401b54e95cde26
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Instead of complicating the condition even more, just use the value of
QT_WILL_INSTALL which is determined in QtSetup before configure.cmake
is loaded.
The AUTODETECT part is needed to ensure that
-developer-build
implies -no-prefix.
The CONDITION part is needed so that
-extprefix /tmp/sysroot -no-prefix
correctly errors out saying that this can't be a non-prefix build,
unless
-extprefix ${qtbase_build_dir} -no-prefix
is passed.
Pick-to: 6.2 6.3
Change-Id: Ie4f5a91281bf2fbe1bd0744de05d57f43fe992e7
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Otherwise we get:
Styles ................................. Basic Fusion Imagine iOS
Material Universal macOS Windows
-- Qt is now configured for building. Just run 'cmake --build .
--parallel'
Pick-to: 6.2 6.3
Change-Id: Ie8d009455e4f45c9eb0557c4a08e9d0a94030c3a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The textual output of otool in recent Xcode releases has changed.
We now look for OBJC_CLASS_RO/OBJC_METACLASS_RO rather than
class_ro_t.
Pick-to: 6.2 6.3 5.15
Change-Id: I86192e91e55d8deb7e5c6790b327855fc0f7e594
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Qt backing store images should have alpha iff that was
requested by the QWindow's surface format. This changes
wasm to be in line with the other platforms, and enables
use of transparency for Qt windows.
Change beginPaint() to clear the backing store only
if the format/image has alpha. This is also established
behavior Qt's backing stores.
Change-Id: Idafe658e24d864f7c4f9e68ee39cb409982b5852
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
Reviewed-by: David Skoland <david.skoland@qt.io>
This should've been done already for Qt 6.2.
Pick-to: 6.2 6.3
Change-Id: I2f943254698a4f0f2742619fd7fcab9ac3a5014a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This is a cherry modification of 5826a7ad92
in 5.15 branch.
Fixes: QTBUG-102438
Pick-to: 6.3 6.2
Change-Id: I8bdb7cb2537c6df7bb1381871b3cc2446ff1d270
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
...and properly find and link against `libatomic` using find_library.
This fixes the qtdeclarative build on the RISC-V platform.
Initial-patch-by: Sprite <SpriteOvO@gmail.com>
Pick-to: 6.2
Pick-to: 6.3
Task-number: QTBUG-99234
Change-Id: I2b5e4812886ce45cb02bed3106ce8c519b294cbe
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
