When the Command key is pressed AppKit seems to do key equivalent
matching using a Latin/Roman interpretation of the current keyboard
layout.
For example, for a Greek layout, pressing Option+Command+C produces a
key event with chars="ç" and unmodchars="ψ", but AppKit still treats
this as a match for a key equivalent of Option+Command+C.
We can't do the same by just applying the modifiers to our key map,
as that too contains "ψ" for the Option+Command combination. What we
can do instead is take advantage of the fact that the Command modifier
layer in all/most keyboard layouts contains a Latin layer. We then
combine that with the modifiers of the event to produce the resulting
"Latin" key combination.
If the unmodified key is outside of Latin1, we also treat that as a
valid key combination, even if AppKit natively does not. For example,
for a Greek layout, we still want to support Option+Command+ψ as a key
combination, as it's unlikely to clash with the Latin key combination
we added above.
However, if the unmodified key is within Latin1, we skip it, to avoid
these types of conflicts. For example, in the same Greek layout, pressing
the key next to Tab will produce a Latin ';' symbol, but we've already
treated that as 'q', thanks to the Command modifier, so we skip the
potential Command+; key combination. This is also in line with what
AppKit natively does.
Fixes: QTBUG-96371
Fixes: QTBUG-79493
Task-number: QTBUG-112736
Change-Id: I30d678c1c7860642d3eed29c7757133ff74c6521
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
An incoming key event with a set of modifiers can potentially match
a range of key combinations, depending on how the event's modifiers
are combined to produce "intermediate" representations of the event.
For example, given a normal US keyboard layout, the virtual key
23 combined with the Alt (⌥) and Shift (⇧) modifiers, can map
to the following key combinations:
- Alt+Shift+5 (Fully expressed combination)
- Alt+% (Shift consumed to produce %)
- Shift+∞ (Alt consumed to produce ∞)
- fi (Shift and Alt consumed to produce fi)
But in other cases the intermediate modifier combinations
produce the same key/symbol as other modifier combinations.
For example, pressing Alt (⌥) and Shift (⇧) with the 'c'
key on a US layout will produce:
- Alt+Shift+C (Fully expressed combination)
- Shift+Ç (Alt consumed to produce Ç)
- Ç (Shift and Alt consumed to produce Ç)
In this case, we don't want to reflect the standalone 'Ç',
as that has already been reflected in the more direct form
via Shift+Ç. Consuming the additional Shift modifier does
not produce any additional symbols.
The same can happen without the number of modifiers being
different, in case two modifiers produce the same symbol.
In this case we want to prioritize Command over Option
over Control over Shift.
There is similar logic in the Windows and XKB key mappers,
and the implementation in the Apple key mapper has been
adapted from the Windows key mapper.
Task-number: QTBUG-67200
Task-number: QTBUG-38137
Change-Id: I4f1aeebac78a5393f8da804b53cf588f7c802c1b
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
If the native method contains a jfloat parameter, I get
the warning/error:
Second argument to 'va_arg' is of promotable type 'JNITypeForArg<float>'
(aka 'float'); this va_arg has undefined behavior because arguments will
be promoted to 'double'
Change-Id: I8e8ee256b9bea01585b5f70554ba2fc537e2c94d
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Amend 1aba24a2ed and add check for the
EGL_DRM_MASTER_FD_EXT now used as older egl headers might not have it.
Pick-to: 6.6 6.5
Change-Id: I98b860d05396c24b8eb0e73172ac395c89da8628
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Reviewed-by: Alex Bu <alex.bu@qt.io>
It's explicitly undefined behavior to pass release/acq_rel
memory_order to load(), so don't.
This is private API, so no ChangeLog needed.
Reported-by: Fabian Kosmale <fabian.kosmale@qt.io>
Task-number: QTBUG-115107
Pick-to: 6.6 6.5
Change-Id: Iee119303d790c31937238ef92d900a25020e9713
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
... by making it thread_local.
It is written and read by multiple threads at the same time, so it needs
to be protected. Since signal emission start and end happens in a single
thread, keep it thread_local rather than using an atomic.
Pick-to: 6.6 6.5
Change-Id: I98fc5438c512b45f936318be31a6fccbe5b66944
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
... by making it thread_local.
As a natural (and welcome) side-effect, this makes output look sane in
multithreaded scenarios.
As for why it should be thread_local instead of an atomic:
Since signal emissions and slot invocations on one thread are not
necessarily correlated with another thread, they should not affect
one another's indentation level. As in, emitting QIODevice::readyRead
on a background thread should not make QEventLoop::aboutToBlock on the
main thread be indented. The only exception to this is BlockingQueued,
where one thread is directly tied to another (QTBUG-118145). But slot
invocations are anyway not currently printed for Queued connection
(see QTBUG-74099.)
Pick-to: 6.6 6.5
Change-Id: Iea1fc522d37626df14af419a3455a732729edf74
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
QT_NO_OPENGL is defined in qtgui-config.h so we should include it before
checking the definition.
Fixes: QTBUG-115446
Pick-to: 6.5 6.6
Change-Id: I29b9d7d89fe4c079ca0cf767a1b1a63cc5621623
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
We were using the .remove(Key) API on the map instead of
erase(iterator), so we were removing any reply of the same priority that
had not yet been popped from the queues.
Rewrote to drop loop and only work with iterators.
This issue was there since SPDY days, so not picking all the way back to
5.15, where HTTP2 anyway is not enabled by default.
As a drive-by, drop the #ifndef QT_NO_SSL, which was also there from
SPDY times, which was TLS-only.
Pick-to: 6.6 6.5 6.2
Fixes: QTBUG-116167
Change-Id: Id7e1eb311e009b86054c1fe3d049c760d711a18a
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Implements an iterator API and other standard member access functions
for sequential containers so that we can use ranged-for over an object
that is a jarray. Provides read-only access to individual elements
(which is mostly relevant for arrays of objects), or the entire data()
as a contiguous memory block (which is useful for arrays of primitive
types).
QJniObject call functions can return QJniArray<T> when the return type
is either explicitly QJniArray<T> or T[], or their Qt equivalent (e.g.
a jbyteArray can be taken or returned as a QByteArray). If the return
type is a jarray type, then a QJniObject is returned as before.
Arrays can be created from a Qt container through a constructor or the
generic fromData named constructor in the QJniArrayBase class, which
implements the generic logic.
Not documented as public API yet.
Added a compile-time test to verify that types are mapped correctly.
The function test coverage is added to the QJniObject auto-test, as
that already provides the Java test class with functions taking and
returning arrays of different types.
Change-Id: I0750fc4f4cce7314df3b10e122eafbcfd68297b6
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
And some of them are not needed at all.
Pick-to: 6.6
Change-Id: Ia4778c7016573eff3eefc2f6838e458008161da6
Reviewed-by: Christian Strømme <christian.stromme@qt.io>
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>
