I'm not familiar with CUPS APIs, so missing better judgment or a
code comment, handle the possibility for a failure.
Change-Id: I6f9afa9fdccaadbe199ce307f79e1d6050aa2939
Reviewed-by: Albert Astals Cid <aacid@kde.org>
As discussed in QTQAINFRA-6146, there were two potential approaches to
enabling backtraces in Qt Quick tests:
- Either via a thorough refactoring of quicktest.cpp so that each
testcase is a Slot in a programmatically-created QObject-derived class,
which will be executed via QTest::qExec() similar to the documented
QTest way. This way the pre-existing code in QTest::qRun() will setup
the fatal signal handler.
- Or as a quick fix, modify quick_test_main_with_setup() to setup a
FatalSignalHandler class and invoke prepareStackTrace() like it's
already done in QTest::qRun(). This would require exporting these
symbols in the private header.
This patch enables the implementation of the latter, as it has a
fairly light footprint, is easily revertable (should we need to),
and allows us to immediately gain insight into crashes in CI.
Task-number: QTQAINFRA-6146
Change-Id: Iedffc968acb3e570214df34884ab0afcb6b30850
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
In preparation for reusing it in Qt Quick, which currently doesn't
print backtraces upon crashes.
Task-number: QTQAINFRA-6146
Change-Id: Ib0384f514b348a398f53529ff3bcc7d4ac2daba7
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Because we can't support it on 32 bit operating systems.
Task-number: QTBUG-69558
Change-Id: I406ecccdf039d7d4f4c24268c92c91e367655cba
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
f1bb9cfbf6 added this value, but it was
only when a test in qtdeclarative tried to use it that it was
discovered that it couldn't be set on 32 bit operating systems (armv7,
AKA imx7) due to overflow as a result of the bit shifting that is done.
Fix it by using an old, deprecated value. If any old codebase using
that older flag tries to build against a newer Qt with this change, it
shouldn't affect it, as setting the flag does nothing in Widgets, and
native menus didn't exist in earlier versions.
Task-number: QTBUG-69558
Change-Id: I520154d02e9ccf007ebd73807685212a19fbee1b
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Draw the glyph directly in the paint() override, and use that
from the scaledPixmap implementation. This avoids a pixmap
creation just for drawing an icon with an existing painter.
Pick-to: 6.7
Change-Id: Iece0083a3a9f3625d843bc6e9d836baf9b5d84f8
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Doris Verria <doris.verria@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Instead of implementing scaledPixmap() to rasterize the
vector image we get from App/UIKit, and calling that from
paint, implement paint() to draw the vector image directly
through the painter, and use that in scaledPixmap.
Pick-to: 6.7
Change-Id: I2c62826f29406543bc8d8c7fa71199e91586d83b
Reviewed-by: Amr Elsayed <amr.elsayed@qt.io>
Reviewed-by: Doris Verria <doris.verria@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Although the output of these functions is premultiplied ARGB, we know
the alpha is always going to be full (1.0) because the source is CMYK 32
bit (without alpha). We can therefore avoid calling qPremultiply.
This work has been kindly sponsored by the QGIS project
(https://qgis.org/).
Change-Id: I129b601f5c93a1c444ab06c3325f946d2bcc6efc
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
As part of eacd58d4e7, a mechanism was
added to prevent posting redundant UpdateRequest events to the top
level widget, managed by QWidgetRepaintManager. The mechanism relied
on a boolean that was set when posting an update request event, and
reset when processing the event for the top level widget, as part
of QWidgetRepaintManager::sync().
However, for paint-on-screen widgets, we don't post an update request
to the top level, we post it to the paint-on-screen widget directly.
And when processing that event, we don't paint the widget though the
normal QWidgetRepaintManager machinery, but instead call the paint
event via QWidgetPrivate::paintOnScreen().
As a result, an update() on a paint-on-screen widget would result
in never receiving updates for non-paint-on-screen widgets, as
we assumed there was no reason to send further update requests.
We could fix this by clearing the updateRequestSent flag as part
of the paintOnScreen() code path, but that's incorrect as the flag
represents whether the top level QWidgetRepaintManager needs an
update request event or not, and would lead to missed updates
to normal widgets until the paint-on-screen widget finishes its
update.
Instead, we only set updateRequestSent if we're posting update
requests for non-paint-on-screen widgets, which in practice
means the top level widget.
The paint on screen logic in QWidgetRepaintManager::markDirty
still takes care of rate-limiting the update requests to the
paint-on-screen widget, by comparing the dirty area of the
widget.
There is definite room for improvement here, especially in the
direction of handling update requests via QWindow::requestUpdate
instead of manually posted events, but for now this will have to
do.
Fixes: QTBUG-80167
Pick-to: 6.7 6.6 6.5 6.2 5.15
Change-Id: Ib5685de7ca2fd7cd7883a25bb7bc0255ea242d30
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
It was introduced in December 2018, which is apparently too recent for
some Linux distributions. So remove the dependency that was there only
to give us MS_RDONLY and revert to the old statfs.h / sys/vfs.h flag.
We still don't include <sys/vfs.h> because it is absent on some old
Android versions.
Amends ea6abe583f.
Pick-to: 6.7
Fixes: QTBUG-123932
Change-Id: If1bf59ecbe014b569ba1fffd17c29cc448d16358
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
We can't fix the underlying reported problem, but we can warn that the
user has made a mistake.
[ChangeLog][QtCore][QObject] The class template parameter passed to
QObject::findChild() or findChildren() is now required to have the
Q_OBJECT macro. Forgetting to add it could result in finding children of
the nearest ancestor class that has the macro.
Pick-to: 6.7
Fixes: QTBUG-105023
Change-Id: I5f663c2f9f4149af84fefffd17c008f027241b56
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
We don't use that in the XCB library or plugin anywhere.
Pick-to: 6.7
Change-Id: I5f663c2f9f4149af84fefffd17be8c7f3bd7bd14
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
On systems without the RTLD_NODELETE flag, simply don't call dlclose()
and leak the handle. Amends ef5ab6e006.
Pick-to: 6.7
Change-Id: I01ec3c774d9943adb903fffd17b76673562daa8a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Remove unused code.
This work has been kindly sponsored by the QGIS project
(https://qgis.org/).
Change-Id: I3db7705b3963d7a7669f8c9b284d3d35a2a7da92
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
JPEG part 6 defines CMYK support. This commit adds such support to the
JPEG plugin.
A *very* interesting discovery is the fact that Photoshop inverts the
meaning of the CMYK color channels when saving into JPEG: 0 means "full
ink", and 255 means "no ink". Most other image viewers/editors follow
the same interpretation, I imagine for compatibility.
But others, like Adobe Reader, don't (???) -- a PDF expects a DCT
encoding with 0 meaning "no ink". I am adding a SubType to the image I/O
handler to let the user choose what they want, defaulting to Photoshop
behavior.
Also, turns out that Qt was already loading CMYK files and converting
them to RGB. I don't think we should do automatic, lossy conversions (we
were not taking into account an eventual colorspace...), so I'm changing
that loading to yield a CMYK QImage.
Finally: save the colorspace, even if it's a CMYK image.
QColorSpace doesn't support anything but RGB matrix-based colorspaces.
Yet, it can load an arbitrary ICC profile, and will store it even if
it's unable to use it. We can use this fact to preserve the colorspace
embedded in CMYK images, or let users set an arbitrary ICC profile on
them through Qt APIs, and then saving the result in JPEG.
[ChangeLog][QtGui][JPEG] Added support for loading and saving of JPEG
files in 8-bit CMYK format. When loading a CMYK JPEG file, Qt used to
convert it automatically to a RGB image; now instead it's kept as-is.
This work has been kindly sponsored by the QGIS project
(https://qgis.org/).
Change-Id: Ibdbfa16aa35814f5dba28c2df89577175162b731
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
Input events have a timestamp. When dispatching an event through QPA, a
platform plugin can either provide it, or QPA will use an internal
QElapsedTimer to provide a timestamp.
Windows input messages do come with a timestamp already, so we can use
that instead of the QPA.
The two methods are not equivalent.
For instance: for various reasons, Qt does not honor Windows' "double
clicked" message, but uses the delta between two mouse events to
establish if the second click is actually a double click.
Now suppose that the user double clicks on a widget. On the first click,
the application does something that freezes it for a bit (e.g. some
heavy repainting or whatever). Does the second click register as a
double click or not?
* If we're using Qt's own timer, the answer is NO; the event is pulled
from the WM queue after the freeze, given a timestamp far away from
the last click, and so it will be deemed another single click
* If we use the OS' timestamps, then the second click will be seen as
"close" to the first click, and correctly registered as second click.
This reasoning can be extended to many other QPA events, but looks like
the APIs for some are missing (e.g. enter events), so I'm not tackling
them here.
This commit reverts ade96ff644.
Task-number: QTBUG-109833
Task-number: QTBUG-122226
Change-Id: I5f3fba029b44c618ef622bacdc4bcc3928e04867
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Yuhang Zhao <yuhangzhao@deepin.org>
Add setDepthResolveTexture(). Should work similarly to the color
attachments' resolveTexture, but for depth or depth-stencil.
However, this is another fragmented feature.
- D3D11/12:
Not supported. AFAICS multisample resolve (ResolveSubresource) is just
not supported for depth or depth-stencil formats.
- Vulkan:
Not supported with Vulkan 1.0.
Supported with Vulkan 1.1 and the two extensions.
(VK_KHR_depth_stencil_resolve which in turn requires
VK_KHR_create_renderpass2 since the 1.0 structs are not extensible, so
now need to use VkRenderPassCreateInfo2 and all the '2' structs)
In Vulkan 1.2 the above are in core, without the KHR suffix, but we
cannot just use that because our main target, the Quest 3 (Android) is
Vulkan 1.1. So 1.2 and up is ignored for now and we always look for
the 1.1 KHR extensions.
The depth resolve filter is forced for SAMPLE_0. AVG seems to be
supported on desktop (NVIDIA) at least, but that's not guaranteed, so
would need physical device support checks. On the Quest 3 it does not
seem to be supported. And in any case, other APIs such as Metal do not
have an AVG filter mode at all, so just use SAMPLE_0 always.
- OpenGL (not ES):
Should work, both when the multisample data is a renderbuffer and a
texture. Relies on glBlitFramebuffer with filter NEAREST. What it does
internally, with regards to the depth/stencil resolve mode, is not under
our control.
- OpenGL ES:
Should work when the multisample buffer is a texture. But it will not
work when a multisample renderbuffer (setDepthStencilBuffer, not
setDepthTexture) is used because the GLES-only multisample extensions
(GL_EXT_multisampled_render_to_texture,
GL_OVR_multiview_multisampled_render_to_texture, which we prefer over
the explicit resolve-based approach) work with textures only.
- Metal:
Should work.
Task-number: QTBUG-122292
Change-Id: Ifa7ca5e1be78227bd6bd7546dde3a62f7fdbc95e
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
"Just in case" -- as the comment says,
QInternalMessageLogContext's constructor is usually inlined, but
we can't be sure if it has been.
Change-Id: I4da2f0875d9fd9f7bd6d79447b4761fda329c7fd
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This commit adds a CMYK 8bpp format to QImage. The idea is to enable the
transport of CMYK images inside Qt, for instance to be loaded/saved from
files or painted on CMYK capable paint devices (e.g. PDF).
Also, rasterization support *from* a CMYK image is added (on top of a
RGB surface), as well as CMYK image scaling/conversion.
Conversion and rasterization between CMYK and RGB isn't particularly
optimized nor it honors any colorspaces yet. The overall idea is to
match 1:1 the existing behavior of CMYK QColor (which get naively
changed to RGB; there isn't colorspace support in QPainter yet).
There are no plans to add rasterization *towards* CMYK.
Image save/load in native CMYK formats will be added in future commits.
This work has been kindly sponsored by the QGIS project
(https://qgis.org/).
[ChangeLog][QtGui] Support for 8-bit CMYK images has been added.
Change-Id: I4b024cd4c15119c669b6ddd450418a9e425587f8
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
Change the invalid static_cast<std::int16_t>(i)+1
to the correct static_cast<std::int16_t>(i+1).
Change-Id: I5d3e17d29deb2a70fa0d7d7838531a3dc80b4e45
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Calling data() for parameters of the type bigint
failed in combination with stored procedures with
output parameters. Cast the result to qlonglong to
fix it.
Pick-to: 6.7 6.6
Change-Id: I84ef04ed26821b92ef7c5bcdf12b778e91450e0b
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Inline namespaces serve the purpose for which the original
-qtnamespace option was added and allow for macro simplification (no
need for any using directives). This makes it possible to use
namespaced builds of Qt also for Qt for Python and similar use cases
which have issues with the additional namespace.
[ChangeLog][QtCore] It is now possible to use an inline namespace for
-qtnamespace (option -qtinlinenamespace).
Task-number: PYSIDE-2590
Change-Id: Ia0cecf041321933a2e02d1fd8ae0e9cda699cd1e
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
We're not guaranteed to get into any of the code paths that call
removePopupMonitor() before the app goes away. In a plugin-scenario,
this may cause crashes when our monitor then gets a callback and
we try to access QGuiApplicationPrivate::instance().
Pick-to: 6.7 6.6 6.5 6.2
Fixes: QTBUG-123959
Change-Id: I287b91ff261a8aab74adbbad8c63a042daf944d5
Reviewed-by: Doris Verria <doris.verria@qt.io>
Like the other times it's used in this file
This is causing compilation errors in projects that use -Werror=undef
Fixes: QTBUG-123937
Pick-to: 6.7
Change-Id: I0cdd2910755dc9079890011dd8dbc27a6e64793e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Apparently it has trouble with multiple attributes between the
class keyword and the class name, looking only for the EXPORT
macros.
As a quick band-aid we can add the #pragma to tell syncqt
to generate the header explicitly.
Pick-to: 6.7
Fixes: QTBUG-123875
Change-Id: If155a5b667b9e71d43dfac04ad19caee0ff23793
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Juha Vuolle <juha.vuolle@qt.io>
QMessageBox contains an icon that can be set using icon type. Before
this commit, android.R.attr.alertDialogIcon was used regardless of the
expected icon type. Only if setting failed, the icon from
android.R.drawable was set (depending on the expected icon type).
Previously, usage of android.R.attr.alertDialogIcon was the way to
consider Theme in choosing icon view. Since
31a0d99fa5 commit, getDrawable(id, theme)
is used with second parameter: Resources.Theme.
Because of that we can start to use only icons from android.R.drawable
and remove usage of android.R.attr.alertDialogIcon
Fixes: QTBUG-123334
Pick-to: 6.7 6.6 6.5
Change-Id: I6cfdaf30aea5d132e38ba5d78054089b51cf5f13
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Instead of deep inside the processing of the message pattern tokens.
This reduces the number of uninlineable functions in release builds to
2. Experimentation shows that even in debug mode our overhead to
backtrace() is just 2, despite the debugger's backtrace showing 3 frames
-- the debugger is using QtCore's debug symbols and does know about the
inlined function.
As a nice side-effect, we capture the backtrace only once per message,
not once per %{backtrace} token in the QT_MESSAGE_PATTERN.
Change-Id: I01ec3c774d9943adb903fffd17b7d6de09167620
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
QMessageLogContext is a primitive type that may be extended in the
future with more fields (it has been at version 2 since commit
6d166c8822, though that did not extend the
struct's size). This introduces a QInternalMessageLogContext which is
used in before all our calls to qt_message_output().
Currently there's no difference and no way to tell that the internal
version is used.
Change-Id: I01ec3c774d9943adb903fffd17b7d5abc0052207
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
8cd7a3d472 remembered the current screen
in QMenuPrivate::popupScreen. This QPointer member is not reset, after
QMenu:exec(), which makes a re-used menu remember the wrong screen, if
its next usage happens on another screen.
Reset the member variable at the end of QMenuPrivate::exec().
This amends 8cd7a3d472.
Fixes: QTBUG-118434
Pick-to: 6.7 6.6 6.5
Change-Id: I7457ca72166346f01cf71b2706ebc20ecd71173c
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Add the note about the way the str size is determined when using
QByteArray::operator=(const char*).
Pick-to: 6.7 6.6 6.5
Change-Id: I39b2d0fc2967832622fbf0c11b3ff6c7ff99b8f2
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
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>
Commit 87362f3f58 added
qt_linux_find_symbol_sys(). Given the authors and reviewers, I'm
guessing that was used somewhere in qtdeclarative. Indeed, its use was
removed in qtdeclarative/67191c2b3213259c6eaf045154e9370faa085868
("Remove qqmlmemoryprofiler*").
qt_mac_resolve_sys() was never used in the public repository, as far as
I can tell.
Change-Id: I6818d78a57394e37857bfffd17bbf1fae8688b1a
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
These options are declared with TYPE enum and a MAPPING that's supposed
to control the feature 'system-zlib' or 'system-sqlite'. Since only
inputs of type boolean control features now, we need to somehow declare
that this non-boolean input controls a feature.
We do this by adding the keyword CONTROLS_FEATURE to
qt_commandline_option. For example,
qt_commandline_option(zlib
CONTROLS_FEATURE
TYPE enum
NAME system-zlib
MAPPING system yes qt no
)
declares
- commandline option "zlib" sets the input "system-zlib",
because of the "NAME system-zlib" argument
- accepted input values are "system" and "qt", because
we have "TYPE enum" and the odd values of MAPPING
- those values are translated to yes/no, because of the
even values of MAPPING
- CONTROLS_FEATURE forces the translated input's type
to boolean, and with that it will set the corresponding
feature 'system-zlib'
Luckily, only qtbase has command line options with MAPPING declared.
Change-Id: I82d06cec43ece3b002c8f5dd414c68dc730909af
Reviewed-by: Alexandru Croitor <alexandru.croitor@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>
Amends aadf1d447c because size_t on 32-bit
platforms is 32-bit.
qhash.cpp:331:15: error: left shift count >= width of type [-Werror=shift-count-overflow]
Change-Id: I5f663c2f9f4149af84fefffd17c0567b17f832ce
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
And ensure all combination of CBOR types are tested.
Amends e5ebb9022a
Change-Id: I5f663c2f9f4149af84fefffd17c02d352cd41f3f
Reviewed-by: Tatiana Borisova <tatiana.borisova@qt.io>
The name says it's a warning, it's pretty unexpected that it should
lead to a critical message.
One case where this is a problem is QTBUG-48488
where merely printing with "Microsoft Print To PDF" and canceling
the file dialog leads to "QWin32PrintEngine::begin: StartDoc failed"
as a *critical* message. Some Windows applications have a message
handler that shows a msgbox in case of a critical message,
and getting such a msgbox after canceling the file dialog seems very
wrong.
Task-number: QTBUG-48488
Pick-to: 6.7
Change-Id: I1c842340dd2faf2be6e64e0522f9e2b33547d3cf
Reviewed-by: Thiago Macieira <thiago.macieira@intel.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>
New comparison macros are used for following classes:
- QJsonArray::iterator
- QJsonArray::const_iterator
Replace public operators operator==(), operator!=(), operator!<(), etc
of classes to friend methods comparesEqual(), compareThreeWay();
Use *_helper methods to have an access to protected members of
QCborValueConstRef class from friend functions.
Task-number: QTBUG-120300
Change-Id: I9b41b619107ce69d8b6dab4938232fab841aab51
Reviewed-by: Thiago Macieira <thiago.macieira@intel.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>
The QTextStream(FILE*) constructor may fail to open the filehandle
through QFile (e.g. if the open mode is incompatible). However
QTextStream has no error report mechanism for this and still reports
status Ok. This is consistent for instance with the QIODevice*
constructor, where even passing a closed device sets the status to Ok.
Add a comment and discard the return of open().
Change-Id: I430b96fd26e0ebca15a4d9ee640b09895bdd0b03
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
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>
Coverity complains that QToolBarAreaLayout's
addToolBarBreak(QInternal::DockPosition) could access
QToolBarAreaLayout::docks out of bounds if passed
QInternal::DockCount.
That is correct, but a valid pos seems to be a precondition for this
function, judging from its sister functions, e.g.
addToolBar(DockPosition, .) or insertItem(DockPosition, .), which also
don't validate `pos`. All in-module callers of addToolBarBreak() only
pass valid positions, and use validateToolBarArea() to ensure that. So
it seems that Coverity doesn't grok the pass-by-in/out -parameter used
by that function. That, or it doesn't track back far enough.
Before attempting more drastic measures, first try rewriting the
function to return-by-value instead, and see what Coverity has to say
afterwards.
As a drive-by, make validateToolBarArea() constexpr.
Pick-to: 6.7 6.6 6.5 6.2 5.15
Coverity-Id: 444141
Coverity-Id: 444135
Change-Id: I5fcc664c3cea608429036cad75c37f5c38059733
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
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>
Coverity complained about a use of the moved-from (in the first line
of the loop) `info` object in subsequent lines.
This specific instance is harmless, because the field being accesssed
is a scalar and the move SMFs are the default ones, so the field isn't
actually changed when the struct is moved from.
Still, to silence Coverity and to guide other attentive readers of the
code, take a copy of the field before moving from the struct, and use
the copy's value after the move.
Amends ddc39eb3a4.
Amends 3e330a79ec.
Pick-to: 6.7
Coverity-Id: 444199
Change-Id: I26ea8669f27124fb2567b16d803d47ab439f1e41
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Giuseppe D'Angelo
Mitch Curtis
Volker Hilsheimer
Tor Arne Vestbø
Thiago Macieira
Laszlo Agocs
Tatiana Borisova
Fredrik Ålund
Friedemann Kleint
Albert Astals Cid
Mårten Nordheim
Bartlomiej Moskal
Axel Spoerl
Alexey Edelev
Marc Mutz
Miguel Costa
Joerg Bornemann
Allan Sandfeld Jensen
David Faure
Shawn Rutledge