The 3-arg connect is error-prone and makes the lifetime of the
connection unclear.
Change-Id: I43dabe3d25ffc2b711aa50dec525d72a8810861c
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
If moving a window from a screen to another using keyboard shortcuts,
the screen change detection happens after the handleDpiChange() call
which essentially makes Qt think the window stayed on the old monitor.
Instead of checking against currentScreen DPI, check against savedDpi
which should not have this problem.
Task-number: QTBUG-106483
Pick-to: 6.6 6.5
Change-Id: Ic30dc1b16bbaf9306a086c8d3042f5341d3848c1
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Previously, a target name with a JS special character (like, -, for
example), would lead to an invalid export name being generated for
WASM modules. Sanitize these by replacing any non-alphanumeric
character with underscores, as is done for feature names.
Change-Id: I01fbc50bddedd011a9584f673d79d88a3bc09bbb
Reviewed-by: Piotr Wierciński <piotr.wiercinski@qt.io>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Allows easy use from the examples.
Pick-to: 6.6
Change-Id: I731ea5641e247db2937aa1b12d1e91dd7dcb2848
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The dark mode related changes for windows didn't update disabled and
inactive group palettes, and this makes text in certain context
(such as menu bar) appear with enabled color. The windows theme API
populateLightSystemPalette() is responsible for this and it updates
palettes for color roles and certain inactive scenarios but not for
disabled.
This patch set makes existing systemPalette(Qt::ColorScheme) to be
available in QWindowsTheme and it updates palette depending on color
scheme. From now on, this API updates palettes for windows native
style. Its to be noted that window native style use light palette
irrespective of color scheme.
Fixes: QTBUG-114821
Pick-to: 6.5 6.6
Change-Id: Iff4f35900293b8e7030ec121ca21856daa094dc0
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
This is what maps to the Vulkan and Metal backend. Taking the
frame slot from the other swapchain was a mistake. It should use
the frame slot from the current swapchain.
Pick-to: 6.6
Fixes: QTBUG-114826
Change-Id: I1585088ce9a963f1710168d3ebc0d2e5f1e9ab21
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
This should not be there because 'u' is passed to beginPass().
Change-Id: I95ba8ed400baa06948b4d4c6bbf7ca2d07a5480f
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
When a QTextEdit/QPlanTextEdit window loses focus and receives
PaletteChange event, the ColorGroup that controls the palette for
the QWidgetTextControl will be set to 'Inactive'. However, the
QTextEdit does not update the palette when the window is activated again.
This can become more noticeable in applications where different colors
are used for the 'Inactive' and 'Active' ColorGroups.
Pick-to: 6.5 6.6
Change-Id: Idd4dcc55b2bf8e671e7dd9cbd040782e1c3bf1a3
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Gerrit says it refuses to color lines that exceed 500 characters, so
let's split this line to get colors back.
Pick-to: 6.6 6.5
Change-Id: Iab6d37332e27ecdeaf1420da6fa242ca65f0aab5
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
The test needs investigation. Skip it for now so that we can enable
CI for WASM but leave a note to investigate it.
Task-number: QTBUG-109954
Change-Id: I445996e969e7016a4d92a7e70da10b6d84a0fc71
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
The use of Q_ASSERT(false) is bogus as we don't need to test here, but
want to signal unreachability.
Q_UNREACHABLE_RETURN allows us to tell the compiler that the point
can't be reached while also getting rid of the no return error.
Task-number: QTBUG-114689
Pick-to: 6.6 6.5
Change-Id: I007cd243055237bcc21772a4130a6c1a44fd882d
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Two QCOMPARE calls aren't worth the extra indirection.
Change-Id: If3b54d303c28582c7df29a3f1c4dc1a2c2a974f4
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
About the requirement of wrapping unitests in "#ifdef
QT_BUILD_INTERNAL".
Stating the obvious (which wasn't obvious to me until Thiago pointed it
out in code review, so).
Change-Id: If8b3dda43a7034b8304d2b93c0fbedbdbdb184b6
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The 3-arguments overload of connect() is error-prone / easy to misuse:
* it's easy to e.g. connect to a lambda, and capture local state in the
lambda. By not passing a receiver/context, the connection won't get
disconnected if the local state gets destroyed (effectively, it
creates a "dangling connection");
* in a multithread scenario, one may not realize that the connection is
forced to be direct. If the signal is emitted in another thread than
the one establishing the connection¹, then the functor will be invoked
in that other thread. (Not that "the thread establishing the
connection" has ever mattered, but again, this API is error-prone.)
Add a macro that allows users to disable the overload in their project.
I'm not going for deprecation because there's simply too much code
around that uses it.
[ChangeLog][QtCore][QObject] Added the QT_NO_CONTEXTLESS_CONNECT macro.
Defining the macro before including any Qt header will disable
the overload of QObject::connect that does not take a receiver/context
argument.
Change-Id: I86af1029c1a211ea365f417aae9038d3fcacadfd
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The 3-arg connect is error-prone and makes the lifetime of the
connection unclear.
Change-Id: I4f2b54bc086e8f4723a0357d983e3df2f85135ac
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Why do we need this feature: to give user the possibility to explore
different interesting graphics features (currently only compatible
with D3D with the new FLIP model).
Why do we need to modify QPA directly: touch this flag after the
window has been created has no effect. It can only be used when we
call CreateWindow(), so we can't add this flag through SetWindowLong().
However, Qt doesn't provide any public or private interface to
control how Qt call CreateWindow(), and providing such interface
is also dangerous. Using environment variable to control this behavior
is the simplest solution and is commonly used inside Qt code base.
Change-Id: I12440ed498d97cc17640e6c7498e42770b813737
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
When a table view adds its first row, QHeaderView::initializeSections()
is called. It initializes the vertical header view with the number of
added sections. Subsequently QHeaderView::sectionsInserted() is called
with the same amount of newly added rows/sections.
That leads to the initial amount of sections being 2x the number of
rows added in the first go. In other words, the table view will display
at least one row more than the underlying table model has.
This patch adds an OR condition to the early return check at the
beginning of QHeaderView::sectionsInserted(). The method returns early
if the number of sections equals the number of respective sections
(rows in this case) in the model.
An autotest is added in tst_QTableView::rowsInVerticalHeader().
Fixes: QTBUG-114225
Pick-to: 6.6 6.5
Change-Id: I895444f025591981965562e54e2335391db52357
Reviewed-by: David Faure <david.faure@kdab.com>
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
33c88f86b5 added some logic to QAPM in
order to have it automatically emit headerDataChanged when rows/columns
were added or removed in the model. This was done as a stopgap measure
to prevent QAPM from asking for illegal indices in order to implement
automatic remapping of the section headings (since there's no
mapSectionToSource).
The commit seems to have introduced a regression in QHeaderView, which
isn't prepared to receive headerDataChanged while a row/column count
change is in progress. When receiving headerDataChanged, QHeaderView
will try to read the row/column count and will store it internally.
When it will then receive the signals for insertion/removal of
rows/columns, it will interpret it as a modification of the previously
stored value -- even if the value it stored was already correct.
Fix this by avoiding to have two signals in flight at the same time;
emit headerDataChanged as a queued invocation.
Task-number: QTBUG-114225
Change-Id: I521465a852b8c7135f22f730ead41dca760ba428
Pick-to: 6.5 6.6
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Reviewed-by: David Faure <david.faure@kdab.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
The CMakeUserPresets.json file can be used to simplify configuring Qt,
particularly with tools such as Visual Studio and Visual Studio Code.
As opposed to the CMakePresets.json, the CMakeUserPresets.json should
only contain user specific configurations, and should never be checked
into source code management system.
This file is already ignored in the top level Qt super-project, but to
facilitate working with each individual submodule, we should also have
this .gitignore in each submodule.
Pick-to: 6.5 6.6
Change-Id: I383417c7fe9d803aeb0385ba83e8c9cee6181602
Reviewed-by: Miguel Costa <miguel.costa@qt.io>
In the iOS theme, we determine the color scheme based on the the last
UIWindow of the application, but listen to trait changes in the
QUIWindow class. However, the last window of the application is not
always a QUIWindow. Sometimes it can be a temporary UIWindow created
by the system for transitioning or other effects. These kind of windows
do not always follow the appearance of the app and the main window
(QUIWindow), so we were sometimes ending up with the wrong color scheme being reported.
This was happening when the app was put into background for example,
which causes the traitCollectionDidChange method to be called and query
the userInterfaceStyle of the last window to determine if the color scheme was changed. The queried window would sometimes end up being of type UITextEffectsWindow, etc. and report the wrong appearance.
To fix, always make sure to get the appearance from a QUIWindow.
Fixes: QTBUG-114571
Fixes: QTBUG-113169
Fixes: QTBUG-114191
Pick-to: 6.5 6.6 6.5.2
Change-Id: Ic0b29c02c8e8100996d5cd31b37e6a5b839f5fb1
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
INTEGRITY has a pre-P1115 implementation of std::erase/erase_if that
returns void instead of the number of erased elements, so make q20's
implementation more specialized, so the compiler will pick it over
INTEGRITY's (Marc's idea from the code review).
Change-Id: I88d025a3f90cdd65f5bb73beb8a39e32ccf12d9b
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
... like QUIP-0019 suggests.
The main problem here is finding these classes. We don't have markup
for RAII classes, so I had to find them by name. This patch is based
on the output of
git grep -we Q[A-Z0-9a-z_]+er
extracting the matches and piping them through sort -u, then removing
a lot of suffixes like Manager and Handler, then visually inspecting
the remaining list.
Task-number: QTBUG-104164
Pick-to: 6.6
Change-Id: I59b18d8d0a0237fcc11047857adc39b984ad7fcb
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Wrappers around P1301 [[nodiscard("reason")]].
[ChangeLog][QtCore][Q_NODISCARD_X/Q_NODISCARD_CTOR_X] Added as
wrappers around C++20 [[nodiscard("reason")]].
Task-number: QTBUG-114767
Change-Id: Ie566d9c9d500ef632c7e243af97081f83506a752
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
If we are already disconnected we end up printing warnings about how it's
illegal to call waitForBytesWritten on an unconnected socket
Change-Id: I8c864d105d5372edfee84affb362cca3021b8ea0
Reviewed-by: Konrad Kujawa <konrad.kujawa@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Only when available at build time (dxcapi.h) and at run time
(dxcompiler.dll, ideally with dxil.dll).
The catch is that the latter will not be true in a typical Windows
system. Unlike the legacy d3dcompiler_47.dll the dxc stuff is just
not there. It is unclear what we can do about it. In the meantime
one needs to go to https://github.com/microsoft/DirectXShaderCompiler/releases
and get the DLLs.
Fixes: QTBUG-114773
Change-Id: I6e68fdd1e47505187036b47d6f3e7fe9cc4ee8dc
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Only for dev and 6.6, includes D3D12.
6.5 has its own dedicated version of the patch.
Fixes: QTBUG-114775
Task-number: QTBUG-114115
Pick-to: 6.6
Change-Id: I36c96e046ba611b228fd5c320e5780ca4d180165
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
This relies on qsb being able to invoke dxc instead of fxc when the
request HLSL (shader model) version is 6.1. (6.1 is required for
SV_ViewID) This currently works only when conditioning offline with
qsb (or via CMake), because qsb can easily invoke dxc instead of
fxc. When shipping HLSL inside the .qsb package (so when -c is not
specified or running the external tool fails), this won't work since
the D3D12 backend still uses D3DCompile(), not IDxcCompiler. Support
for that will be investigated separately.
We also need to bump to ID3D12Device2 and ID3D12GraphicsCommandList1.
With Windows 10 version 1703 being quite old now, this should not be a
problem at run time.
There are however issues at build time, namely that MinGW and
MinGW/LLVM and similar seems to have ancient Windows SDK headers
according to the CI test runs. None of the MSVC configurations have
this in the CI, they have reasonable versions of d3d12.h and similar.
Therefore, one important aspect of this change is that the D3D12
backend of QRhi will only be available from now on when the SDK
headers are new enough (meaning ID3D12Device2 is declared, which is a
several years old type now). Otherwise, QRhi::create() will simply
fail when asking for D3D12 with a helpful warning message about the Qt
build being crippled.
Implementation-wise, there are surprises in store as well:
The way the PSO is created needs to be revamped to follow the
extensible approach that uses a pipeline state stream
description. Both the graphics and compute pipeline creation is
changed to use CreatePipelineState() and the associated
machinery. This is only really essential for graphics pipelines since
we know have to include data for view instancing (multiview). For
compute the result is the same as before.
Additionally, the view count must now be baked into the
QRhiGraphicsPipeline. This means that applications must call
setMultiViewCount() with the same value (typically 2) *both* on the
render target's color attachment and on the pipeline. Backends that do
not care about the pipeline's view count (GL, Vulkan) will of course
ignore it, but if it's not set correctly D3D12 will fail. The manual
test is updated accordingly.
Fixes: QTBUG-114772
Change-Id: I93db7313377e711c2faeb956815899b12132d23b
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
Under some circumstances, MSVC seems to complain about SlotArgumentCount
being unused
qobject.h(210): warning C4189: 'SlotArgumentCount': local variable is
initialized but not referenced
note: see reference to function template instantiation
'QMetaObject::Connection QObject::connect<void(__cdecl QAction::* )(bool),
main::<lambda_1>>(const QAction *,Func1,
const QtPrivate::ContextTypeForFunctor<main::<lambda_1>,void>::ContextType *,
Func2 &&,Qt::ConnectionType)' being compiled
This is nonsense, as SlotArgumentCount is used in the next line, to
construct the list of signal arguments, but the workaround to declare
the variable as [[maybe_unused]] is trivial.
Add a connect statement to the test case that creates such a connection.
This does not produce any warning with or without the attribute (and if
it did, the build would fail for CI configuratinos setting -Werror).
Pick-to: 6.6
Fixes: QTBUG-114781
Change-Id: I4ee6f7d57c2836ef3dd9741d037d48181af2cdec
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Adding some Qt Design Studio macros for global
qtdoc use. This would ensure flexibility for
the documentation writing.
Pick-to: 5.15 6.5 6.6
Task-number: QDS-10142
Change-Id: Id61a68d124aad1b8c8f9e17358fb5990efbab5de
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
Previously, Qt would always ignore user's custom QSurfaceFormat
settings and this behavior makes user have no way to control
the preferred OpenGL version when running on WASM. And after reading
the wasm platform plugin code, I don't see any reason why we should
limit ourself to the default OpenGL version. And I've tested this
patch locally, Qt still work normally if I set a newer OpenGL version.
Pick-to: 6.6 6.5
Change-Id: I0cfb831d6a722fe61cc85808a6d9e3098c73d82e
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The concatenated byte array is already the "size" we want.
Drive-by change: use QByteArray::sliced()
Change-Id: Id0afb45ae1daf08bd125230eef0734770c645e1a
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Change Generator::generateSignal() to take by const FunctionDef*, so
that it can be called with the return of QList::at().
Change-Id: I5ffb0726a5ded6561e0000a2bea1973ada675152
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
No need to copy the 3 QLists to iterate over them.
Change-Id: Id0fc7d39012bdaa78e51b1153565df77c7fb889a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
By handling the special case before entering the loop, then it can
become a range-for, which fixes a narrowing conversion warning, and it
becomes more readable.
Change-Id: I6ce0181c95eae01a4f2bb7cd12fb5cbeba378586
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Yes, the code now uses two loops, but it's slightly better than
erasing-during-iteration; the alternative is using e.g. a while loop and
advancing an iterator manually with operator++() (in two separate
locations, since there would be a `continue` statement) or with the
return value of QList::erase (in one location).
Change-Id: I119d0e61bc06396f2158ecf9f4ae84a76d9bce7b
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Instead of changing the "index" member then restoring it, add a
symbolAt() method to get the Symbol in question, and pass it to
new warning() overload.
Change-Id: Ie84a6cf4d837f4ed694f617100e9556c2fc2eea3
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
