Make the QT_D3D_NO_FLIP env.var. have an effect again.
This env.var. has the following effects:
- SwapEffect is set to DXGI_SWAP_EFFECT_DISCARD
- Scaling is set to DXGI_SCALING_STRETCH (no other option with the
blitting legacy model)
- Alpha works without having to deal with DirectComposition, the dcomp
code path is therefore skipped completely in legacy mode
- Requesting a HDR mode behaves incorrectly (there's an unwanted
conversion to SDR or something like that)
- Different window resizing artifacts. Instead of the big black/white
bars, that is typical with the modern, efficient flip swapchains in
non-Qt applications as well, there is a bit of shimmering on the
right side esp. when resizing on the left side. The option of using
the legacy is model provided mainly for users where this is
important.
- Reduced performance due the using the old blitting model, although
that probably won't be visible for many typical Qt applications on
desktop PCs.
Only for D3D11, because D3D12 does not support non-flip swapchains.
Note: this is incompatible with QT_QPA_DISABLE_REDIRECTION_SURFACE.
The reason to reintroduce this option is to provide a way, even if
just as a developer-focused environment variable, to get a behavior
that is identical to other frameworks and non-Qt applications that
still use D3D11 with the legacy swapchain modes in their rendering
engines. This applies first and foremost to window resizing, where
the visual artifacts common with flip model swapchains may be
misunderstood to be caused by Qt. Having a way to opt-in to the
legacy model allows avoiding/clarifying Apples-to-Oranges
comparisons.
Pick-to: 6.6 6.5
Change-Id: I04e46f71a96fa56cace38703e0e9b93b43bfebc7
Reviewed-by: Christian Strømme <christian.stromme@qt.io>
Previously we had some inline c-string literals. But since the parameter
for those is const-ref QString it has to actually allocate the storage
and convert the string to UTF-16.
By putting it as a function that returns a QString constructed
with u""_s, we instead create a cheap non-owning QString that just
refers to the string somewhere in memory.
As a drive-by: move other string-literals into functions as well.
Change-Id: I2f2ca5b979cfa772665fa83689837f991b0c656d
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
There's nothing wrong with device labels starting with a dot. Whether
udev would encode those as \x2e is unknown, but we may as well not tempt
fate in case it has changed or changes in the future.
Also including QDir::System in case udev places the actual device nodes
in /dev/disks/by-label instead of a symlink.
As a nice and intentional side-effect, QDirIterator no longer performs a
stat() in each of the entries, removing the double stat'ing that started
happening with the previous commit.
Pick-to: 6.6
Change-Id: I9d43e5b91eb142d6945cfffd1787681b4cf2bb58
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
In addition to what parseMountInfo() filtered, we also filter entries
with zero total bytes (other than the root filesystem). This avoids
creating yet another QStorageInfoPrivate that may not be used, but most
importantly it avoids calling root() for that check, which would call
parseMountInfo() again.
Pick-to: 6.6
Change-Id: I9d43e5b91eb142d6945cfffd1787538dd3f285d0
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Mine has 41 lines, of which 22 are returned by parseMountInfo with
filtering. That meant the file was parsed once to get the listing, then
22 times more to create a QStorageInfo for each entry. Now
QStorageInfo::mountedVolumes() opens the file and parses it only once.
Pick-to: 6.6
Change-Id: I9d43e5b91eb142d6945cfffd178752ef6c2122f2
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Nothing here is empty and even if anything were, QStringBuilder properly
handles empty strings.
In static member function ‘static void QConcatenable<QByteArrayView>::appendTo(QByteArrayView, char*&)’,
inlined from ‘static void QConcatenable<QStringBuilder< <template-parameter-1-1>, <template-parameter-1-2> > >::appendTo(const type&, T*&) [with T = char; A = QByteArrayView; B = const char (&)[20]]’ at qstringbuilder.h:398:37,
inlined from ‘T QStringBuilder< <template-parameter-1-1>, <template-parameter-1-2> >::convertTo() const [with T = QByteArray; A = QByteArrayView; B = const char (&)[20]]’ at qstringbuilder.h:117:54,
...
qstringbuilder.h:178:19: error: ‘void* memcpy(void*, const void*, size_t)’ forming offset [1, 5] is out of the bounds [0, 1] of object ‘QByteArray::_empty’ with type ‘const char’ [-Werror=array-bounds=]
QStringBuilder::convertTo() creates the target as
const qsizetype len = QConcatenable< QStringBuilder<A, B> >::size(*this);
T s(len, Qt::Uninitialized);
We know len can't be zero because GCC is complaining about a memcpy()
when the offset has been changed from 0, meaning QByteArray was given a
non-zero size and therefore its data pointer is not &QByteArray::_empty.
Fixes: QTBUG-116763
Pick-to: 6.5 6.6
Change-Id: I85599ea5ca7a4b79a8bbfffd178af437984080fb
Reviewed-by: Shawn Rutledge (away) <shawn.rutledge@qt.io>
Use the pre-existing MSVC code path, which uses UCRT.
warning: 'tzname' is deprecated: Only provided for source compatibility; this variable might not always be accurate when linking to UCRT. [-Wdeprecated-declarations]
Pick-to: 6.6
Change-Id: I8f3ce163ccc5408cac39fffd178dc618f1a8f034
Reviewed-by: Samuel Gaist <samuel.gaist@idiap.ch>
The current example shows a minimal implementation. However, neither
this example nor the documentation explains what happens without the
guard. Although it's not mandatory, the large majority of the time
it's a good practice to have it. This patch improves this part.
Change-Id: I411a9d66bd7d8ba16aac87e28b5cab219fd71a5d
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
This base class implementation for COM objects provides IUnknown
interface implementation with reference counting which will allow to
keep all this functionality and implementation in the same place.
Pick-to 6.6 6.5
Change-Id: I8ec597b1040ac33295317e06338ffdcb61b78f85
Reviewed-by: Jøger Hansegård <joger.hansegard@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Mention that QtMessageHandler needs to be reentrant,
as well as other caveats. Mention QLoggingCategory,
so people do know that they don't have to necessarily
implement their own handler to filter messages (and that
not all messages reach the handler). Also mention
qFormatLogMessage().
Finally, give a more useful example for a custom
message handler that logs to a file. Note that the example
leaks a file handle at exit, but that is arguably not that
bad.
Pick-to: 6.5 6.6
Change-Id: I5be44167b266c9bbdbb0e94806bb024c9b352a32
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Since https://gitlab.kitware.com/cmake/cmake/-/merge_requests/8840 is
merged, the timestamp file for {target}_json_file.txt should be updated
for `multi-config` builds too.
A possible error message before this commit when `qt6_extract_metatypes()` is called with a newer
or equal version than `3.28` `CMake` and `Ninja Multi-Config`.
```
ninja: error: 'src/corelib/Core_autogen/timestamp', needed by 'src/corelib/meta_types/Core_json_file_list.txt', missing and no known rule to make it
```
Amends 8042bfba47305352627d910930e52da496904c17
Pick-to: 6.2 6.5 6.6
Change-Id: Ib404bd058d5f4c75501fb714c2ad9608d6852822
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Queued signals from main thread were not handled if enqueued on
a different thread. This is because qt_jspi_can_resume_js was
called on a thread (worker), where the Module object does not have
the property used for determining whether JSPI is suspended.
Change-Id: Icbc4dbfcf46c1091eb71b23c7de50760c8a339ae
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Fix some issues for QProgressBar with fusion style:
- no progress text was shown in vertical mode
- the color change for the text was not correct in rtl mode
- the two rounded rects were not drawn correctly in some modes
Also simplify the code by also using a QTransform for rtl mode and not
only for the vertical mode.
Fixes: QTBUG-117904
Change-Id: I1dd89daf34e8808417750f2ca714252afdab1416
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
On some configs (e.g. using Snap) the NetworkManager service is not
available without some manifest or similar. In this case, the
_interface_ we have is still valid but we can't connect to the
service. So we need to mark the interface as invalid in this case, so
that we can avoid trying to use this plugin.
Pick-to: 6.6 6.5
Fixes: QTBUG-117490
Change-Id: I3c5ebb492f9ca4dfdf4353d77705ba993279eb69
Reviewed-by: Ilya Fedin <fedin-ilja2010@ya.ru>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
The previous attempt to record a dependency on the
IntegrityPlatformGraphics target for the Gui target was insufficient.
Aside from a qt_find_package(PROVIDED_TARGETS) call, we also need to
use qt_internal_extend_target(Gui PRIVATE IntegrityPlatformGraphics)
to ensure the dependency is written into the Qt6GuiDependencies.cmake
file.
Replace the target_link_libraries call with qt_internal_extend_target,
and remove the qt_find_package all together. A qt_find_package call
in src/gui/configure.cmake already exists, so the one in
CMakeLists.txt is redundant and can be removed.
Finally the
qt_internal_extend_target(Gui PRIVATE IntegrityPlatformGraphics)
call will also result in a
target_link_libraries(Gui INTERFACE
$<LINK_ONLY:IntegrityPlatformGraphics::IntegrityPlatformGraphics>)
because Gui is a static library when building on Integrity, so the
transitive requirement will still be passed along to user projects.
Amends c03eb94c8a
Amends 8116fdde1c
Pick-to: 6.6
Fixes: QTBUG-118051
Task-number: QTBUG-102883
Change-Id: Ic962df94a20071d3f2459e705dbafaca0319a638
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
When QDoc reads an `\fn` command it saves it to a file to parse it with
Clang, with the objective of using the produced AST to perform certain
sanity checks on the documented element.
Generally, `\fn` commands that do not represent correct C++ code are
accepted as long as Clang is still able to build an AST Node that QDoc
can work with, not resulting in any issue in the output documentation.
For example, an `\fn` that doesn't state a return type might be able to
be parsed correctly enough by Clang to produce a sensible Node for the
function that QDoc is interested into.
The documentation for `QDBusReply::value` make
use of this possibility by not stating a return type.
Up to Clang 15 this was not an issue, and a correct-enough AST was
produced when the `\fn` commands for those methods were parsed.
On Clang 16, Clang chokes on the missing return type, being unable to
recognize the function definition and produce an AST that QDoc can work
with.
This has the effect of losing those documented element in the output
documentation.
To avoid the issue, a return type is now added to the relevant `\fn`
commands.
Task-number: QTBUG-111580
Change-Id: Ia70404c7ad548cb1e144bec99943cf72c990bb83
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
When QDoc reads an `\fn` command it saves it to a file to parse it with
Clang, with the objective of using the produced AST to perform certain
sanity checks on the documented element.
Generally, `\fn` commands that do not represent correct C++ code are
accepted as long as Clang is still able to build an AST Node that QDoc
can work with, not resulting in any issue in the output documentation.
For example, an `\fn` that doesn't state a return type might be able to
be parsed correctly enough by Clang to produce a sensible Node for the
function that QDoc is interested into.
The documentation for the various `QRgbaFloat::fromRgba*` make use of
this possibility by not stating a return type.
Up to Clang 15 this was not an issue, and a correct-enough AST was
produced when the `\fn` commands for those methods were parsed.
On Clang 16, Clang chokes on the missing return type, being unable to
recognize the function definition and produce an AST that QDoc can work
with.
This has the effect of losing those documented element in the output
documentation.
To avoid the issue, a return type is now added to the relevant `\fn`
commands.
Task-number: QTBUG-111580
Change-Id: Id9d8a713caf7d6cbb4d2de1040ce5ea5092f7b14
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
Otherwise it incorrectly changes to a white-ish color when the window
becomes inactive, when native apps keep the accent color.
Fixes: QTBUG-116826
Change-Id: I3837e7ca93a494e60dbe5f1b7f8607b3dd16d29e
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
When QDoc reads an `\fn` command it saves it to a file to parse it with
Clang, with the objective of using the produced AST to perform certain
sanity checks on the documented element.
Generally, `\fn` commands that do not represent correct C++ code with are
accepted as long as Clang is still able to build an AST Node that QDoc
can work with, not resulting in any issue in the output documentation.
For example, an `\fn` that doesn't state a return type might be able to
be parsed correctly enough by Clang to produce a sensible Node for the
function that QDoc is interested into.
The documentation for the various overloads for QList::assign and
QVarLenghtArray::assign makes use of this possibility by not stating a
return type.
Up to Clang 15 this was not an issue, and a correct-enough AST was
produced when the `\fn` commands for those methods were parsed.
On Clang 16, Clang chokes on the missing return type, being unable to
recognize the function definition and produce an AST that QDoc can work
with.
This has the effect of losing those documented element in the output
documentation.
To avoid the issue, a return type is now added to the relevant `\fn`
commands.
Change-Id: Ic1434aaf71c39840c64ce04fbd503c4542dc4f42
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
Makes it clearer what members depend on arguments to the ctor. And
what the initial value of all the members are.
Change-Id: Ie1cd2361955053eaf4c4e6887d23ac245738288d
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mate Barany <mate.barany@qt.io>
We have code in the protocolHandlers that tries to handle this case, but
if we have an error before we create protocolHandler (read: proxy
complains about something) we will assert in debug, or
deref nullptr in release.
Pick-to: 6.6 6.5 6.2
Change-Id: I4bde9c8af0fa96dc11f77ca4d4b5cb84c31b54fa
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
These source files have been ported away from Q_FOREACH but weren't
blacklisted, so un-blacklist them by removing "#undef QT_NO_FOREACH",
and removing them from NO_PCH_SOURCES.
These are the last remnants of the Q_FOREACH blacklisting in QtWidgets.
Task-number: QTBUG-115803
Change-Id: Ib73d668687f64d39fa48397d75a0f342e525c1ad
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
These two QSetS are local to the function, the loop bodies don't modify
them but they can't be made const due to the way they're filled. So use
std::as_const and ranged-for.
Un-blacklist the file, by removing "#undef QT_NO_FOREACH", and removing
the source file from NO_PCH_SOURCES.
Change-Id: I49b852aa865b0321d3e2f617466557d77143a32b
Task-number: QTBUG-115803
Reviewed-by: Christian Ehrlicher <ch.ehrlicher@gmx.de>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
getGestureTargets() first parameter is a QSet created locally at the
call site in deliverEvents(); and the loop body doesn't change it.
Change-Id: I3484f7ecc9d85b22b45a123ccf75316d5316e031
Task-number: QTBUG-115803
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Those QSetS are local to the function, make them const, proving that the
loop bodies didn't change them, and the copy Q_FOREACH took wasn't
needed.
Task-number: QTBUG-115803
Change-Id: Iec2fc31fc060c59760a84dc45baf8fa16f62eb6d
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
The "conflictedGestures" QHash is local to the function, and the code in
the loop body doesn't change it. The "gestures" QList (the value in the
QHash key/value pair) isn't changed in the loop (both the enclosing
for-loop and the for-loop iterating over the QList itself):
- the QGestureEvent constructor takes by const& so it couldn't have
changed the QList
So use a const QList& instead of a copy.
Task-number: QTBUG-115803
Change-Id: I4d7f2f833fe0119b9c1ffa91b0cdba9561025382
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
The enclosing iterator-based loop: the loop body doesn't modify the
`m_objectGestures` QMap (the original loop was using const_iterators),
so port to ranged-for by using asKeyValueRange().
The foreach loop: the loop body doesn't modify the `gestures` QList, so
a simple port to ranged-for.
Task-number: QTBUG-115803
Change-Id: I92ba7ff6ef878d7e4b7115a8fab87e95a6d93182
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Christian Ehrlicher <ch.ehrlicher@gmx.de>
The loop doesn't modify the QHash while iterating over it, so use
std::as_const.
Drive by change: Use asKeyValueRange() to get a key/value pair:
- No need to allocate a QStringList to hold the keys
- Prevent double lookup which happened when hash.value(key) was used
inside the loop body
Task-number: QTBUG-115803
Change-Id: Ic0473c0971089f6ca75d3397209fe1c909e975a1
Reviewed-by: Christian Ehrlicher <ch.ehrlicher@gmx.de>
The loop body doesn't change the QHash, so use asKeyValueRange() and
ranged-for.
Un-blacklist the file, by removing "#undef QT_NO_FOREACH", and removing
the source file from NO_PCH_SOURCES.
Task-number: QTBUG-115803
Change-Id: I22924d2addeed75867edf9f6cac53f1c6f266dcc
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Christian Ehrlicher <ch.ehrlicher@gmx.de>
It was weird that they were missing. Now that C++23 added them to
std::span, add them to QSpan, too.
Pick-to: 6.6
Change-Id: I4a9b1fdeda66bc7b133c8f7b3b269656e5faffa3
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Overload the binary QSet operators |, &, + and - for rvalue LHSs, so
chained operations like e.g. in qgesturemanager.cpp:
QSet<QGesture *> endedGestures =
finishedGestures + canceledGestures + undeliveredGestures + maybeToCanceledGestures;
become as efficient as chained op+= calls.
Make the operators hidden friends as a drive-by.
[ChangeLog][QtCore][QSet] The binary operators &, |, + and - are now
hidden friends, and chaining them has been made a lot more efficient.
Change-Id: I55d2247b11d088eb1ef88608f89d2bf9e1daeb58
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
All these TUs relied on transitive includes of qpointer.h, maybe to a
large extent via qevent.h, though, given that qevent.h is more or less
the only public QtBase header that includes qpointer.h, something else
seems to be at play here.
Said qevent.h actually needs QPointer in-name-only, so a forward
declaration would suffice. Prepare for qevent.h dropping the include.
The algorithm I used was:
If the TU mentions 'passiveGrabbers', the name of the QEvent function
that returns QPointers, and the TU doesn't have qpointer.h included
explicitly, include it. That may produce False Positives, but better
safe than sorry. Otherwise, in src/, add an include to all source and
header files which mention QPointer. Exception: if foo.h of a foo.cpp
already includes it, don't include again.
Task-number: QTBUG-117670
Change-Id: I3321cccdb41ce0ba6d8a709cea92427aba398254
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Follow-up patch for 39d486171b - don't
create a temporary container for the connections but add them directly
into the final one.
Task-number: QTBUG-117698
Change-Id: I6ea3b1a5a834f2581f3929cca13c53f47b8c9805
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
When QDoc reads an `\fn` command it saves it to a file to parse it with
Clang, with the objective of using the produced AST to perform certain
sanity checks on the documented element.
Generally, `\fn` commands that do not represent correct C++ code are
accepted as long as Clang is still able to build an AST Node that QDoc
can work with, not resulting in any issue in the output documentation.
For example, an `\fn` that doesn't state a return type might be able to
be parsed correctly enough by Clang to produce a sensible Node for the
function that QDoc is interested into.
The documentation for `QPromise::emplaceResult/emplaceResultAt` make
use of this possibility by not stating a return type.
Up to Clang 15 this was not an issue, and a correct-enough AST was
produced when the `\fn` commands for those methods were parsed.
On Clang 16, Clang chokes on the missing return type, being unable to
recognize the function definition and produce an AST that QDoc can work
with.
This has the effect of losing those documented element in the output
documentation.
To avoid the issue, a return type is now added to the relevant `\fn`
commands.
Task-number: QTBUG-111580
Change-Id: I7d41fc52720ff8762bf2cce229969b7250e44754
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
This changes takes Qt for Android Java code away from the Delegate
classes that uses heavily Java reflection to invoke Activity/Service
calls and overrides. So instead of that, now, we have a QtActivityBase
and a QtServiceBase classes which handle the override logic needed for
Qt directly without reflection.
These Base classes extend Android's Activity and Service directly, and
are inside the internal Qt android package (under Qt6Android.jar).
For example, to handle onConfigurationChanged, instead of the current
way where we need this in QtActivityDelegate:
public void onConfigurationChanged(Configuration configuration)
{
try {
m_super_onConfigurationChanged.invoke(m_activity, configuration);
} catch (Exception e) {
e.printStackTrace();
}
handleUiModeChange(configuration.uiMode &
Configuration.UI_MODE_NIGHT_MASK);
}
And then this in QtActivity:
@Override
public void onConfigurationChanged(Configuration newConfig)
{
if (!QtLoader.invokeDelegate(newConfig).invoked)
super.onConfigurationChanged(newConfig);
}
public void super_onConfigurationChanged(Configuration newConfig)
{
super.onConfigurationChanged(newConfig);
}
And having to keep it's Method handles around and then use Java
reflection
to call the override behavior done by Qt and the superclass methods.
instead of that, we can do it now in QtActivityBase like:
@Override
public void onConfigurationChanged(Configuration newConfig)
{
super.onConfigurationChanged(newConfig);
handleUiModeChange(newConfig.uiMode &
Configuration.UI_MODE_NIGHT_MASK);
}
Then, we would still have our user facing QtActivity class which extends
QtActivityBase and benefit from the same implementation of Qt logic done
in the base class.
An additional benefit to this approach is that now QtActivity will be
very lightweight and doesn't need to have all the boilerplate code as
before.
[ChangeLog][Android] Simplify Qt for Android public bindings
(QActivity, QtService and QtApplication) by implementing base
classes which use the delegate implementions directly and avoid
reflection.
Task-number: QTBUG-115014
Task-number: QTBUG-114593
Change-Id: Ie1eca74f989627be4468786a27e30b16209fc521
Reviewed-by: Tinja Paavoseppä <tinja.paavoseppa@qt.io>
The m_activityObject and m_serviceObjects are no longer plain
jobjects. Instead they are constructed with a jobject.
The constructor makes it a global ref, which the destructor
then frees. The destruction happens when the stdlib exit()
is called.
However, since the terminateQt() function already had released the
global ref, the destruction of the objects crashes the
application with a JNI APPLICATION ERROR in Android logs.
In addition since the the code only ever freed the reference to
a reference, the actual reference was leaked.
Change-Id: I6bb637dba2de59e89436685a9d63950d36438fa5
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Various constant keys were duplicated in QtActivityDelegate,
QtServiceDelegate and QtLoader classes, and this de-duplicates that.
Task-number: QTBUG-115014
Task-number: QTBUG-114593
Change-Id: I3479fbb58293b26b7625f8653289c6b6d987a59f
Reviewed-by: Tinja Paavoseppä <tinja.paavoseppa@qt.io>
Following the previous change in the chain, this removes override calls
that have no implementation under Qt Delegates, so they can be removed
and
the default behavior would persist.
Task-number: QTBUG-115014
Task-number: QTBUG-114593
Change-Id: Ia7c76e9b56c63cba935cb3d2ae3b6260d3462e51
Reviewed-by: Tinja Paavoseppä <tinja.paavoseppa@qt.io>
Those overrides are deprecated and will print a warning during Gradle
build, moreover, these calls don't have any implementation by Qt that's
being triggered by the Qt Delegates classes, so they don't need to be
kept in the Activity/Service main classes' implementations.
Task-number: QTBUG-115014
Task-number: QTBUG-114593
Change-Id: If0c241206652c1a52e2396a24ec7ab63236e6308
Reviewed-by: Ville Voutilainen <ville.voutilainen@qt.io>
Reviewed-by: Tinja Paavoseppä <tinja.paavoseppa@qt.io>
These forward calls to QtNative don't need to be present inside the
QtActivity implementation, all those calls are invoked by the Delegate
classes.
Task-number: QTBUG-115014
Task-number: QTBUG-114593
Change-Id: Id1bfa694687af3edc4e9b82b09cf13e1f8eba1de
Reviewed-by: Ville Voutilainen <ville.voutilainen@qt.io>
Reviewed-by: Tinja Paavoseppä <tinja.paavoseppa@qt.io>
Move QtLoader classes outside of the bindings package and into
the internal Android Java package (Qt6Android.jar that is), to simplify
Qt for Android project templates. This is because QtLoader classes are
used to trigger Qt libs loading and the users don't need to necessarily
know about it or find it in the project's source files.
The classes in question: QtLoader, QtActivityLoader, and
QtServiceLoader.
Task-number: QTBUG-115014
Task-number: QTBUG-114593
Change-Id: I61f68abf6ee83fc45bc47ed9af7457db4f7deabc
Reviewed-by: Tinja Paavoseppä <tinja.paavoseppa@qt.io>
When building non-qtbase tqtc repos in CI, we don't load a lot of
Plugin Config files in static builds due to project names having a
tqtc- prefix. This is similar to the issue and workaround that was
done in 4c6292686259e4e232f29cb6fd6c79065e9fa96d for qtserialport.
The specific issue here is the following error:
CMake Error at Qt6Gui/Qt6GuiTargets.cmake:61 (set_target_properties):
The link interface of target "Qt6::Gui" contains:
IntegrityPlatformGraphics::IntegrityPlatformGraphics
but the target was not found. Possible reasons include:
* There is a typo in the target name.
* A find_package call is missing for an IMPORTED target.
* An ALIAS target is missing.
Call Stack (most recent call first):
/home/qt/work/install/target/lib/cmake/Qt6Gui/Qt6GuiConfig.cmake:52
(include)
/home/qt/work/install/target/lib/cmake/Qt6/Qt6Config.cmake:157
(find_package)
CMakeLists.txt:15 (find_package)
To work around the issue, explicitly record a dependency on the
IntegrityPlatformGraphics target for Gui when building on INTEGRITY.
The underlying issue is sadly still not fixed.
Change-Id: I9a9cff05d036f224aab8083ad6bc8b8e568abd8b
Pick-to: 6.6
Task-number: QTBUG-102883
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Tatiana Borisova <tatiana.borisova@qt.io>
We need access to bitPosition in order to check if a role was set.
This fixes the following build error:
[...] qwindowstheme.cpp(1150): error C2220: the following warning is treated as an error
[...] qwindowstheme.cpp(1150): warning C4506: no definition for inline function 'QPalette::ResolveMask QPalettePrivate::bitPosition(QPalette::ColorGroup,QPalette::ColorRole)'
Amends 417878904b.
Task-number: QTBUG-116826
Change-Id: I815c7e961198ab93b6ed6132badc2ec693522472
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io>
Check if QCoreApplication::instance() and print a warning if not instead
creating and assertion later on.
Fixes: QTBUG-117621
Change-Id: Iffb4f7097edbbaf19cb584bff6e5ba1535bf88a0
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
It's not needed, and might trigger -Wshadow on some compilers. Only
the public QSpan class has the `extent` static data member, everything
else uses the template argument, `E`, directly.
Amends f82cf6333e.
Pick-to: 6.6
Change-Id: If378119aff1e352d1e90854b570720444cd532a0
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Dennis Oberst <dennis.oberst@qt.io>
