On Unix, we have the fchmod(2) system call that changes the permissions
of an open file descriptor. This commit adds a test for that, by not
closing the QFile before setPermissions().
Pick-to: 6.4
Change-Id: If5d5ef6220874ae8858efffd171255b9f20ed501
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
In theory, if we succeed, the permissions should be what we set, but
let's not make that assumption. And if we failed, it might be because
the file disappeared or something else, so re-stat()ing the file is a
good idea.
Pick-to: 6.4
Fixes: QTBUG-7211
Change-Id: If5d5ef6220874ae8858efffd171255506b7bbee0
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
"obscured" is also what the doc uses for QWidget's visible property [1].
[1] https://doc.qt.io/qt-6/qwidget.html#visible-prop
Change-Id: I0fc5a2672b8d6f43627763e01ffe7ebde17ac6e8
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
With high-DPI scaling in place QScreen properties like the geometry
can be affected both by screen resolution changes, as well as logical
DPI changes. We want to ensure similar behavior in both cases when it
comes to which change-signals we emit, so centralizing this code makes
sense.
As the update of the cached primary orientation is trivial we do it
unconditionally.
Change-Id: I712005075a4b758180906fb88b2ac187b3dbe1ff
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
QCore::applicationName() is influenced by what values we insert into
the Info.plist file of an application bundle.
We accidentally inserted tokens like ${PRODUCT_NAME} that are meant to
be expanded by xcodebuild, even when using a generator like Ninja.
This caused the applicationName() to report "${PRODUCT_NAME}".
Make sure to only call relevant finalizers for macOS applications
when using a generator other than Xcode.
Amends d5580aa719
Pick-to: 6.4 6.4.0
Fixes: QTBUG-106652
Change-Id: Idbc9c84557a8f17b1302e6969f6eb317e3ef225d
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
This is needed to later determine what kind of runner should be
selected on WASM for the executable. Tests use the test runner,
whereas other executables use qtLoader.
Change-Id: I75aa361403b72f8e82a288967b8a81b8232d68dc
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
It has been decided to add an appearance property in QStyleHints, which
will be propagated to classes that do not include QPlatformTheme.
Therefore an appearance enum class is added to the Qt namespace, thus
being available to all Qt classes.
Task-number: QTBUG-106383
Change-Id: Icff94b0d7adca954ce74241d6811401d41f053e6
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
__has_include(<chrono>) is always true, because C++11 chrono include
is required since 6.0.
Pick-to: 6.4 6.3 6.2
Change-Id: I50cb92571bf4f1f86e2f3f2b5f486dd3c3f30f4a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Commit 71b4d4f150 is likely the source of
the issue. It fixed a race on disconnection, but kept the call to
disconnectNotify() (which is user code) inside the locked section. My
analysis is that by construction the sender object can't be undergoing
concurrent deletion anyway at this point. All call sites
(QObject::disconnect or the signal-slot activations but before the slot
is activated) imply that the user code that reached here cannot itself
be racing the deletion.
There may be one race condition left: if the same signal was connected
earlier to a slot via queued connection and that slot deletes the sender
asynchronously. A synchronous deletion is handled by doActivate(), so
the single-shot connection is never activated in the first place, but an
asynchronous deletion could race past that check and delete the sender
while QObjectPrivate::removeConnection is running. However, I'd call
this a mistake in user code.
[ChangeLog][QtCore][QObject] Fixed a regression from 6.3 that caused
QObject::isSignalConnected() to deadlock if called from inside
disconnectNotify().
Fixes: QTBUG-106025
Pick-to: 5.15 6.2 6.3 6.4
Change-Id: Ic6547f8247454b47baa8fffd170fe0bdb62cfcaf
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Lars Knoll <lars@knoll.priv.no>
And remove the platform-specific code.
fenv is available since c++11.
Change-Id: Ia5540be93b54117d4b5e9c7579100039c151dcc5
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The _qt_internal_wrap_tool_command function has a limitation
that it is not possible to use it when a command needs to be wrapper
in a generator expression.
Provide a lower level API called
_qt_internal_get_tool_wrapper_script_path
to just get the path to the wrapper script, ensuring that the script
is created if needed.
Deprecate _qt_internal_wrap_tool_command, in favor of replacing it
with the new API.
Pick-to: 6.4
Task-number: QTBUG-90820
Task-number: QTBUG-96232
Change-Id: Ie4a4a17178bf2061ae01ee2b03b052d84560abf9
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Instead of creating the tool wrapper shell script only
during a Qt build in QtBuild.cmake,
ensure it is created any time _qt_internal_wrap_tool_command is
called, regardless if we're building Qt or a user project.
As a transitional period not to break compatibility, we also need
to create the script in QtBuild.cmake, until all usages of
QT_TOOL_COMMAND_WRAPPER_PATH are replaced with function calls.
Currently such usages are present in qtdeclarative.
When considering which bin dirs to add to the script's PATH
environment variable assignment, in addition to the build
internals relative bin dir, also add QT_BUILD_DIR,
QT_ADDITIONAL_PACKAGES_PREFIX_PATH and QT6_INSTALL_PREFIX.
QT_BUILD_DIR is important so we always pick up the just-built
but not installed libraries in a prefix build when running just-built
tools.
QT_ADDITIONAL_PACKAGES_PREFIX_PATH is important when building examples
as ExternalProjects in prefix builds, to ensure that the
not-yet-installed tools and libraries are picked up from the repo
build dir, which is passed via QT_ADDITIONAL_PACKAGES_PREFIX_PATH
to the external projects.
QT6_INSTALL_PREFIX is there in case if the build internals relative
dir is located in a different places than the Qt6 package.
Pick-to: 6.4
Task-number: QTBUG-90820
Task-number: QTBUG-96232
Change-Id: I4d76fbbc275ca961379971054f87991adac36539
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Move it into QtPublicCMakeHelpers.cmake so it is available also when
configuring qtbase and the Qt6Config.cmake file is not yet loaded.
Pick-to: 6.4
Task-number: QTBUG-90820
Task-number: QTBUG-96232
Change-Id: I88127fe0439ae26af1d125eb584244d315574a48
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Move it out of QtConfig.cmake.in into QtPublicCMakeHelpers.cmake
so that the Qt6Config file is less cluttered.
Pick-to: 6.4
Change-Id: I772a0cca35d5c03cd688c3f1de34984484444105
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Historically, resource imports were generated as "import file_rc",
however, pyside6-project generates files by prepending "rc_". Add an
option to flip this.
Pick-to: 6.4
Change-Id: Iee0f161cb2101c8080bd131a6401bbaf4682186d
Reviewed-by: Adrian Herrmann <adrian.herrmann@qt.io>
Reviewed-by: Cristian Maureira-Fredes <cristian.maureira-fredes@qt.io>
The leak is just on termination, but we should show good practices in
our examples
Pick-to: 6.4 6.3 6.2
Change-Id: I39abb7545d3c68a1a537b865ba3fcb5e60c22fbf
Reviewed-by: Venugopal Shivashankar <Venugopal.Shivashankar@qt.io>
The macOS platform plugin exclusively uses handleExtendedKeyEvent() these
days, never the simpler handleKeyEvent(), and always passes false for the
tryShortcutOverride argument, so the special-cased code was never executed.
No other platform passes the optional tryShortcutOverride argument, so
it can be removed completely.
If we ever need to bring back this kind of logic it should live in the
macOS platform plugin, not in the QWSI layer.
We have to keep the existing logic for qt_handleKeyEvent() though,
as that's exercised through QTest::simulateEvent(). The next step
would be to remove the QWindowSystemInterface::handleShortcutEvent()
call in QGuiApplicationPrivate::processKeyEvent() and teach existing
platform plugins, as well as the QTest machinery, to handle shortcuts
explicitly before sending raw key events.
Change-Id: I6eb3fd18c64d1619e33e79f076e25efd299a9ba7
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
This Windows-only file should not be executable on Unix derivatives.
And on Windows it doesn't matter whether we install PROGRAMS or FILES.
This amends commit e0c0feb1d8.
Task-number: QTBUG-106610
Change-Id: I70bfc9576b1feb06c5d69c5f4921a8f83723c753
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Add the NO_TRANSLATIONS option to qt_deploy_runtime_dependencies and
qt_generate_deploy_app_script. On Windows and Linux, this option
prevents the deployment of Qt translations.
[ChangeLog][CMake] Added the NO_TRANSLATIONS option to
qt_deploy_runtime_dependencies and qt_generate_deploy_app_script.
Change-Id: I9d8435e262e2ff6c7242760ddb189473af850476
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Add the command qt_deploy_translations to the CMake deployment API.
This can be used to deploy a set of Qt translations.
This command is supposed to be called by the generic deployment tool in
a future commit.
[ChangeLog][CMake] Added qt_deploy_translations for deploying Qt
translation catalogs in user projects.
Change-Id: I4492a5042970cf89b2be2ed0c34521c7af904771
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Before this change, qt_deploy_runtime_dependencies supported Windows and
macOS only. We add a generic deployment method implemented in
cmake-language with file(GET_RUNTIME_DEPENDENCIES). This deployment
method is now enabled for shared builds on Linux.
The file(GRD) command requires that the EXECUTABLE argument points to
the executable in the build directory.
Only libraries in Qt's installation directory are considered for
deployment. This includes Qt's own libraries and also things like
libicu*.so we're shipping with the installer.
Unlike macdeployqt and windeployqt, the generic
qt_deploy_runtime_dependencies does not yet support deploying
translations. We will catch up on this in a later commit.
Change-Id: Iea23abcdba774d4c1885c8d2c243eb3e48fb7fae
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
These tested results are all wrong and caused by internal overflows.
Note the behavior can not be fixed either as it involves moving an
already maximized QRect, which can not be done without overflow.
Change-Id: If35db68102889012c56eb149fe49bc48954d3422
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: hjk <hjk@qt.io>
This fixes an regression after commit aa99bf532d,
where the moc filename was changed. It does not check if basename contains a
relative path.
This checks if basename contains a relative path. In that case, make sure to
correctly set the path in the `_moc` variable.
Fixes: QTBUG-106571
Change-Id: I88ec156d7c666b626d85018e9cde0dc397051035
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Make use of supported types only. As such,
QOpenGL2PaintEngineExPrivate_drawTexture_entry has to be adjusted so
that it does not exceed the maximum number of supported parameters by
LTTNG, and thus the 'pattern' argument had to be dropped.
Change-Id: I8d1c1dea7de82063926502d77dde1063b2096b73
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
This hint is not really needed in the first place and only causes
problems in some environments.
For example in KDE, the compositor animates changes in position and size
for all ToolTip windows. However, this is not wanted here because we use
this window as a thumbnail for a drag-and-drop operation.
Before this patch the dragged element would lag significantly behind the
cursor. Now it works as expected, i.e. the dragged element follows the
cursor immediately.
Fixes: QTBUG-98048
Change-Id: I49ef453c05228ce1a9336a9463046a794650acae
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Liang Qi <liang.qi@qt.io>
While working on QTBUG-98434 some improvements for the pre-existing
code were found during the code review.
The first parameter is the base of the QString created by the
function but it is not needed as an actual QString, it is just
appended to. Change the type from QString to QL1SV.
Task-number: QTBUG-103100
Change-Id: I8042a921628e84d951dcfd2fd12154bf74dd5162
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
The *Other was documented as "anyone" where it should be "others"
because these permission are only applied to users except owner and
users in group in UNIX like system.
Change-Id: I416eb53a5b6e7ccba238a70a7a0cedd129fc83a4
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
We are calling makeKeyAndOrderFront on the NSColorPanel once when
show()-ing it and then we call runModalForWindow when calling exec(),
which also internally makes the panel key window.
The call to makeKeyAndOrderFront changes the window to key window
immediately so by the time the next event loop is run, the window is
already key. This causes problem when running the modal loop in
runModalForWindow as now the [NSApp _previousKeyWindow] already points
to the color dialog (NSColorPanel), so the application looses the
reference to any other window that was key before the color dialog,
thus, choosing the wrong window as key when the color dialog is closed.
So ideally we would avoid the first call to makeKeyAndOrderFront, but
since we don't know if exec() will be called on the dialog, or just
show() (which would need the call to makeKeyAndOrderFront in order
to set the dialog visible), we need to make the call to
makeKeyAndOrderFront in an asynchronous way, so by the time the
next event loop is run (the modal session loop in the case of
exec()), the app still has the correct reference to _previousKeyWindow
and can choose the right window after the color dialog is closed.
Fixes: QTBUG-42661
Pick-to: 6.2 6.4
Change-Id: I1b5c429c90847c48d7aa1d61b2462122c5b587f8
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Some errors, such as 404, may still present useful data. As opposed to
errors such as 'RemoteDisconnected'. So, just keep the data around until
the reply is deleted.
Pick-to: 6.4
Fixes: QTBUG-106573
Change-Id: I6c86b5a55a45f837ea9b42559d88cd3e0ac2fa5c
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
The XXX_other_files targets were introduced to collect files that are
added to resources and expose them to IDEs. This resembles what we did
in qmake with OTHER_FILES but has the downside of cluttering the IDE
with additional targets.
The idiomatic way of exposing such files to IDEs is to add them as
source files to the related target and mark them as HEADER_FILE_ONLY.
We must avoid marking source files as HEADER_FILE_ONLY that are
additionally used in SOURCES. This can only be done reliably when
finalizing a target.
Targets that are not finalized, for example targets that are added with
add_executable instead of qt_add_executable, are handled as before: for
those we still create the XXX_other_files target. The same applies if
CMake < 3.19 is used.
Task-number: QTBUG-99808
Change-Id: I7220e91d726e9409d557d5cd33d171528b9d4a63
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Synthetic mouse events are not reliable, as the platform might restrict
synthetic mouse moves. In addition, the WM might automatically activate
the window when the other window is hidden, which makes the EXPECT_FAIL
flakey.
Since the test was not written to test window activation, let's just
explicitly activate the window.
Fixes: QTBUG-23699
Pick-to: 6.4
Change-Id: I0ac1d3bc0658dfbd600a1f5d960839860be6dd2c
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
As a potential improvement discovered while working on QTBUG-98434,
replace the current comparison in toBool with QString::compare.
Task-number: QTBUG-103100
Change-Id: If5482adeea1537d24a97a4dda2d27ecc3b12b5bf
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
Its debug member can be set where it's declared, making the
constructor redundant.
Change-Id: Ic1195108766a6a86c3392a5bcf7f197ea31e8068
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The CLDR data from which they're obtained may contain a space-joined
sequence of timezone IDs, rather than a single ID. (This applies
principally to the mapping from MS-specific names to IANA IDs, but in
principle may also apply to the other data obtained from same-shaped
XML.) Note this on the methods of internal types and actually take it
into account when using this data to match IDs.
See CldrAccess.readWindowsTimeZones() in util/locale_database/cldr.py
for the form of the CLDR data from which these are extracted; the type
attributes of mapZone elements in the XML are the source of the
space-joined lists of IANA IDs.
Change-Id: I3f940e4c352d8312ff735f972c9f8f3961572884
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Port of the 5.15 change. It is not strictly required for Qt 6 since the
immediate problem of failing to compile some of the shaders with some
drivers will pop up much more rarely in practice, because neither
Multimedia nor the backing store compositor for
QOpenGLWidget/QQuickWidget use QOpenGLTextureBlitter in 6.4 and newer.
To maintain the internal behavior between 5 and 6, the patch is
nonetheless ported to Qt 6. It also has a performance benefit for
the users of the blitter, because now the special shader variants
(for rectangle or external textures) are only created when needed.
Task-number: QTBUG-101396
Change-Id: I1cf4bec0c74045f4b6f94765563254026bf0b7d8
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
While working on QTBUG-98434 some potential improvements were
found in the pre-existing code.
Some of the QLatin1String literals are used to initialize
QStrings or are converted to QStrings and so it makes sense to
replace them with QString literals.
As a related change, change the type of namespaceDelimitier from
QString to QL1SV, since it is used only for a function call and
that function has an overload to take QL1SV.
Task-number: QTBUG-103100
Change-Id: I56db6ddd84ad2a7133a765bb49ecd8f962ac5c13
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
This will ensure that we get compiler warnings when a newly added value
is missing.
Change-Id: I6de78534cb330aa4968ac018354a1ab37c499228
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Otherwise, when platform integration is deleted, it triggers resolving
promises after the global instance of QGuiApplication is dead and
QPixmap in turn calls qFatal, crashing the exiting app.
Fixes: QTBUG-106472
Change-Id: Ie706d030214c33abdbc8fff86cc2eddd0c632f1b
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Refactor QWinRegistryKey to make it more modern and more
usable from outside.
Adjust the test for QWinRegistryKey to test the new functions,
merged with the original test.
Will port raw registry accessing code in QtBase to use this
class in follow-up commits. This change is the first step.
The long term goal is to port QSettings registry code to
this class instead of using raw Win32 APIs, however, there's
much more registry code in QSettings and migrate them to this
class needs a large refactor, so jsut leave it for now. Will
fix it in some future commit.
Change-Id: Iada2adb41b4d58e1b658ff6870a4b31ace479d43
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
[ChangeLog][macOS] QWindow::setKeyboardGrabEnabled() and
QWindow::setMouseGrabEnabled() now returns false, as the feature is
not implemented on macOS yet. If you were relying on these functions
to make the window key (activate it), please use
QWindow::requestActivate() instead.
Task-number: QTBUG-106597
Change-Id: I86d7d806080aae98c9aec5287adfcc8cb70d372a
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
