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>
If an application runs on a macOS or iOS version that introduces new
permission statuses that we haven't accounted for, we don't want to
crash.
Replace Q_UNREACHABLE with a warning and Qt::PermissionStatus::Denied.
Pick-to: 6.5 6.6
Change-Id: I063042f510caaa8936742f6195bd455d09c4d9ee
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
For now we do not have a QCalendarPermission::AccessMode::WriteOnly,
so we have to report Qt::PermissionStatus::Denied.
Fixes: QTBUG-114864
Pick-to: 6.5 6.6
Change-Id: I94e92912ef4c24adb524ccf2cf28553115d6781b
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Doris Verria <doris.verria@qt.io>
CTFontDescriptorCreateMatchingFontDescriptors has been observed to
return nullptr, so we need to handle that explicitly.
Fixes: QTBUG-113698
Pick-to: 6.5 6.6 6.2
Change-Id: Ic9fa574c14068fcae98fe8e6ceddd8a4f7008210
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
- Use unique_ptr instead of manual memory management
- Improve consistenty in variable name with the simpletreemodel
childrenNumber -> row, m_ prefix for member variables
Change-Id: Iface30c2224c2b1db7c623a9e6fcbb449c556f3e
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Since qt_noop() is supposed to be a no-op, it should not affect
constexpr'ness and noexcept'ness of functions and expressions it's
(indirectly) used in.
That requires that it be constexpr and noexcept itself. Add the
keywords, but guard against use from C. We can't use our Q_ macros
(which would enable noexcept for C, too, on some compilers, because
qcompilerdetection.h depends on qtnoop.h, and we don't want the
circular dependency.
Pick-to: 6.6 6.5
Change-Id: Ie5441c423b7942a6c956345126fc7aec99907d25
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
A class-level [[nodiscard]] used to be the only way to get a waring
for code such as
QMutexLocker(&mutex);
with original C++17 means. This was because a few of our compilers
would warn about the presence of [[nodiscard]] on ctors, which is
really the semantics we want: we don't want to prevent users from
passing QMutexLocker out of functions and users of those functions
from ignoring the return value, if they so choose. That should be the
choice of the author of the function returning such types, not ours.
So QUIP-0019 makes class-level [[nodiscard]] conditional on proper
rationale in the user docs (or the commit message in case of private
API). Since none of the existing uses really strikes this author as
particularly convincing, remove them all.
All these classes have gotten Q_NODISCARD_CTOR on all their ctors, so
we continue to provide the same true positive warnings, minus the
false positives when returning from functions, at least on the
majority of compilers (and it's not as if all compilers interpreted a
class-level [[nodiscard]] as a trigger to warn on the initial example
of this commit message).
Task-number: QTBUG-104164
Pick-to: 6.6
Change-Id: I163356486e7c80f9d69bf67023010a88233fe662
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
QGtk3Theme uses the GTK button foreground as a default for the
WindowText color role. When a GTK3 theme has no specific color for the
entry text, this can lead to text on certain assets looking darker
and thus disabled.
This discontinues usage of the button foreground for the window text.
Finding the WindowText color role in QPlatformTheme::SystemPalette now
follows the following logic:
(1) GTK normal entry text is used if specified. This is the preferred
option, copying GTK behavior.
(2) If (1) is not specified, the GTK default text color is used, making
WindowText equal to Text.
(3) If neither (1), nor (2) are specified, the WindowText color role is
taken from qt_fusionPalette, where it is also equal to Text.
The SystemPalette is used as a default template for all other control
or widget speicific palettes. The rules above therefor apply to all
screen assets (unless they use a JSON file to specify a their
individual WindowText).
[ChangeLog][QGtk3Theme][SystemPalette][WindowText] Default to GTK
Entry Text / Normal Text / qt_fusionPalette
Fixes: QTBUG-114600
Pick-to: 6.6 6.5.2 6.5
Change-Id: I4c96ac7d096526faf4c2feee436753990c6c9f92
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Explicitly check that at least CMake 3.21 is used when building Qt or
when using Qt in a project.
This only affects macOS and iOS builds.
We check for 3.21 instead of 3.21.1 as described in the documentation
to avoid an error like:
Policy VERSION range "3.21.1...3.21" specifies a larger minimum than
maximum.
Until the technical limitation is addressed, if someone does end up
using 3.21.1, another existing check for "unsuitable" cmake versions
(as opposed to minimum required) will let them know they should use
something newer.
Amends 1cf3295cef321c9a587af2f2de7740c0cd3ca743.
Pick-to: 6.6
Fixes: QTBUG-114869
Change-Id: I2a479baaa63cfbe23af187cf0796e1c00042692b
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
