There is no guarantee that it will return 0 after one call
to sendPostedEvents(), since more events may have been
posted during that call. This can in turn cause infinite
looping since the wait() isn't called.
Move sendPostedEvents to the top of processEvents()
to make sure we send events before waiting, in line
with the implementation for the other event dispatchers.
Pick-to: 6.5 6.6
Fixes: QTBUG-112893
Change-Id: Iba7d87cf1c08cd302884782cb135d758afeb9e4b
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
This patch allows to open databases using QFile. This way it
can open databases from RW locations as android shared storage
or even from RO resources e.g. qrc or android assets.
[ChangeLog][QtSql][SQLite3 driver] QtVFS for SQLite3 allows to open
databases using QFile. This way it can open databases from RW
locations such as android shared storage, or even from read-only
resources e.g. qrc or android assets.
Fixes: QTBUG-107120
Change-Id: I889ad44de966c96105fe1954ee4eda175dd5a886
Reviewed-by: Christian Ehrlicher <ch.ehrlicher@gmx.de>
`QVariant::convert` may lead to crash or produce garbage data when
attempting to convert a gadget between a pointer type and a value type,
for example from a variant holding a QLocale gadget to a QLocale*
pointer and vice versa. Similarly, `QVariant::view` may crash under the
same conditions.
The reason is that conversion is implemented through copy construction
assuming that both source and target types are either both pointers or
both values. If converting from pointer to value type, the result is
crash during destruction of the QVariant. If converting from value to
pointer type, the result is a QVariant holding a pointer to garbage
data (and possibly crash if pointer is dereferenced).
Similarly, if attempting to convert a pointer to a QObject derived type
to its value type, the system crashes, with a slightly different failure
mode. During `QVariant::convert`, a temporary `QVariant` of the target
type is created. Since objects that can not be copy constructed are
invalid for `QVariant`, the temporary is left empty without constructing
the target value. Then, when attempting to convert from a pointer type
to a value type, the temporary's destructor is incorrectly called on the
owned object. Since the owned object is never constructed, this leads to
a crash.
The proposed fix is to return false from `QMetaType::view`,
`QMetaType::canView`, `QMetaType::convert`, and `QMetaType::canConvert`
if the target type is of different 'pointedness' than the source type.
After this fix, converting and viewing gadgets and QObjects behaves the
same way as primitive types and core types, which already returned false
when converting between value type and pointer type.
Fixes: QTBUG-114797
Pick-to: 6.5 6.6
Change-Id: If5ad764a60f2f3c912070198073b28999d995f17
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
because it's flaky in current CI setup.
Task-number: QTBUG-109776
Pick-to: 6.6 6.5
Change-Id: I3e432e632622f47b8125344187daf238a03a7372
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
http is enabled by default if you have threading support, which is true for qdoc. There is therefore no reason to believe that a normal
qdoc configuration won't have it configured, and hence no need to
check also explicitly for Q_QDOC.
Pick-to: 6.6
Change-Id: I118388fedaa87225ce81a211d361d593da61105d
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
Example source code should be LicenseRef-Qt-Commercial OR BSD-3-Clause
Pick-to: 6.5 6.6
Change-Id: Ia9cf6f4783fde0e25f72a31bbe6d809118fd4240
Reviewed-by: James McDonnell <jmcdonnell@blackberry.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The warning has been reported by users, but never observed in CI, even
though the only path that can lead to the last return statement becoming
unreachable is very common in Qt: if a QDebug stream operator exists,
then we always return early.
Nevertheless, rewrite the code to have a single return statement.
Task-number: QTBUG-112371
Fixes: QTBUG-114944
Pick-to: 6.6 6.5
Change-Id: Iaf9ec683ceceedb00771fb0743a09dcc8f50ba3f
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Reviewed-by: Pavel Dubsky <pavel.dubsky@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Jøger Hansegård <joger.hansegard@qt.io>
The default for showsHiddenFiles is NO, so we were not showing hidden
files unless the user toggled them via the keyboard shortcut.
Pick-to: 6.5 6.6
Change-Id: I796144452cf8f5a6cc46f1ba6747affcd0a35879
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
In our NSOpenSavePanelDelegate we respond to panel:shouldEnableURL: by
checking the file dialog's filter options. As part of this, we pulled
out the file's attributes using [NSFileManager attributesOfItemAtPath:],
but this API triggers the TCC (Transparency, Consent, and Control)
machinery to ask the user for permission to access the path in question.
We could replace the directory check with fileExistsAtPath:isDirectory:,
but this would still leave the checks for writable/readable/executable.
Luckily for us, the plumbing for QFileInfo uses lower level CoreFoundation
APIs that don't have these issues (except for isBundle, which we should
fix separately).
This also means we can remove the custom isHiddenFileAtURL helper, as
it was based on the same kCFURLIsHiddenKey as the QFileInfo plumbing.
Fixes: QTBUG-114919
Pick-to: 6.5 6.6
Change-Id: I9ebefaeb1ef7bcc5bb9a1c5cd4b993ce230cf506
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
In our NSOpenSavePanelDelegate we respond to panel:shouldEnableURL:
with YES if it's a directory or symlink to a directory, which matches
the native behavior.
But the panel has a special flag to treat bundles as directories instead
of files. We were checking this flag, but ignoring the case where it
was actually set (which it normally is not), and as a result would
go on to filter directory names as well.
We now handle both cases, and only call [NSWorkspace isFilePackageAtPath:]
if needed (when the treatsFilePackagesAsDirectories flag is not set).
Pick-to: 6.5 6.6 6.2
Change-Id: I2b9a16ff99b4b643389acc042c032813f432ac59
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
This script has been superseded by a C++ implementation.
Change-Id: I2a9b55dbf7fabbb422040f601d9ba1035d88bba4
Reviewed-by: Michal Klocek <michal.klocek@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io>
Homebrew offers a formula for `vulkan-headers`, which does not include
the MoltenVK headers. MoltenVK does include the vulkan headers, but if
someone passes the vulkan-headers path to CMAKE_PREFIX_PATH, then our
module cannot pick up the MoltenVK headers. Brew's MoltenVK
installation is a bit odd as well, as in, one needs to point the
CMAKE_PREFIX_PATH to `HOMEBREW_PREFIX/molten-vk/libexec/` instead of
the directory head.
Pick-to: 6.6
Change-Id: I933faeb16b3f54597e3a0af0af584d79b3c0a344
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The code bailed out of the while loop when "remainingTime <= 0",
for a QDeadlineTimer::isForever() timer remainingTime() returns -1,
whereas remainingTimeAsDuration() returns nanoseconds::max().
I.e. the original code stopped the while loop when the timer isForever()
or "expired" (i.e. remaining time is 0). I am not sure the isForever()
part was intended that way or not, but it makes sense, if
QCoreApplication::processEvents() has already run "forever", there is no
point looping again.
[ChangeLog][QtCore][QTest] Added qWait(chrono::milliseconds) overload.
Change-Id: I871c28b053c6ba4f81a7e2d434aa4fbe03c8c5e7
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Using chrono means one can write 10s instead of 10'000.
[ChangeLog][QTest] Added qSleep(std::chrono::milliseconds) overload.
Change-Id: Iac1b12a3fc3f692b557e2d459e6f3bc565f20e93
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The button state from windows when we use GetAsynckeyState() provides
both MK_LBUTTON and MK_RIGHTBUTTON at the same time. This creates an
issue when we validate only with single state to determine
DRAGDROP_S_DROP operation.
Normally, The MK_RBUTTON will be delivered when we have long press
during drag. But sometimes (no definitive reason identified) the key
state from windows contains both the key state (MK_LBUTTON | Mk_RBUTTON)
during drag and drop operation with touch.
This patch set fixes the issue by validating all key state instead of
a particular state.
Fixes: QTBUG-112995
Pick-to: 6.6 6.5
Change-Id: I67bf5f4956b68279ecc5fbeca8e8e7aef46d0482
Reviewed-by: Timothée Keller <timothee.keller@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Wladimir Leuschner <wladimir.leuschner@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
As a result of d8bbb5ee0e, we
were no longer calling QDialog::done(), which users may have
overridden.
We now pull out the dialog code to determine whether to
emit accepted/rejected directly in done(), so that we
can go back to calling QDialog::done().
Pick-to: 6.6 6.5
Change-Id: Ie08270123d61d9010acd8c989b66986f71960ad0
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The native dialog helper is populated with buttons based on the message
box buttons, which are still represented as QAbstractButtons, either
by adding custom buttons, or by turning QMessageBox::StandardButton
into QAbstractButton.
To ensure as little difference as possible between the native and
non-native backed dialogs, we plumb the dialog helper clicks back
to the corresponding QAbstractButton. We were already doing this
partially for custom dialog buttons, but now we also do it for
standard buttons.
As the click() will plumb back to _q_buttonClicked, which calls
setClickedButton to finalize the dialog, we don't need to do
this explicitly anymore.
For custom buttons it now means the result() of the message box
will be the custom button's index, not its role, but the result
in this case is documented to be an opaque value, and it's best
to keep these the same for native and non-native dialogs.
Pick-to: 6.5 6.6
Change-Id: I5fe3b28e4c4ed879775610103cd1b591b3353f7e
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
In d8bbb5ee0e we started respecting the
button roles of buttons added to QMessageBox, by emitting accepted()
and rejected() if the appropriate roles were found.
Unfortunately this only touched the QMessageBoxPrivate::_q_buttonClicked
code path, for non-native dialogs, leaving the code path for native
dialogs in QMessageBoxPrivate::_q_clicked alone.
We now follow the same approach for the native dialogs as for the
non-native ones, by calling QMessageBoxPrivate::close() and
QMessageBoxPrivate::finalize() explicitly, instead of going
via QDialog::done(). This allows us to pass a dialog code
to finalize().
One side effect of the original change was that overriding
QDialog::done() for non-native dialogs no longer had any effect,
as we were using lower level plumbing. Since we now align with
the original change for native dialogs, we will adopt the same
limitation, but this will be fixed in a follow up for both
cases.
The callback code for custom buttons in native dialogs could also
use some alignment with the non-native path, but this is also
left for a follow up.
Fixes: QTBUG-113685
Pick-to: 6.5 6.6
Change-Id: Iea03a0007f884d6c7f11d2bd891446bdaa5ddc67
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Erik Verbruggen <erik.verbruggen@me.com>
For non-native dialogs we set the clicked button before calling finalize,
which emits finished(). We did the same for custom buttons in native
dialogs, but for standard buttons in native dialogs we deferred it
until QMessageBoxPrivate::helperDone, which meant that during the
finished() signal the button was not set.
We now set the button as early as possible for all three cases.
Pick-to: 6.6 6.5
Change-Id: Ifdbaa9a25105fef0bb56dd28caee9af55cd74e67
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
We want syncqt to be built optimized by default. The current approach
set the default build type for the external projects and optimized
flags for the non-configure-time syncqt build. The problem is that
syncqt still have compiler flags littered by either the Qt configuration
type or the system defaults that are applicable for RelWithDebugInfo
configuration(the default one we chose for syncqt).
This patch makes sure that we cleanup all compiler flags from any
optimizations and apply optimized flags for all configurations. Also
we discard '/RTC1' flag if it's set. Configure time executables now
respect the language related flags that are set in the project and
adjust the flags passed to try_compile.
For linker flags we should use those that are applicable for the
preferred build type. Since syncqt is built in RelWithDebugInfo
by default we should replace linker flags in all configs with
those are used for RelWithDebugInfo configuration.
Fixes: QTBUG-114925
Pick-to: 6.5 6.6
Change-Id: I782f81a36f5ef7ee4d342ce8ac6c217cb2552f3b
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* use nullptr
* use member init
* set ExpandingFieldsGrow fieldGrowthPolicy for QFormLayout, which
makes it behaviors similar on macOS as other platforms
* select first row to make up/down keys works by default
Pick-to: 6.5 6.6
Change-Id: I25d9869d2ca1c7274c2b750aada8270734787546
Reviewed-by: Liang Qi <liang.qi@qt.io>
They're already suppressed for clang.
-Wself-move was added in GCC 13.1, the CI still doesn't have that so
wrap it in an "#if Q_CC_GNU >= 1301".
Change-Id: I5c2ec78a5003485261b4e3125f85c5b78dd0db22
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
/proc/self/mountinfo is available on Android too AFAIK (it's available
on an old Android 6.0 phone I have).
Change-Id: Ia4b04a143b362c7a18773716a90897ce4c5fc5f0
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
The check_language macro spawns a new cmake subprocess to detect
availability of a language. We use that to detect availability of
the Objective-C/C++ languages when targeting Apple platforms.
That's problematic because the parent process CFLAGS / LDFLAGS env
vars influences the result of the subprocess compiler detection,
and in some cases that can fail the detection.
An example of that is passing iOS specific flags which then get
mixed with the default macOS flags added by CMake, resulting in
a linker failure.
Instead of using check_language, explicitly enable the Objective-C
and C++ languages when targeting Apple platforms because we know
that we need them for compiling Qt.
This avoids the issue because enable_language is not spawning a
separate cmake sub-process and thus passes more information to the
underlying try_compile project to ensure a successful check.
The change also means that CMake will error out earlier in case if the
Objective-C compiler is not found, which was not the case before.
Pick-to: 6.5 6.6
Fixes: QTBUG-114470
Change-Id: I1a16c1e5828dfe10b2d7da27cc9a8c787517ab8e
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This class doesn't exist on MSVC, so the inline functions didn't
become part of the ABI, so it suffices to only export the two
out-of-line functions.
Pick-to: 6.6
Task-number: QTBUG-104164
Change-Id: Iedf8b0b1882802db53406942d7ac2a27e7ddfa23
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
To maintain flexibility in how we store the features, we
introduce accessors through indirection rather than accessing
the property directly.
Made as response to API review.
Pick-to: 6.6
Change-Id: I3e5d4ddabe93f67796af4626fddefe028ded9888
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Lars Knoll <lars@knoll.priv.no>
The feature allows to not use OpenSSL in QCryptographicHash
implementation and removes OpenSSL from dependencies of QtCore if
disabled.
Fixes: QTBUG-114783
Pick-to: 6.6
Change-Id: I2a49fa9ddfa5acedcfc95a3330fd7863a8052a5c
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
... and collapse adjacent C string literals.
Both QStringBuilder and non-QStringBuilder builds have no problem
resolving an operator+ for char[] and QByteArray, so there's no need
to turn the char[] into a QByteArray using the _ba UDL first.
It just causes pain because not all active branches support this UDL,
so remove, to bring this code in line with what the cherry-picks to
6.2 and 5.15 must needs had to use.
Amends 6326bec46a.
Pick-to: 6.6 6.5 6.5.2
Change-Id: Id3d61483729c51c82f58b826efcc8fc7960c3ccd
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
The /coin directory is not installed, so trying to include a .qdocconf file using a relative path from an (installed) global configuration will fail.
Task-number: QTBUG-113326
Change-Id: I761b1a7eb19ca9d6a768f1367e30d5eaf80cb816
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
I added the ability to use `-no-unity-build`, and included the
batch size in the config.summary as well. In addition, qt_feature is not
being used for `-unity-build` anymore.
Pick-to: 6.5 6.6
Change-Id: I4a10e03d3505336d2256280ed2854ec0425df47f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
