It didn't enter the original patch because it would
prevent it to be backported to 6.2 and 5.15.
Pick-to: 6.3 6.4
Change-Id: I9af30b86b98d5d101b0784cf45781cf46d216c6d
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
While headerscheck doesn't detect this (generic code), this might
trigger warnings in user code.
Pick-to: 6.4 6.3 6.2 5.15
Change-Id: I6183323d0a1c73b021699d4c4afa2d1fcf71aad2
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
User code in an event handler can do arbitrary things, including
operations that lead to destroying the QWidgetWindow. An example is
what the autotest does: reparenting the top-level widget to under
another top-level upon the drop. Internally this leads to destroying
the drop target's QWidgetWindow as the widget is now a child, not a
top-level.
In fact some of the existing drag and drop handling code seems to be
prepared to handle the case of having the drag target widget destroyed
in the user's event handler during a drag-move. But none of it is
prepared for having the QWidgetWindow destroyed upon returning from
forwardEvent().
The associated bug report has the same root cause, it is just popping up
now via the new 6.4 behavior: adding a QOpenGLWidget to a widget
hierarchy upon a drop leads to getting a new QWidgetWindow (if the
window only had regular raster widgets before).
To solve this, avoid touching members on 'this' after the
forwardEvent(). It looks like the handlers for mouse events follow
this pattern already, no member data is touched after forwarding events
(not sure if that is intentional or just incidental but it is the safe
solution, even if this is not feasible everywhere, but ideally input
events should take this into account).
Fixes: QTBUG-104596
Pick-to: 6.4 6.3 6.2
Change-Id: I96c704cadcd799fc5619b776e939dfdf313a27dd
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The previous fix 754512a64d
did not handle qml plugins, which meant that they would still have
hardcoded paths and see warnings like the one below when generating
the prl files
CMake Warning (dev) at
cmake/QtFinishPrlFile.cmake:103 (message):
Could not determine relative path for library
qml/QtQml/WorkerScript/libworkerscriptplugin_debug.a
when generating prl file contents. An absolute path will be
embedded, which will cause issues if the Qt installation is
relocated.
Handle qml plugins as well.
Amends 754512a64d
Amends f4e9981259
Pick-to: 6.2 6.3 6.4
Fixes: QTBUG-104708
Task-number: QTBUG-104396
Change-Id: Icfb1069d1cb0a39a35004b20e58ee6e386d14f3b
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Previously if zstd was not found, one would see such a warning message
Could NOT find WrapZSTD: Found unsuitable version "", but required is
at least "1.3" (found ZSTD_LIBRARY-NOTFOUND)
This is because PC_ZSTD_VERSION was a defined variable with an empty
value, which makes FPHSA believe that a version was extracted from
somewhere.
Avoid passing that value directly.
Now the warning message is
Could NOT find WrapZSTD (missing: ZSTD_LIBRARIES ZSTD_INCLUDE_DIRS)
(Required is at least version "1.3")
Pick-to: 6.2 6.3 6.4
Change-Id: I88760d94db0d869d328085996298f4aaa88bc6c2
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>
Rename FindWrapDoubleConversion.cmake into
FindWrapSystemDoubleConversion.cmake.
Merge contents of Finddouble-conversion.cmake into the one above.
This allows users to provide their own Finddouble-conversion.cmake
file (Conan can do it).
Don't mark the system package as required, because we have a bundled
one too.
Add link to upstream.
Make sure to show either Config file or library path when one is
found.
Pick-to: 6.2 6.3 6.4
Fixes: QTBUG-104541
Change-Id: I9ea2330697c6fc280328849ca11522291c4073d8
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
This allows picking up 3rd party Find modules. One use case is
Conan-generated Find modules.
Also add TODO in case we ever need to handle finding the upstream
target name rather than the Hunter chosen one.
Pick-to: 6.2 6.3 6.4
Fixes: QTBUG-104542
Change-Id: I243987c657f74e8127076666d9734b2b657bc0ee
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>
The version option needs to be specified before the COMPONENTS
option, otherwise it is treated as another component.
This causes failures when a Conan provided FindPCRE2.cmake script is
picked up, which actually does validation of component names based
on the component information stored in the conanfile.py recipe.
Move the version value to be before COMPONENTS.
Amends 1007aac63a
Pick-to: 6.2 6.3 6.4
Task-number: QTBUG-104542
Change-Id: I92c70f266a07c4aabdadcecda1ba7e107a033604
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
If the user has a Wacom stylus in proximity of the tablet already
(perhaps left it lying on the tablet) and starts a Qt application, we
don't get to see a proximity enter event, so a lot of device information
is missing; nevertheless, creating a stop-gap device (with ID 0, type
Unknown) makes it possible to get basic QTabletEvents with pressure,
until the next time the stylus leaves and comes back into proximity.
Pick-to: 6.4
Fixes: QTBUG-65559
Change-Id: Ibacbdb78461c0b62d4040c80d210a1b06074e952
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Since objectName() isn't always set, the className() makes it slightly
easier to find and fix the issue.
Also unify some wording "produce a warning", which is generic enough to
fit:
print warning in terminal
print warning in logviewer (if you're unlucky and have to use Windows?)
print warning in system journal (if you're unlucky have to use binary
systemd journal logs)
Pick-to: 6.4
Change-Id: I7522d65666cb5829c33c45039b8646dd535e21ea
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Although CFRunLoop is documented to support nesting, the UIKit event
delivery machinery is not prepared to handle nested event loops. If the
user starts a nested event loop in response to e.g. a button press/release,
it will deadlock the entire UIKit event machinery, stopping processing
of both screen updates (CATransactions) as well as other events.
This became an issue on iPhone hardware device in iOS 15, but can not be
reproduces on iPads or in the simulator.
To be on the safe side, we deliver all touch events asynchronously,
even if that means the application code will always be one step
behind the event delivered by the operating system.
Fixes: QTBUG-98651
Pick-to: 6.4 6.3 6.2 5.15
Change-Id: Id0a9fa60b7bb7aa98606d46257e99eac144a1080
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
When recording which package version to look for in
QtFooModuleDependencies.cmake and other files like it,
instead of using PROJECT_VERSION, use the version of the
package that contains the dependency.
For example if we're hypothetically building the qtdeclarative repo
from the 6.4 branch, against an installed 6.2 qtbase, then
the Qt6QmlModuleDependencies.cmake file will have a
find_package(Qt6Core 6.2) call because qtdeclarative's
find_package(Qt6Core) call found a 6.2 Core when it was configured.
This allows switching the versioning scheme of specific Qt modules
that might not want to follow the general Qt versioning scheme.
The first candidate would be QtWebEngine which might want to
follow the Chromium versioning scheme, something like
Qt 6.94.0 where 94 is the Chromium major version.
Implementation notes.
We now record the package version of a target in a property
called _qt_package_version. We do it for qt modules, plugins,
3rd party libraries, tools and the Platform target.
When we try to look up which version to write into the
QtFooModuleDependencies.cmake file (or the equivalent Plugins and
Tools file), we try to find the version
from a few sources: the property mentioned above, then the
Qt6{target}_VERSION variable, and finally PROJECT_VERSION.
In the latter case, we issue a warning because technically that should
never have to happen, and it's a bug or an unforeseen case if it does.
A few more places also need adjustments:
- package versions to look for when configuring standalone
tests and generating standalone tests Config files
- handling of tools packages
- The main Qt6 package lookup in each Dependencies.cmake files
Note that there are some requirements and consequences in case a
module wants to use a different versioning scheme like 6.94.0.
Requirements.
- The root CMakeLists.txt file needs to call find_package with a
version different from the usual PROJECT_VERSION. Ideally it
should look for a few different Qt versions which are known to be
compatible, for example the last stable and LTS versions, or just
the lowest supported Qt version, e.g. 6.2.6 or whenever this change
would land in the 6.2 branch.
- If the repository has multiple modules, some of which need to
follow the Qt versioning scheme and some not,
project(VERSION x.y.z) calls need to be carefully placed in
subdirectory scopes with appropriate version numbers, so that
qt_internal_add_module / _tool / _plugin pick up the correct
version.
Consequences.
- The .so / .dylib names will contain the new version, e.g. .so.6.94
- Linux ELF symbols will contain the new versions
- syncqt private headers will now exist under a
include/QtFoo/6.94.0/QtFoo/private folder
- pri and prl files will also contain the new version numbers
- pkg-config .pc files contain the new version numbers
- It won't be possible to write
find_package(Qt6 6.94 COMPONENTS WebEngineWidgets) in user code.
One would have to write find_package(Qt6WebEngineWidgets 6.94)
otherwise CMake will try to look for Qt6Config 6.94 which won't
exist.
- Similarly, a
find_package(Qt6 6.4 COMPONENTS Widgets WebEngineWidgets) call
would always find any kind of WebEngine package that is higher than
6.4, which might be 6.94, 6.95, etc.
- In the future, if we fix Qt6Config to pass EXACT to its
subcomponent find_package calls,
a find_package(Qt6 6.5.0 EXACT COMPONENTS Widgets WebEngineWidgets)
would fail to find WebEngineWidgets, because its 6.94.0 version
will not be equal to 6.5.0. Currently we don't pass through EXACT,
so it's not an issue.
Augments 5ffc744b79
Task-number: QTBUG-103500
Change-Id: I8bdb56bfcbc7f7f6484d1e56651ffc993fd30bab
Reviewed-by: Michal Klocek <michal.klocek@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
If a find_package(Qt6Foo) call has the QUIET option passed, don't
display the incompatible version warning.
Also if the find_package call has the EXACT option passed, and the
searched for version does not match the package version exactly,
there's no point in showing the warning because find_package
will reject the package anyway, even if we set
PACKAGE_VERSION_COMPATIBLE to TRUE
Pick-to: 6.2 6.3 6.4
Change-Id: I78ef95cf4a045034fc50853465f3ba1db84bba63
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
A new property Qt::ImEnabled was added in Qt 5.3.
Since the already existing widgets with IM support
(3rd party included) didn't implement this property,
QWidget got the fall back logic that if a widget
was queried for Qt::ImEnabled, and the returned QVariant
was invalid (the widget didn't implement it), we
would, for backwards compatibility with Qt 4, return "true"
(meaning that the widget supports IM).
But a side effect from this fallback logic, is that now
any widget that doesn't implement ImEnabled (or input
methods at all) report that they support IM. This will
confuse platforms like iOS, which uses ImEnabled to decide
if the input panel should show, and if text selection tools
should be enabled. The result is therefore that if you click
on a QPushButton, the input panel will open.
This patch will implement a more careful strategy to check if
a widget implements IM, if ImEnabled is missing. Rather than
saying that all widgets that don't implement ImEnabled supports
IM, we now require that the widget also returns a valid QVariant
for Qt::ImSurroundingText. We assume then, that a widget that
doesn't do so will anyway not be in need of input method support
from the platform.
Fixes: QTBUG-104527
Pick-to: 6.4 6.3 6.2
Change-Id: Ib391fd1daae92c4325e9ccb59730fbdd7c9328fc
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The "callbacks" passed to setMinOrMaxSize are not stored and
outlive the callee. Therefore, don't use std::function to pass
them (by value (!)); instead employ the recently-added function_ref.
Change-Id: I37eea020920a76c063265e667c99a6040394d645
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Currently, to use a promise from C++ we either have to use an ASM block
(which does not work well with dynamic linking) or declare exports in
the EMSCRIPTEN_BINDINGS block, which is cumbersome and cannot be chained.
This solution makes it easy to use js promises by introducing the
WebPromiseManager which dispatches callbacks to appropriate callers when
available.
This is a preliminary patch for FileSystem support, which will heavily
use async APIs.
Task-number: QTBUG-99611
Change-Id: I368a8f173027eaa883a9ca18d0ea6a3e99b86071
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
The native size of a QWindow on Windows is the logical size of the window
times the window's device pixel ratio. We manage this relationship
for top level windows via the WM_GETDPISCALEDSIZE message, and during
WM_DPICHANGED we then applied the same scale to child windows.
This is problematic in the case where a child window does not have
a QWindow parent, so instead of scaling all children when the parent
gets a WM_DPICHANGED message, we scale each individual child in the
child's WM_DPICHANGED_AFTERPARENT message.
Task-number: QTBUG-103383
Pick-to: 6.4
Change-Id: Ia0845aa19a3bb97b7bc9e7d9554ac02b95ca65a5
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
When partly moved back and forth between screens
with different dprs (device pixel ratios)
unexpected jumps and size changes could occur.
(See the linked issue for details)
This patch maps global coordinates to native ones
and vice versa (in QDockWidgetPrivate::mouseMoveEvent()),
so that the calculated position is the right coordinate
on the right screen.
Pick-to: 6.4 6.3 6.2 5.15
Fixes: QTBUG-104205
Change-Id: I0e59792a946e0444fed2e2b857f2f8b140afc9b7
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
This allows to speed-up the build of external projects.
Pick-to: 6.3 6.4
Change-Id: I3bbdbd6ec5b0920c9e912cb59a6e16c5a8efa0ec
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
The commands qt6_add_executable and qt6_add_library both accept a list
of sources that get automatically added to the created target.
Extend qt6_add_plugin to also accept sources for consistency.
Fixes: QTBUG-104189
Change-Id: Iad5d8c5b31551663be155d068d55e770e1a91b27
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
qtwasmtestlib supports writing asynchronous tests for
the web platform.
Asynchronous test functions differ from normal test
functions in that they allow returning from the test
function before the test has completed:
void TestObject::testTimer()
{
QTimer::singleShot(100, [](){
completeTestFunction(); // Test pass if we get here
});
}
Currently one logging backend is supported which
writes the results to an html element. See the README
file for further documentation.
Change-Id: Ia633ad3f41a653e40d6bf35dd09d62a97c608f84
Reviewed-by: Mikołaj Boc <Mikolaj.Boc@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Use activity location in the Window to handling a cursor handle and editpopup menu
in Multi-Window mode. No effect when using full screen.
Fixes: QTBUG-58503
Pick-to: 5.15 6.2 6.3 6.4
Change-Id: I17f3119be4c3dda2fca50156bf62c1260c2ea1f6
Reviewed-by: Samuel Mira <samuel.mira@qt.io>
Reviewed-by: Rami Potinkara <rami.potinkara@qt.io>
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Fix the offset of the EditPopupMenu on application window.
Issue caused by a5bb7b3ca5
Fixes: QTBUG-71900
Pick-to: 6.2 6.3 6.4
Change-Id: Ib95e1544fe91c273bc5317bd338a50a74fb1090a
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Drop call to setPlatformScreen since the only affected variables are
logicalDpi and geometry. Replace setPlatformScreen with updateLogicalDpi
which handles global scale factor changes in QScreen.
Call updateGeometriesWithSignals() to check if there are any changes
in geometry or availableGeometry, since the geometry or availableGeometry
can also change when setting a scale factor.
Move setPlatformScreen to QScreen ctor as the function is not used
elsewhere.
Pick-to: 6.4 6.3 6.2
Change-Id: I7acf40bf0643e89a1d9177674d66dc503829f98f
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Ignore the original width if it's larger than maximum.
Fixes: QTBUG-104383
Fixes: QTBUG-104565
Pick-to: 6.4 6.3 6.2
Change-Id: Id86d4f5bd1d50304d95c4711f1989f4dae416b69
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
References to __declspec(dllimport) is not a constant expression on
Windows, so we can't have a direct reference to a staticMetaObject.
Commit 9b8493314d fixed the Q_OBJECT parent
link (added in 5.14, kicked in for 6.0 with the ABI break), but commit
656d6f2a9b added links for Q_GADGETs too
without taking the need for Windows DLLs into account.
This change is a no-op everywhere but Windows. On Windows, since we
store the pointer to the indirect getter function, now you may get non-
null pointers from QMetaObject::superClass().
Pick-to: 6.4
Change-Id: I6d3880c7d99d4fc494c8fffd16fab51aa255106e
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Just so we have data structures and functions grouped together.
Pick-to: 6.4
Change-Id: Id0fb9ab0089845ee8843fffd16fa171f6e1caf2b
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
The presence of the mutable causes the const object to lose its
constness, so declaring as const wasn't helpful. But we can't drop the
const wholesale for MSVC right now because it mangles the variable's
type in the external name.
For all other compilers, we drop it for user-defined types, which is a
no-op but is semantically correct because QMetaType needs to modify
those objects. Aside from a few const_cast (marked with comments),
nothing else changes.
For types with built-in type IDs, however, the QMetaTypeInterface is now
fully const... or would be if it weren't full of relocations. It does
move the lot from the .data section to the .data.rel.ro section. After
this change, QtCore and QtGui have:
QtCore QtGui
.data.rel.ro 57 23
.data, exported 17 39
.data, private 94 193
sizeof(QtPrivate::QMetaTypeInterface) = 112 on 64-bit platforms
(but GCC issues ".align 32", so they effectively occupy 128 bytes)
Change-Id: Id0fb9ab0089845ee8843fffd16f9a35bfafebf77
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
This *should* make no difference in behavior, it just prevents the
instantiation of the QMetaTypeInterface and all the lambdas used in it
in every compilation unit, with a copy in every library. Now, a simple
function like:
QMetaType f() { return QMetaType::fromType<int>(); }
produces only a single function, with a reference into QtCore:
_Z1fv:
movq _ZN9QtPrivate25QMetaTypeInterfaceWrapperIiE8metaTypeE@GOTPCREL(%rip),%rax
ret
The code above *does* work on Windows, producing:
_Z1fv:
movq __imp__ZN9QtPrivate25QMetaTypeInterfaceWrapperIiE8metaTypeE(%rip), %rax
ret
However, it breaks the staticMetaObjects' metatype listing, because
getting the address of a __declspec(dllimport) variable is not a
constant expression (it lacks data relocations). So this is disabled on
Windows.
This change also broke the INTEGRITY build. I've simply disabled the
optimization there without attempting to understand why it fails.
Task-number: QTBUG-93471
Pick-to: 6.4
Change-Id: Id0fb9ab0089845ee8843fffd16f97748a00b4d64
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Do not wait for the timer to time out. When losing the focus, finish
editing immediately since we cannot really edit it further without
focus.
Pick-to: 6.4
Change-Id: If42926ef9b06fbea7592a294f48ea5e99ef57ef8
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Though we can get xcb_xkb_state_notify_event_t for the change, but
it looks like not enough, especially when a new usb barcode
scanner was used, it should be a slave keyboard, and Qt only uses
core_device_id for now. It should be enough to update xkb_state
mask when we get key event.
See also https://xkbcommon.org/doc/current/md_doc_quick_guide.html .
Fixes: QTBUG-95933
Pick-to: 6.4 6.3 6.2 5.15
Change-Id: Ie1e82c19edd777630c7f9057a3b2b8b7cad59e38
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Previously trying to execute a test function with an unknown data tag
would print an error message but exit with 0.
This patch stores a test failure, and continues trying to execute the
rest of the command line arguments, if any. In the end the process exits
with the usual exit code (number of failed tests) which is now !=0.
Pick-to: 6.4 6.3 6.2
Fixes: QTBUG-24240
Change-Id: Id4d422035f173e01e77ca88028dfd94dc0f9085c
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
when deploying user applications with QML modules located under user's
subdirectories, (e.g. some third-party QML components used as git
submomdule). The qmldir for such QML modules will be, typically,
generated under BUILD_DIR/android-qml.
if a BUILD_DIR is under the source directory, androiddeployqt will skip
those QML modules incorrectly because they "appeared to be under the
QML root path so that seems can be imported", however without deploying
them, it's impossible to import those modules on an Android device.
this patch adds a check that also tests if a root path plus the module's
url can actually lead to the correct module path, so a QML module under
android-qml subdir would not pass the test, and thus won't be skipped.
Task-number: QTBUG-103593
Pick-to: 6.4 6.3
Change-Id: I8af76bd38cd55700e17794cf2fff0e50a90ac87e
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
A single examined pixel might have sampled corners outside the logical
constraints, that needs to be ignore.
Pick-to: 6.4 6.3 6.2
Fixes: QTBUG-92485
Change-Id: I105fd42d3388a48f3bb03c00d640832e8e99477c
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
Under fractional scaling, an N units wide rectangle can in general
cover either M or M+1 pixels, depending on placement. For a tall thin
recangle like the cursor, this difference becomes very visible as the
cursor moves from position to position. Avoid by instead painting the
cursor as a cosmetic line in such cases, since that keeps its width
independently of the current transformation.
Fixes: QTBUG-95319
Pick-to: 6.4 6.3 6.2 5.15
Change-Id: I31a31f89fe7eac3037694946aa452a9f2bd6e5be
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
It's never been entirely sound or necessarily correct to use single-dash
options for long options. Various other things invoked by androiddeployqt
seem to provide only single-dash options, but llvm tools and GNU tools
always provide a double-dash option. Therefore we can just change the
--needed-libs option to use double-dash without any particular version
checks or differences.
Task-number: QTBUG-104580
Pick-to: 6.4 6.3 6.2 5.15
Change-Id: I5649b0f9565989157d934c802da1f3c4c43fca0f
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
This convenience should be, according to the Apple docs, equivalent to
calling present from a scheduled handler. (which on its own makes it
unclear why we switched in the first place)
In practice it seems the two approaches are not identical. It looks
like that once a frame is submitted earlier than the next display link
callback, the throttling behavior we implement in beginFrame()
(waiting on the semaphore for the completion of the appropriate
command list etc.) starts exhibiting unexpected behavior, not
correctly throttling the thread to the refresh rate. Changing back to
presentDrawable does not exhibit this at all.
The suspicion is that presentDrawable is probably doing more than what
the docs suggest, and so is not fully equivalent to calling present
manually from a scheduled handler.
Therefore, switch to presentDrawable now, which restores the expected
cross-platform behavior, but make a note of the oddity, and also
prepare the hellominimalcrossgfxtriangle manual test to provide an
easy, self-contained application to allow experimenting in the future,
if needed.
This allows Qt Quick render thread animations to advance at the
expected speed (because the render thread is correctly throttled to
the refresh rate), even if the render thread decides to generate a new
frame right away, without waiting for the next display link update.
Without this patch, attempting to get updates not via requestUpdate(),
but by other means (timer etc.) leads to incorrect throttling, and so
the triangle in the test app is rotating faster than expected - but
only with Metal. Running with OpenGL on macOS or with any API on any
other platform the behavior will be correct. Even if scheduling
updates without display link is not efficient, and should be
discouraged, not doing so cannot break the core contract of vsync
throttling, i.e. the thread cannot run faster just because it renders
a frame not in response to an UpdateRequest.
Amends 98b60450f7 (effectively reverts
but keeps the code and the notes because we might want to clear this
up some day)
Pick-to: 6.4 6.3 6.2
Fixes: QTBUG-103415
Change-Id: Id3bd43e94785384142337564ce4b2644bf257100
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The class actually also avoids filtering the tab and backtab keys for
the mentioned classes: QTextEdit and QPlainTextEdit.
So, the documentation needs to be extended to cover the hidden gems.
Pick-to: 6.4 6.3 6.2
Change-Id: Id993b055a105c6cfe5ee57be3863ce8bff448396
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Merge all the existing checks into a single one, which is a simple pass
or fail, since all our supported compilers support all the intrinsics up
to Cannon Lake. The two I've recently added (AVX512VBMI2 and VAES)
aren't yet supported everywhere, so they stay.
For some reason, all intrinsics seem to be disabled on Android. It looks
like some support was missing during the CMake port and this was never
again looked at. I'm leaving it be.
As for WASM, discussion with maintainers is that the WASM emulation of
x86 intrinsics is too hit-and-miss. No one is testing the performance,
particularly the person writing such code (me). They also have some
non-obvious selection of what is supported natively and what is
merely emulated. Using the actual WASM intrinsics is preferred, but
someone else's job.
Change-Id: Ib42b3adc93bf4d43bd55fffd16c10d66208e8384
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
This will stop working with the next commit, which merges all basic x86
SIMD intrinsics into one configure test. As a result, linking almost
anything graphical on iOS (which is almost everything) causes the linker
to fail with undefined references to SIMD-optimized versions that didn't
get compiled.
Change-Id: Ib42b3adc93bf4d43bd55fffd16c288f4104a6ccc
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
35ddf34988 added QMenu::menuInAction, but
the documentation added to cover it contains a typo.
The method added to replace QAction::menu() is menuInAction, not
menuForAction. It was probably just an oversight.
Pick-to: 6.4 6.3 6.2
Change-Id: I2a6ec846bbe7ac8dd9e0c285bc62dd7e08820459
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
