The most common limit for the maximum number of allowed documentation
warnings is zero. Use a global value for 'warninglimit', adopted by
all Qt module documentation projects that include the configuration
from qtbase/doc/global.
This allows for a temporary increase of the limit across all modules as
needed - for example, when updating the QDoc binary that the CI
provisions to a version that introduces new types of documentation
warnings.
Increase this base limit temporarily to 10 to help re-enable
documentation testing in CI as it's currently disabled.
Task-number: QTBUG-113326
Change-Id: I8b66951ca9324bcfaec3b5a7ec2cff544c62feb0
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
Some shortcomings and unexpected problems are not unlikely.
The basic feature, with 2 views going to a texture array's
0 and 1 elements, seems to be working with macOS, also with
MSAA. Instanced drawing has not been verified. (relevant
because layered rendering works via instancing in Metal
and the QRhi backend has to adjust the instance count
in every draw call)
Fixes: QTBUG-114774
Change-Id: I3655e0d2c658b88c4cd6b52a32f94134324e4ac9
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
Just handling attachments with a render buffer set and only one
attachment is not what other backends do. They support all attachments
and also the cases of multisample (2D) textures and multisample texture
arrays.
By extension this allows multisample 2D texture arrays. (GL 3.2+/GLES
3.1+) This was previously not working probably since the correct texture
target was never used.
Pick-to: 6.6
Change-Id: Ibe929faaf86824a596f9794240d1becc51f68e43
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
Follow what got documented in the previous patch.
Task-number: QTBUG-114790
Change-Id: I3e8b3028639c3e4edd39eb0f9446f7eae5f96f3b
Reviewed-by: Andy Nichols <andy.nichols@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>
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>
Setting color scheme before handling theme change provides incorrect
palette color when user switches from light to dark or dark to light.
This is visible when using Fusion style (or other style that supports
dark mode) in Windows. The change has been made as part of patchset
787038bb1d.
It also has to be noted that handling palette changes to make further changes to the palette (or the style sheet), is less likely than
Handling the colorScheme change signal and in this sense, this patch set
can also be considered as an improvement.
This patchset reverts that change and updates color scheme after palette change in the application.
[ChangeLog][QtGui][ColorScheme] Update colorScheme property after
palette change.
Fixes: QTBUG-112653
Pick-to: 6.5 6.6
Change-Id: I71bc413c56663fefdf9fe5871bbb19b7e6c3d9ff
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Make it so that what we query with regards to 1.1, 1.2, and 1.3 features
are stored for later use. This will be relevant for e.g. multiview where
the multiview field will need to be checked when deciding if the feature
is supported at run time.
All this is only really compatible with Vulkan 1.2 and newer. Vulkan 1.1
does not have the 1.2 approach, i.e. there is no
VkPhysicalDeviceVulkan11Features
in Vulkan 1.1 (!). That is a struct added in Vulkan 1.2. In 1.1 one had
the feature (extension) specific structs, such as
VkPhysicalDeviceMultiviewFeatures
in case of multiview. That we do not bother with at the moment.
Then again that's nothing new. The existing code to enable all features
with a few exceptions, that's already tied to the 1.2+ way of working
with physical device features, and not quite compatible with a pure
1.1 (not 1.0, not 1.2+) implementation (which should be hopefully rare
out there).
Pick-to: 6.6
Change-Id: I661f2634651d28edd9b5feec66a423220920f894
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
It has no purpose (like Alt+Enter is not functional anyway when we
created the swapchain for composition), and with D3D12 there is a
warning printed (with the debug layer enabled?) about this. So move
the call to the appropriate branch.
Pick-to: 6.6
Change-Id: I266ae6835bcc49b3ba8d84e5d08ab9115c6401e0
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
Fixes QDoc warning: 'Documentation for class has no \inmodule command'
for both classes.
Pick-to: 6.6
Change-Id: I59eb5f5b935ea30f756d655158a06f390d2ebc54
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
... and make it a hidden friend.
This avoids ODR violations when, because they can't use ours (private,
and not exported), users try to produce their own version of
qHash(Key).
[ChangeLog][QtGui][QPixmapCache] Made the qHash() overload for
QPixmapCache::Key public (was: private) API.
Pick-to: 6.6
Change-Id: I324ed001c0ae0a251ac2e1d04713013452ffff9c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
This is not scalable. Instead of putting parts of post-1.0 vulkan_core.h
into this header, apply the appropriate ifdefs instead.
Pick-to: 6.6
Change-Id: I21a9d6f7c51169efa7b66705545bae192ed30c14
Reviewed-by: Christian Strømme <christian.stromme@qt.io>
Just in case someone includes the private headers outside of Qt.
Pick-to: 6.6
Change-Id: I79232d2bab7604c71c31226a67ec3ef40210d161
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Without this patch, the compiler will complain about can't find
"qshaderdescription.h" when using "qrhigles2_p.h" from outside of
Qt, which breaks user project compilation.
Pick-to: 6.6
Change-Id: I9e201d82890c92ddd2f6aad48eef0edc9a7c46ef
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
It's not a real leak in that the string data is being freed on program
exit (or, more recently, QPixmapCache::clear()), but it can lead to
lots of memory being bound for much longer than expected when users
put in new QString keys without attempting to retrive them again. It
can also lead to problems with QStringLiterals lingering around until
after their underlying data has been freed. A bug in the Fusion style,
generating new string keys for identical state, exposed this
misbehavior, and one way to fix the resulting issue for the user is to
make sure that QPixmapCache doesn't leak QString keys.
The Fusion style issue with generating non-repeating keys for use with
QPixmapCache should also be fixed, eventually, but this patch
relegates that to an optimization issue (the caching is effectively
non-existent), the resource exhaustion is gone now.
The issue exists because the QString keys are internally mapped to
QPixmapCache::Key's by way of a QHash<QString, Key> cacheKeys data
structure. When the QCache, indexed by Key, not QString, decides to
evict an entry, the Key is invalidated, but no-one was removing the
corresponding entry from cacheKeys. So make the existing releaseKey(),
used to invalidate copies of Keys referring to evicted pixmaps, do
that, now. So as not to have to scan the whole cacheKeys QHash for the
right Key, store the QString key, if any, inside the Key, so
releaseKey() can retrieve it and use it for O(1) erasure from
cacheKey.
This allows removing the previous work-around in clear()
(6ab0d25a09), greatly simplify
object(QString), and requires to rewrite all code that holds iterators
or references into cacheKeys over an insertion into or removal from
the QCache. Two (insert() and remove()) have already been done in
prequel commits, so only flushDetachedPixmaps() was left.
Fixes: QTBUG-112200
Pick-to: 6.6 6.5
Change-Id: Ic93b0ed388ae963267fe242b491c6c941d146b99
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Implement insert(QString, QPixmap) in terms of insert(QPixmap) to
avoid duplicating code and to separate concerns: insert(QString,
QPixmap) is now only dealing with the cacheKeys, insert(QPixmap) is
only concerned with the Key-based lookup.
Task-number: QTBUG-112200
Pick-to: 6.6 6.5 6.2
Change-Id: I30394da43a5e93b7bd41ef9ce9c7aea044523c30
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The previous code used `cacheKey` as the name of an iterator, which
made the code hard to understand.
Instead of renaming that to the more idiomatic `it`, use QHash::take()
to get an actual `cacheKey` back, and then delegate to
QPMCache::remove(QPixmapCache::Key) for the actual removal.
Pick-to: 6.6 6.5 6.2
Task-number: QTBUG-112200
Change-Id: I9311c19f12a05cad694702672f17ae19ba339b04
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
It was always 0
Task-number: QTBUG-113679
Pick-to: 6.6
Change-Id: I090036296ad2df99b986400863b1e57a5d6101fb
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
Since they don't contribute to the width of a string then we may
accidentally end up ignoring the potential left-bearing that the first
non-zero-width glyph has.
Task-number: QTBUG-113679
Pick-to: 6.6
Change-Id: I8e89a428acf5d0a3da0255c50778ccc773ff20e1
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
The lack of 0x adornment made hex confusing. `xinput list` shows device
IDs as decimal, and device IDs appear in decimal in some categorized
qt.qpa.input.devices log messages, so let's be consistent here too.
Also fixed one more that was inconsistent in that category:
"scroll event from unregistered device <x>"
Change-Id: I98a39b30b1bc030611d3cfe9dd5e95886faf48ff
Pick-to: 6.5 6.6
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
We want to pass the QPointingDevice* because we've already identified
it by its "system ID" (xinput device number). The other versions of
handleTabletEnterProximityEvent and handleTabletLeaveProximityEvent
try to identify the stylus by only its deviceType, pointerType and
unique ID, which can go wrong if there are multiple tablet devices and
the unique ID is not provided (as with N-trig and Wacom tablets being
used at the same time). Anyway this fixes a TODO comment from
6589f2ed0c
Leave a "deprecated" comment by the QWSI functions that should not
be used.
Pick-to: 6.6 6.5
Task-number: QTBUG-104878
Change-Id: Id9f19c60b54b7900b02d5f87b5d12f9a9189721d
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The Freedesktop Icon Theme Specification [1] describes that,
if a theme does not specify anything for its 'Inherits' key,
"implementations are required to add the 'hicolor' theme to
the inheritance tree. An implementation may optionally add
other default themes in between the last specified theme and
the hicolor theme."
And later, when describing the lookup algorithm, that "The
lookup is done first in the current theme, and then recursively
in each of the current theme's parents, and finally in the
default theme called 'hicolor' (implementations may add more
default themes before 'hicolor', but 'hicolor' must be last)".
But it doesn't explicitly describe the behavior when a theme
does specify a list of inherited themes via the 'Inherits' key,
and this list explicitly includes 'hicolor'.
In that case, our custom fallback theme, which we inject after
the theme's explicit parents, will be prioritized after 'hicolor'.
As it's likely that the theme author added 'hicolor' to their
parent list to ensure that 'hicolor' is at some point consulted,
but didn't intent it to be priorized, and that the spec puts focus
on 'hicolor' being last, it seems reasonable that we can move the
'hicolor' theme to the end of the fallback list, and as a result
always prioritize fallbackThemeName() over 'hicolor'.
[ChangeLog][QtGui][QIcon] The 'hicolor' theme will now always be
prioritized last when looking up fallback themes, even if
explicitly declared as a theme parent in a theme.
[1] https://specifications.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html
Pick-to: 6.6
Change-Id: I76538e4e7e9e395f9e5a38e704c60fb6b9688885
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
We still need to consult fallbackThemeName() when computing the
parent list for an individual theme, as the Freedesktop Theme Icon
spec mandates that the "hicolor" theme comes last, but we no longer
need to do explicit fallback to fallbackThemeName() if a theme is
not found.
Pick-to: 6.5 6.6
Change-Id: I6c0b5a45d8258c5b6eaa761402944a735b1606ba
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
The use of fallback icons should not depend on a theme being set.
[ChangeLog][QtGui][QIcon] QIcon::fallbackSearchPaths() will now be consulted
for fallback icons even if the current theme name is empty.
Pick-to: 6.5 6.6
Change-Id: Ia8d14062de7c53601fd9dac30f87a9e672aa2207
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
We would previously only use the fallback theme for themes that did
not exist, or for themes that did not declare any parent theme.
We now unconditionally use the fallback theme, even for themes that
declare their own parent themes, so that a QIcon::fromTheme("foo")
that doesn't exist in the current theme, nor any of its parents,
nor in "hicolor", will still be looked up in the fallback theme.
The reason this seemed to work in the existing tests was because
our test themes inherit system themes such as crystalsvg and gnome,
and we didn't provide a hicolor theme. Any of these themes missing
would lead us into the code path where we use the fallback theme
for a missing theme, masking that fact that we had not added the
fallback theme to the list of fallbacks for the theme that had
explicit parents declared.
The logic has been moved out of the theme parsing and into an
accessor in QIconTheme, so that we're not caching the fallback
theme lookup.
[ChangeLog][QtGui][QIcon] QIcon::fallbackThemeName() will now be
used as fallback even for themes that declare a parent theme.
Pick-to: 6.5 6.6
Change-Id: Ib0ce1dfe97030f23893460ed624073a719a3ebd1
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Setting a fallback theme will affect the lookup strategy, so we need
to invalidate earlier lookups.
Pick-to: 6.5 6.6
Change-Id: I962245ddb3a20b7798d5ce831ed8a369b0ab76b4
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
QThemeIconEngine takes care of creating a new icon engine when
the icon theme key changes, so we don't need to invalidate the
entire QIcon cache.
Pick-to: 6.6
Change-Id: Ie3bca00a9146d1f429b2a6f8ab0b39e15834d158
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
The logic for invalidating a theme QIcon when the platform theme
changed, or when the user set an explicit icon theme, was tied
to QIconLoaderEngine, so any platform theme implementing
QPlatformTheme::createIconEngine() with a custom icon engine
would not take part in this cache invalidation.
As we want users of QIcon::fromTheme to be agnostic to where the
icon is actually coming from, and have a consistent behavior for
the various QIcon APIs for setting explicit themes, the logic
for invalidating the themed icon has now been moved up one
layer, to a new QThemeIconEngine, that is responsible for
lazily creating the actual engine based on the name. The
engine proxies the actual icon loading through to the
real engine via a new QProxyIconEngine helper class.
Pick-to: 6.6
Change-Id: I474589981f751d7467e3073533cba542182f2d36
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
The platform theme's icon loading logic may still have changed, even
if the theme name has not, so we still need to invalidate the theme
cache.
Pick-to: 6.5 6.6
Change-Id: Id3635c235fadb007df86d93ce3beb5622d26b8bf
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
The fallback logic in QIconLoader::updateSystemTheme() has been
updated to match QIconLoader::ensureInitialized(), by using the
systemFallbackThemeName() directly, rather than the possibly
user set QIconLoader::fallbackThemeName().
Pick-to: 6.5 6.6
Change-Id: Ib5aab62bbfb22683d3bddf87c4e798eca4a5af62
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
We cache the system theme name in QIconLoader, so when a theme change
comes in we need to update the system icon theme name regardless of
whether a user theme has been set.
The updated system theme name will not be reflected through the
QiconLoader::themeNamed() unless the user theme is cleared/unset.
Pick-to: 6.6 6.5
Change-Id: Id949e55e2fa12e40818ba54cf2a10ce48fe10815
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
The GTK platform theme (and possibly others) emit theme change
when the named icon theme changes, but that was not propagated
to QIconLoader.
We now call QIconLoader::updateSystemTheme(), but note that
if a user theme has been set we ignore the system theme update
and will end up with a stale value, even if the user theme is
later cleared. This will be fixed in a follow up commit.
Pick-to: 6.6 6.5
Change-Id: I40b537f3618f44d396db0c7ca67e515dfcdfba44
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
QFontEngine tries to generate glyphs for ASCII control characters. Those
characters have no glyphs and should therefore not be generated.
Task-number: QTBUG-113848
Change-Id: Ib15a50c642d8bc92bc007ab5522aebc5a7b2993d
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
The method is more than a plain getter, so keep it with the other
logic of the class.
Pick-to: 6.5 6.6
Change-Id: I34aa185a51f04e3db3c1918f9723e53f33e5e9e1
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Most of the QWS (Qt Windowing System) classes from
the Qt 4 times are cleaned up in Qt 6. Any existing
QWS API documentation should be marked \internal.
Pick-to: 6.2 6.5 6.6
Task-number: QTBUG-35605
Change-Id: I24201406114feaf8af21403b09375a2ee9a4709e
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Topi Reinio
Laszlo Agocs
Tor Arne Vestbø
Santhosh Kumar
Marc Mutz
Yuhang Zhao
Mårten Nordheim
Shawn Rutledge
Ilya Fedin
Wladimir Leuschner
Venugopal Shivashankar