The QVkPipelineCacheDataHeader::reserved field wasn't initializaed by
the code, but then memcpy()ed with the struct into the result
QByteArray. At best, this contains random data, at worst, it leaks
information.
Initialize it to zero.
Found by Coverity.
Amends df0e98d408.
Pick-to: 6.7 6.6 6.5 6.2
Coverity-Id: 444147
Change-Id: I398c9a1e99483f2f9887d768319b20ecc11e2c86
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
What was done:
* Removed headers in src/gui/accessible/windows/apisupport: as of
v13.1.0, MinGW supports most of the definitions in these headers.
Including uiautomation.h should be enough.
* Removed the QWindowsUiaWrapper class: it's not meant to be extended
or itself instantiated, is an "ultra-thin" layer (it even preserves
the "all-caps" Win types of function args), and is in effect only a
MinGW-bound "kludge". Instead of this class, use the UI Automation
API directly, with the assumption that it's available and fully
functional, as specified in the MS docs. Any gaps between this
assumption and what is delivered by MinGW are bridged with specific
(and explicit) temporary "kludges".
* Implemented said specific "kludges" in qwindowsuiautomation. For
Windows builds, the header just includes uiautomation.h, and the
.cpp is empty. For MinGW, the header contains definitions still
missing from uiautomation.h, and the .cpp implements functions
of the UI Automation core library through imports from the
uiautomationcore DLL.
* Windows plugins (and tst_qaccessibility): use the UI Automation API
definitions directly, instead of the "ultra-thin" wrapper.
* Windows plugin builds: use uiautomationcore library, if found.
What's intended:
* Unburden Gui of the Windows UI Automation COM interfaces and other
definitions that are copied in the uia*.h headers.
* Make the Windows plugins independent of MinGW shortcomings.
* Remove the QWindowsUiaWrapper class that essentially only hides these
shortcomings and the "kludge" code needed to overcome them.
* As MinGW adds further support to the UI Automation API over time,
make it noticeable which workarounds are no longer needed. The
current approach of hiding "kludges" in a wrapper class will also
hide the fact that they're no longer needed, if/when that time comes.
Change-Id: I0070636817d5de81d0b106e9179e2d0442362e2a
Reviewed-by: Wladimir Leuschner <wladimir.leuschner@qt.io>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
QColorVector is not forced to 128-bit alignment.
Change-Id: Ifacc171296ddddda742d49745372b47585e40802
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
To indicate color spaces that can not be used as a target,
but only as a source.
Change-Id: Iae79e3533599c112872d171a2f45178029be89dc
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Like the QPolygon code. This fixes a mistake in failing to clear the
list before de-marshalling in operator>>.
Updated most of the QDataStream tests to have data in the objects
they're streaming into, to ensure that the stream overwrites everything.
Fixes: QTBUG-122684
Task-number: QTBUG-122704
Pick-to: 5.15 6.5 6.6 6.7
Change-Id: I01ec3c774d9943adb903fffd17b6920c72f5042b
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
QDbusTrayIcon has a convoluted workaround/hack that consists in putting
an icon file in /tmp/ and then using that path as the icon. Opening the
icon file may fail, so handle it.
Change-Id: I5d1c681e2fe3cfb23e93fd20f6758d4c83fe1578
Reviewed-by: Dmitry Shachnev <mitya57@gmail.com>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
We had no examples of this type, and didn't catch the table was parsed as
-0.5 to 0.5 instead of 0 to 1.
Change-Id: I904937a50deaeecfc89e271bf918eedc521bc8a2
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
A literal backslash needs to be doubled so that the parser doesn't treat
it as escaping the following character when the markdown is read back.
In ca4774131b we tried to limit it to
backslashes that were not already escaped. In case someone really needs
a longer series of backslashes, it's more correct to escape them all;
but this comes with the risk that if they do not get un-escaped by the
markdown parser in some scenario, repeated round-trip saving and loading
could multiply them excessively. So we also add a lot of tests to try
to verify that this is safe.
Task-number: QTBUG-96051
Fixes: QTBUG-122083
Pick-to: 6.7
Change-Id: I64f610d24e99f67ebdc30d5ab5c6cf3985aec5ec
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
There is a limit in WebGL that OpenGL context sharing is not supported.
There is a proposal from 2013
(https://www.khronos.org/webgl/wiki/SharedResouces), but it seems that
it never was implemented.
There is an additional limit in that there is exactly one WebGL context
for each canvas (i.e. window).
A part of the problem here is that the identifier for an OpenGL context
is essentially a surface-thread-context triplet. And the thread part
might be more difficult to handle in a javascript setting.
Regardless of why, we need to have an opinion about what the
consequences are, and what we support to what extent.
As such this commit:
1) Adds a comment on the QOpenGLContext describing the limitations
2) Adds a qWarning() on the first activation of a shared context.
The second item is not complete. We will have problems with multiple
individual contexts also, It is just not possible to warn for these
cases. The second item covers, maybe, the most common case.
Change-Id: I51550a6acb0a7f6f6fa5e9e2c3da080a1d2b498f
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
src/gui/painting/qpaintengine_raster.cpp:3811:42: error: ‘void* calloc(size_t, size_t)’ sizes specified with ‘sizeof’ in the earlier argument and not in the later argument [-Werror=calloc-transposed-args]
3811 | m_clipLines = (ClipLine *)calloc(sizeof(ClipLine), clipSpanHeight);
| ^~~~~~~~~~~~~~~~
src/gui/painting/qpaintengine_raster.cpp:3811:42: note: earlier argument should specify number of elements, later size of each element
Pick-to: 6.7 6.6 6.5 6.2 5.15
Change-Id: I41ec3dd5c439e5cd51dd917741125ce50659500e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
In 4c21f72837 we did this for
QImageReader. So, to support the same for QMovie, we just need
to remove the custom (and very inefficient) scaling for frames.
This should be safe since the underlying QImageReader must ensure
that the returned image matches the scaled size.
[ChangeLog][QtGui][QMovie] Allow only one dimension (width
or height) to be set for the scaled size. In this case, the other
will be calculated automatically based on the original movie size
and maintaining the aspect ratio.
Fixes: QTBUG-115039
Change-Id: I50979a75970c79647dbb8c8b4b121266ba033a63
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
If only one dimension (width or height) of the scaled size is set
by an user, let's try to calculate the second one, based on the
image original size and maintaining the aspect ratio.
[ChangeLog][QtGui][QImageReader] Allow only one dimension (width
or height) to be set for the scaled size. In this case, the other
will be calculated automatically based on the original image size
and maintaining the aspect ratio.
Task-number: QTBUG-115039
Change-Id: If1b13b1ead3cf788915c08bdb3ba8becd8bf8042
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
Simplifies maintenance of code paths that rely on Metal.
Change-Id: I1d1f705fffc14dbafde346eeb555b43be6d5be54
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
bb6d68703b67e042e2a7254c2ca6a004a1441cc5 fixed warnings in the
Universal style by using a faster alternative. It's possible that users
will run into these warnings too, and they should be provided with
information to make a more informed choice about which approach they
can use.
Fixes: QTBUG-123360
Pick-to: 6.5 6.6 6.7
Change-Id: I4170e9ade40c4b54dbc2bd73d124b2ade4d8c939
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
This amends a34e81ab8b .
The previous range comparison doesn't work since XKB_KEY_KP_9 is 0xffb9
while XKB_KEY_KP_Equal is 0xffbd. Change to an explicit switch.
Pick-to: 6.7 6.6 6.5 6.2 5.15
Change-Id: I3a340bac61fb074eef505ef9b06300a6468877f1
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Reviewed-by: Liang Qi <liang.qi@qt.io>
Qt supports some complex foreground brushes which we cannot
express using normal CSS, so we introduce a Qt-specific property
for this. We already had some support for background gradients
in widget style sheets, but this expands support to foreground
brushes of text when converting a QTextDocument from and to HTML.
It also adds an optional "coordinatemode" attribute to the
gradient functions so that this can be faithfully restored from HTML.
Task-number: QTBUG-123357
Change-Id: I3d6dd828f68272995c8525bec5a7b421fdbed670
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
CSS does not have text outline properties, instead different
browsers have custom properties for this. That currently means
that you can have a QTextDocument where you applied a stroke to
text and textEdit.setHtml(textEdit.toHtml()) will remove it.
Since a primary goal of the HTML support in QTextDocument is that
it can be used to save and faithfully restore its contents, we
implement qt specific properties for stroke.
Task-number: QTBUG-123357
Change-Id: Id9cf63abfabe2109ffb6fd74f9cb013304763ccb
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
When high-dpi scaling is enabled, we default to HintNone
currently, since otherwise text layouts (and widget layouts
and anything depending on text size) will have to be updated
when the window is dragged onto a screen with a different dpr.
The check for whether scaling is enabled was based on
QHighDpiScaling::isActive(), which is technically incorrect
since this does not return whether there is a scale on the
painting, rather whether the coordinate system in Qt matches
the one of the platform.
Now that we support agreeing on fractional scale factors with
the Wayland compositor, this issue has become visible, since
QHighDpiScaling::isActive() will now return false for these
compositors, even for fractional scales. For integer scales,
the issue existed before as well, but the kerning issues are
less noticeable in that case.
Pick-to: 6.6 6.7
Fixes: QTBUG-122910
Change-Id: Ic82b07d57a06a351255619f9227dd60396903ade
Reviewed-by: David Edmundson <davidedmundson@kde.org>
Reviewed-by: Kai Uwe Broulik <kde@privat.broulik.de>
This reverts commit fc33fea999.
The change caused issues with system-wide PUA fallbacks on
platforms where this is supported. It needs to be replaced by
an approach which still falls back, but only for fonts which
are explicitly categorized as PUA fallbacks.
Pick-to: 6.5 6.6 6.7
Task-number: QTBUG-110502
Change-Id: I985a1f8076645593c50e81759872b4227d0fcd0d
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
At the time of bb1f616ff1 the
Flickable.flickDeceleration property still applied to both touch
flicking and mouse wheel scrolling. In qtdeclarative
b1766d9d629f61d824146e69f1f3b319cbee3d11 we decoupled them. Switching
from the traditional 1500 logical pixels/sec² to 5000 was not enough to
satisfy those who complained about the mouse wheel "not being linear"
and at the same time made touch-flicking feel too sluggish. So let's
restore the traditional default deceleration value.
The flickDeceleration property is still adjustable, and the default
can still be overridden in any QPlatformTheme subclass.
[ChangeLog][QPA] The default value for the platform FlickDeceleration
hint is reverted to 1500 (rather than 5000 as in Qt 6.6). This sets
the default value for Flickable.flickDeceleration, which can be
overridden directly; and the default can also be overridden in any
QPlatformTheme subclass.
Pick-to: 6.7
Task-number: QTBUG-35608
Task-number: QTBUG-35609
Task-number: QTBUG-52643
Task-number: QTBUG-97055
Fixes: QTBUG-121500
Change-Id: If52b61dfcd0c08a7c6e753f39dbe01f417e94bf4
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Change 997fd3b88e fixed integer overflows
with huge texts. This was done by using qsizetype for size calculations
instead of int. However, that change introduced a serious regression
due to an itermediate imultiplication result being "promoted" to unsigned,
and therefore a negative value being converted to a large positive.
The solution is to make sure all values in the expression are signed.
Fixes: QTBUG-123339
Task-number: QTBUG-119611
Pick-to: 6.7
Change-Id: I3f9189f77b383c6103cf5b35981cdb607b065f6f
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
Replace all divisions by constant with multiplications of its inverse
Change-Id: I05aa0631e8117e7d42da0eaa30077cd230caa919
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Allows to use it without Qt Widgets or Qt Graphics Views.
Since anyone having imported this through Qt Widget will also be
linking Qt Gui this should be compatible.
qt_halfScaled is also unexported for lack of known users.
Change-Id: I39406dfd4839ed46f8cbfd4651577ab6ece9932c
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
...in particular when doing multisampling with multiview.
With this the results are now identical with multiview and
multiview+MSAA on the Quest 3. (previously the depth buffer
was clearly broken when doing multiview+MSAA)
Change-Id: Iec3c6af66510ab76cb0591eb8d002aa5855a399e
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Also implement this for OpenGL ES since it can be relevant with tiled
architectures wrt performance.
Task-number: QTBUG-122669
Change-Id: I90dcfe4f5f9edbb8dfb51189d46b89ef2c7a7c06
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
One is not enough, we have to have three code paths for three sets of
APIs/extensions.
Task-number: QTBUG-122669
Change-Id: Id10e19dfcfe16a8c21b6c932965f09539f061549
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
The EventPointMap QPointingDevicePrivate::activePoints is actually a
QVarLengthFlatMap<., ., 20>, not 16, so copy the value instead of just
hard-coding something.
Amends 296ede3aab.
Change-Id: Ic8e83f4095f57be74f7708d5cec6a19971772b76
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
We have to be able to strip the _SRGB nonsense from the render target
view formats when rendering into textures that are provided from an
external engine (e.g. OpenXR) and are forced onto us with formats such
as VK_FORMAT_R8G8B8A8_SRGB.
This highlights some limitation of the current system, which has very
limited handling of sRGB stuff since proper renderers such as Qt Quick
3D have first class support for linearization and converting to sRGB
at the end of their shading pipeline, so _SRGB format textures are
never used in practice.
OpenGL has an issue which is different from everything else, namely
that we do not correctly do the glEnable/Disable on GL_FRAMEBUFFER_SRGB.
The QOpenGLExtensions flag is not what we need. We need to know if the
sRGB-conversion-on-write is supported or not, not that some framebuffer
is sRGB-capable. So do our own query based on the desktop and the ES
extension (GL_EXT_sRGB_write_control is something we never checked for,
but that is the appropriate GLES extension, supported on the Quest 3
for instance) This is now corrected in the gl backend. This means that
the colors will no longer be "too bright" with OpenGL ES and multiview
on the Quest 3 for example.
Unlike OpenGL, Vulkan and D3D automatically convert in shader reads and
writes when the shader resource view or the render target view has a
_SRGB format. (which we get by default since we pass on the texture
format) Getting a second linear->sRGB conversion on the already sRGB
data generated by e.g. Qt Quick 3D is just wrong.
Allow solving this by a new function that can be optionally called to
say we want (RGBA8, srgb=false), i.e. VK_FORMAT_R8G8B8A8_UNORM, for
the views.
Of course, reality is more complicated. D3D11 for instance does not
allow "casting" a fully typed texture, we'd need to use a _TYPELESS
format for that (possibly with other consequences), so skip D3D11.
For D3D12 this should work from Windows 1703 on.
Implementing for Metal is also left as a future exercise - it is neither
needed at the moment within Qt, nor is it trivial, because view textures
have to be created explicitly in Metal, normally we just work with the
MTLTexture as-is, not with views.
Task-number: QTBUG-122288
Task-number: QTBUG-122614
Change-Id: I8aea4e892b308d48f0bf18bdef481e460fbc9d47
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
Ensure move where it makes sense, and remove it where it doesnt
Change-Id: I988d7ff44f1d7898a967130fa53ed6ec5690e778
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
QColorSpace::isValid() returns true if QColorSpace can handle the
profile. When called on a QColorSpace obtained via
QColorSpace::fromIccProfile, this doesn't necessarily mean that the ICC
profile itself was invalid; it could be that the ICC data was valid, but
QColorSpace didn't know how to use it. This is especially true on Qt <=
6.7, where only XYZ/RGB matrix profiles were supported.
We don't fully parse ICC v4, and we're lacking an API to differentiate
between "ICC data was valid but QColorSpace doesn't handle it" vs "ICC
data was invalid".
Still, an invalid QColorSpace will still the original ICC data, so it
can be saved again without loss of information.
So: 1) when loading a PNG with embedded ICC data, keep the loaded profile
even if it's "invalid"; 2) when writing a PNG, check if we have ICC data
to save, and unconditionally write it if it's the case.
This avoids data loss in the two directions.
This work has been kindly sponsored by the QGIS project
(https://qgis.org/).
Pick-to: 6.7 6.6 6.5
Change-Id: I1f27f603acbca1590c820e80f52f3b994f5ea5c7
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
This finishes off ICC color space support in Qt (short of the
optional multi process elements), and includes necessary parts for
potential CMYK support (PCSLab and A2B support)
[ChangeLog][QColorSpace] ICC profiles that are not three-component
matrix based are now supported.
Task-number: QTBUG-108175
Change-Id: Ie29b17a366d9ba0ea8135e1752530d6bb19e7520
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
If a markdown file has FrontMatter, we look for the end of the newlines
after the `---` marker to begin parsing the actual markdown. But check
bounds in case the file contains only front matter and not markdown.
Fixes: QTBUG-122982
Change-Id: I09c4ae90c47ebd84877738aecc1d1cad0b0bfca2
Reviewed-by: Anton Kudryavtsev <antkudr@mail.ru>
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
There is logging in QTextMarkdownImporter::import(); in case something
goes wrong, it's useful to compare the size during reading and writing.
Amends bffddc6a99
Task-number: QTBUG-120722
Change-Id: I5f60305ca84d48f91bbb18e9c10ea4010005b356
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Like as QT_QPA_PLATFORM, supports specifying multiple keys, and can
perform fallback operations to prioritize the use of a certain plug-in.
This is useful when using Wayland and XWayland applications at the same
time. For an example, we can set "QT_IM_MODULES=wayland;fcitx", and the
wayland application will use the wayland input context plugin, the
xwayland application will use fcitx, which can't be done without adding
a new environment variable, if we specify "QT_IM_MODULE=wayland", the
XWayland applications may not be able to use the input method.
Fixes: QTBUG-120202
Change-Id: Iac408af241963147747a2fe685f1e27bf9d9ee64
Reviewed-by: Liang Qi <liang.qi@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: David Edmundson <davidedmundson@kde.org>
Try to avoid writing anything that the parser would misinterpret.
Escape pre-existing backslashes, but not those that are already escaped.
Optimize maybeEscapeFirstChar() slightly and apply it to every line
of output (except in code blocks), not only to new lines created by
word-wrapping.
Since it would be hard to do this without using regular expressions,
the markdown writer feature now depends on the regex feature.
Fixes: QTBUG-96051
Fixes: QTBUG-122083
Pick-to: 6.7
Change-Id: I8d95366501fd31441829081c668f11a3a3a23fe2
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
We are observing that the strings become sequences of zeros in
release builds, possibly triggered by qOffsetStringArray being used
in a static constexpr function to initialize a constexpr array.
Pull the array out of the function as a static on translation unit level,
which is a pattern we use regularly elsewhere in Qt.
Pick-to: 6.7
Change-Id: I69c8cfe4e2d6d7d4659edda621ba1afe9768035b
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
This avoids added resources:
":/qpdf/qpdfa_metadata.xml"
":/qpdf/sRGB2014.icc"
Pick-to: 6.7
Change-Id: I89a130bd281c5550f1c3dcead8336e0c3de6bc84
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Use QDirListing in the Bootstrap build instead of QDirIterator.
Drive-by changes:
- more const variables
- use emplace_back() instead of append() where appropriate
Change-Id: Ie1f0d03856e557c4bfabfff38a87edc7da86d091
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
It was added for Android in a4f50269f8,
for the case of QSurface::RasterGLSurface, but since 6.4 we no longer
use QSurface::RasterGLSurface for composition. And the Android usage
was removed in 2020ce5fd2.
Pick-to: 6.7 6.6 6.5
Change-Id: I8dafe959c54e09b3a974253e15d184365141d559
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Marc Mutz
Miguel Costa
Allan Sandfeld Jensen
Thiago Macieira
Giuseppe D'Angelo
Shawn Rutledge
Even Oscar Andersen
Liang Qi
Lucie Gérard
Vladimir Belyavsky
Tor Arne Vestbø
Mitch Curtis
Yifan Zhu
Eskil Abrahamsen Blomfeldt
Paul Olav Tvete
Anton Kudryavtsev
Kai Uwe Broulik
Laszlo Agocs
JiDe Zhang
Volker Hilsheimer
André Klitzing
Ahmad Samir
Aurélien Brooke