After hiding the QSystemTrayIcon explicitly with .setVisible(false)
resetting visibility with .setVisible(true) does not generate NIM_MODIFY
message and thus preventing the tray icon from being visible again.
Fixes: QTBUG-118133
Pick-to: 6.6 6.5
Change-Id: Ic2b1d0f293c92fec7ec697b2fe3d1da9fd0d0e44
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Timothée Keller <timothee.keller@qt.io>
Fix qt namespace issues:
* qjniarray.h:339:30: error: no template named 'Traits';
* ld.lld: error: version script assignment of 'Qt_6' to symbol '_ZNTestQTNamespace114QReadWriteLock16destroyRecursiveEP21QReadWriteLockPrivate' failed: symbol not defined
* same for _ZN16QNetworkDatagram7destroyEP23QNetworkDatagramPrivate
* qtimezoneprivate_android.cpp:14:21: error: unknown type name 'TimeZone'
* qandroidplatformclipboard.h:13:1: error: no template named 'Object'
Change-Id: Ia5fc3990af4a4d762e194c7951727f8d5b10670e
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
The IAccessible2 text attribute specification [1], which
is the applicable specification for text attributes in
Qt as well, says:
> These characters need to be escaped with a backslash:
> backslash, colon, comma, equals, and semicolon.
To adhere to this specification the commas in the
"rgb(0,0,0)" value strings need to be escaped.
However, AT-SPI does not expect those to be
escaped, s. for example the ATK text attribute
specification for ATK_TEXT_ATTR_FG_COLOR:
> The foreground color. The value is an RGB
> value of the format "u,u,u"
Therefore, replace any backslash-escaped comma
with just a comma in the AT-SPI adaptor.
The context where I ran into this is LibreOffice
change [3] (where LibreOffice's qt6 VCL plugin
is based on Qt, but the Windows variant
has its own IAccessible2-based a11y implementation).
[1] https://wiki.linuxfoundation.org/accessibility/iaccessible2/textattributes#formatting
[2] https://gnome.pages.gitlab.gnome.org/atk/AtkText.html#AtkTextAttribute
[3] https://gerrit.libreoffice.org/c/core/+/157845
Change-Id: I0a9003ff891f1bfb180a6d16a1dff2afe4002b3e
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
QMainWindow::show() also showed its dock widget children. When a main
window with dock widget children consumed a show event for another
reason, hidden dock widget children remained hidden.
If a dock widget application went to the background, e.g. because it
was hidden behind another application gaining focus, a klick on the
dock widget application's app icon would not show its dock widget
children. Unless the dock widget application provides shows them
explicitly, they can never been shown again by the user.
=> show all dock widget and group window children, when QMainWindow
consumes a show event.
Pick-to: 6.6 6.5
Change-Id: I7e8b59f021ec4ec5679d0d08d0eeda1e3225a385
Reviewed-by: David Faure <david.faure@kdab.com>
The condition was wrongly converted while qmake-to-cmake porting.
Pick-to: 6.2 6.5 6.6
Change-Id: I8b8de7c9b2ca079609ed466cf91f1a3dd0d22aa9
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
For a CXXFLAGS='-D_GLIBCXX_DEBUG' build, running the
examples/corelib/ipc/sharedmemory/sharedmemory
example and clicking on the "Load Image from File..." button
would result in a crash:
> usr/include/c++/13/debug/safe_iterator.h:492:
> In function:
> bool gnu_debug::operator!=(const
> _Safe_iterator<std::_Rb_tree_const_iterator<std::pair<const
> QSettingsKey, QVariant> >, std::debug::map<QSettingsKey, QVariant,
> std::less<QSettingsKey>, std::allocator<std::pair<const QSettingsKey,
> QVariant> > >, std::forward_iterator_tag>::_Self&, const
> _Safe_iterator<std::_Rb_tree_const_iterator<std::pair<const
> QSettingsKey, QVariant> >, std::debug::map<QSettingsKey, QVariant,
> std::less<QSettingsKey>, std::allocator<std::pair<const QSettingsKey,
> QVariant> > >, std::forward_iterator_tag>::_Self&)
>
> Error: attempt to compare a singular iterator to a
> singular (value-initialized) iterator.
>
> Objects involved in the operation:
> iterator "lhs" @ 0x7ffe8e811550 {
> type = std::_Rb_tree_const_iterator<std::pair<QSettingsKey const, QVariant> > (constant iterator);
> state = singular;
> }
> iterator "rhs" @ 0x7ffe8e811670 {
> type = std::_Rb_tree_const_iterator<std::pair<QSettingsKey const, QVariant> > (constant iterator);
> state = singular (value-initialized);
> }
> Aborted (core dumped)
This may be a libstdc++ bug, but still avoid/work around the issue
by just using two separate variables for the iterators here.
While at it, simplify the code a bit and replace the use
of const_cast and pointers with the use of const references.
Many thanks to Giuseppe D'Angelo for the analysis of
the underlying problem and reporting a bug for GCC/libstdc++ [1] !
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112477
Fixes: QTBUG-119044
Pick-to: 6.6 6.5
Change-Id: I00a8cc35033cf3ab4ba1f071cccabdef8ef52f9c
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Add a template overload for the QJniEnvironment member function so that
a declared type can be used.
And add a static registerNativeMethods class member function to declared
types.
As a drive-by, document the initializer_list overloads. The
"template <typename Class>" convenience wrappers are currently all
undocumented, as we first need to document the QtJniTypes type system
and declaration macros.
Change-Id: I8ff9edc4e493694e6d2c26d4bc7b06bd8e05bf0c
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
We are using eglfs in VxWorks which make 3 few testcases fail, because eglfs windows are fullscreen by default.
This is the same solution as in qt5 in tag 5.12.6 from commit with hash 39027ef076c.
[...] EGLFS forces the first top-level window - either a QWidget or a QQuickView - to become fullscreen. [...]
from: https://doc.qt.io/qt-6/embedded-linux.html
Change-Id: I3ab3208b3c7c1b2e27d879bac1ee0679f48109e2
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
The -Winaccessible-base switch was added for GCC 10. Older GCCs had no
way to suppress the warnings, and the existing suppression of
-Winaccessible-base caused a warning of its own:
qcompilerdetection.h:1125:49: warning: unknown option after ‘#pragma GCC diagnostic’ kind [-Wpragmas]
1125 | #define QT_DO_PRAGMA(text) _Pragma(#text)
| ^~~~~~~
qcompilerdetection.h:1150:49: note: in expansion of macro ‘QT_DO_PRAGMA’
1150 | # define QT_WARNING_DISABLE_GCC(text) QT_DO_PRAGMA(GCC diagnostic ignored text)
| ^~~~~~~~~~~~
tst_is_virtual_base_of.cpp:53:1: note: in expansion of macro ‘QT_WARNING_DISABLE_GCC’
53 | QT_WARNING_DISABLE_GCC("-Winaccessible-base")
| ^~~~~~~~~~~~~~~~~~~~~~
Since GCC 8 and 9 are slowly fading away as supported compilers, the
simplest fix to get a clean build is to suppress all warnings for the
test on these compilers, by passing -w, as suggested by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90449.
Short of moving the affected code into a separate header file and
applying `#pragma GCC system_header` to it, there appears to be no
other way to get rid of the warning.
Amends a1bdee4697.
Change-Id: I12eb1f8d486b1e2413675991659bf9ad3a7869ae
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Add more tests and DRY the code using the usual row() lambda trick.
Pick-to: 6.6 6.5
Change-Id: I810fba0ab2a96e740e67392155f9507675fe57ae
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Helps finding it, e.g. in QtCreator, as it's now disambiguated from
tst_QImageReader, the auto-test.
As a drive-by, remove all empty functions.
Pick-to: 6.6 6.5 6.2 5.15
Task-number: QTBUG-114253
Change-Id: Icb0a3627488bbf4cb0c9d6bc9890f31a88096afd
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Commit 862f42e806 removed the last use
of the Android-only `directory` member, but didn't remove the member's
definition.
Remove it now, probably fixing a Clang -Wunused-private-field warning
on Android.
Pick-to: 6.6 6.5 6.2
Task-number: QTBUG-87438
Change-Id: I67a1d97f29a0dde20ff29fb9b5bbaa5611cb9e17
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Use the arguments to call the parent class implementation.
Pick-to: 6.5 6.6
Change-Id: I602a66447fb8681b3ec9ef8e2e281828612d178c
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
We need to free the memory allocated when getting the
info about the variable font.
Change-Id: I25c5f070a6d02468c904428ea2ae71efce1e847c
Reviewed-by: Lars Knoll <lars@knoll.priv.no>
A foreign window embedded into a Qt hierarchy must also support
being removed from that window hierarchy.
Pick-to: 6.6
Change-Id: Id4d08079ff19d67a8989937bc72602e8bd14b31b
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Adds VxWorks conditions to match target instructions
and sets env prefix to wrenv.
Change-Id: If9a8ffcdf4b60cc4b45eb2a336737d77d2f8804a
Reviewed-by: Jukka Jokiniva <jukka.jokiniva@qt.io>
Reviewed-by: Dimitrios Apostolou <jimis@qt.io>
It contains a static guard variable, so every user of the function
outside of QtCore (at least QtNetwork contains one) will create its
own copy of the guard variable. While mostly harmless, we'd be
executing too many sigaction() calls this way.
As a drive-by, remove the qatomic.h include and replace the C-style
struct initialization (memset()) with C++-style
(value-)initialization.
I also tried C++20/C99 designated initializers, but they cannot be
used here: some platforms #define sa_handler to some nested member
accessor because they hold the field in a union. While .a.b is allowed
in C99, it isn't in C++20, so we'd have to move this function's
definition into a .c file to compile `{ .sa_handler = SIG_IGN }`.
That'd be too much hassle.
Mark the function as noexcept, because it is (sigaction(2) is not a
Posix Cancellation Point), and, now that it's out-of-line, that
actually matters to codegen.
Change-Id: Iffab9e6b57822a4d1be8b81ed5948ce186df978e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
When QDoc parses a project, it parses the source code to extract the
user-provided documentation and perform sanity checkings based on the
code itself on it.
When QDoc parses an "\fn" command as part of this process, it tries to
understand, based on its intermediate representation built on the
information extracted from the code-base, which "documentable element"
the "\fn" refers to.
When QDoc performs this "matching" process, it takes into consideration
only a certain amount of information.
For example, no checking is performed over the template declaration of a
callable.
Due to some upcoming documentation, where two callables are
indistinguishable to the current process, as they differ only in their
template declaration, QDoc will start to take into consideration the
template declaration of a callable when matching.
This implies that an "\fn" command should now provide information
parity, with regards to template declaration for callables, with the
code-base so that QDoc can perform the match correctly.
The documentation for of the members of `QTypeRevision` is not in sync
with the intended target template declaration.
Hence, add the missing information to the relevant "\fn" commands.
Task-number: QTBUG-118080
Change-Id: Id121fb926cdd1a7905be1693f8d9fb90834a99e0
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
When QDoc parses a project, it parses the source code to extract the
user-provided documentation and perform sanity checkings based on the
code itself on it.
When QDoc parses an "\fn" command as part of this process, it tries to
understand, based on its intermediate representation built on the
information extracted from the code-base, which "documentable element"
the "\fn" refers to.
When QDoc performs this "matching" process, it takes into consideration
only a certain amount of information.
For example, no checking is performed over the template declaration of a
callable.
Due to some upcoming documentation, where two callables are
indistinguishable to the current process, as they differ only in their
template declaration, QDoc will start to take into consideration the
template declaration of a callable when matching.
This implies that an "\fn" command should now provide information
parity, with regards to template declaration for callables, with the
code-base so that QDoc can perform the match correctly.
The documentation for of the members of `QVariant` is not in sync
with the intended target template declaration.
Hence, add the missing information to the relevant "\fn" commands.
Task-number: QTBUG-118080
Change-Id: I9ec1a09091afbb17bc37bfc1dee8f738f01619e9
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
When QDoc parses a project, it parses the source code to extract the
user-provided documentation and perform sanity checkings based on the
code itself on it.
When QDoc parses an "\fn" command as part of this process, it tries to
understand, based on its intermediate representation built on the
information extracted from the code-base, which "documentable element"
the "\fn" refers to.
When QDoc performs this "matching" process, it takes into consideration
only a certain amount of information.
For example, no checking is performed over the template declaration of a
callable.
Due to some upcoming documentation, where two callables are
indistinguishable to the current process, as they differ only in their
template declaration, QDoc will start to take into consideration the
template declaration of a callable when matching.
This implies that an "\fn" command should now provide information
parity, with regards to template declaration for callables, with the
code-base so that QDoc can perform the match correctly.
The documentation for of the members of `QStringView` is not in sync
with the intended target template declaration.
Hence, add the missing information to the relevant "\fn" commands.
Task-number: QTBUG-118080
Change-Id: Ia5c6f99d38b0080b150cbfca83ae605cc07d9b72
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
When QDoc parses a project, it parses the source code to extract the
user-provided documentation and perform sanity checkings based on the
code itself on it.
When QDoc parses an "\fn" command as part of this process, it tries to
understand, based on its intermediate representation built on the
information extracted from the code-base, which "documentable element"
the "\fn" refers to.
When QDoc performs this "matching" process, it takes into consideration
only a certain amount of information.
For example, no checking is performed over the template declaration of a
callable.
Due to some upcoming documentation, where two callables are
indistinguishable to the current process, as they differ only in their
template declaration, QDoc will start to take into consideration the
template declaration of a callable when matching.
This implies that an "\fn" command should now provide information
parity, with regards to template declaration for callables, with the
code-base so that QDoc can perform the match correctly.
The documentation for `QSet::QSet(InputIterator, InputIterator)` is not
in sync with the intended target template declaration.
Hence, add the missing information to the relevant "\fn" command.
Task-number: QTBUG-118080
Change-Id: I7e20331af3ca0c8d09ffdb6acf3292b46ca79651
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
When QDoc parses a project, it parses the source code to extract the
user-provided documentation and perform sanity checkings based on the
code itself on it.
When QDoc parses an "\fn" command as part of this process, it tries to
understand, based on its intermediate representation built on the
information extracted from the code-base, which "documentable element"
the "\fn" refers to.
When QDoc performs this "matching" process, it takes into consideration
only a certain amount of information.
For example, no checking is performed over the template declaration of a
callable.
Due to some upcoming documentation, where two callables are
indistinguishable to the current process, as they differ only in their
template declaration, QDoc will start to take into consideration the
template declaration of a callable when matching.
This implies that an "\fn" command should now provide information
parity, with regards to template declaration for callables, with the
code-base so that QDoc can perform the match correctly.
The documentation for `QAbstractGrpcClient::fillRange` overload set is
not in sync with the intended target template declaration.
Hence, add the missing information to the relevant "\fn" commands.
Task-number: QTBUG-118080
Change-Id: I0b9c197019c0ba03d488d7b7c3351de75a0023f3
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Amends 121a30ccef
Fix the unfortunate mistake where oldMenu was not properly disconnected
from the contextMenuRequested() signal. This could lead to a situation
when several menus are displayed at the same time.
Fixes: QTBUG-78737
Pick-to: 6.6 6.5 6.2 5.15
Change-Id: Ice59841724207192eacd5a52b644f83159e09913
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
All good, except missing noexcept.
Can't test ordered relational operators because the classes provide
only op<, not the full set, so this has to wait until we port
Q*ModelIndex to the new comparison framework.
Change-Id: I05e26c88f0bd8c035ef0461c7c50b218c513da08
Reviewed-by: David Faure <david.faure@kdab.com>
The patch provides two sets of functions:
* functions to perform compile-time check for all cv-ref combinations
* functions that actually verify the comparison results for all
cv-ref combinations.
For now it does not test operator<=>(), even if compiled with C++20,
because Qt types do not yet implement it.
The patch uses the new helper functions to improve testing of date and
time classes, because they already provide a full set of relational
operators.
Change-Id: I8bd869c489543719ea856d6609cac53cbd4dc122
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
It's not possible to have empty lines inside a \note as this will cause
the text after the empty line to appear outside the note box. So, remove
the empty lines to make the note paragraph complete.
Also, revise the text.
Fixes: QTBUG-117111
Pick-to: 6.6 6.5
Change-Id: I50ad0cd559f684c5264898ef8bbac16910f96dea
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
QDial::bound() is crashing when min == max due to a division by zero.
Therefore check for this condition beforehand and return min.
Pick-to: 6.6 6.5 6.2 5.15
Fixes: QTBUG-104641
Change-Id: I612625af1ad18333d59a7771abfdec602301b58e
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Fix logic in QSystemTrayIconPrivate::updateMenu_sys() to allow resetting
the tray icon menu. Now we correctly handle `nullptr` menu, and update
the underlying QPlatformSystemTrayIcon instance accordingly.
Also we bail out from QSystemTrayIcon::setContextMenu() early if the
menu is the same.
Fixes: QTBUG-119068
Pick-to: 6.6 6.5
Change-Id: I704b40dfb1a3046331aef65417655411bf3a41a0
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The buttons in QMessageDialogOptions do not have any order that we
can rely on. The standard buttons is just a bit mask, so any ordering
done on the QMessageBox side is lost. The custom buttons are ordered
in the same order the user added them, but this is not really the
order we want them to appear in the dialog either, as we have a
well defined order between roles provided by QPlatformDialogHelper.
We now follow the QPlatformDialogHelper::ButtonLayout order for
macOS, using the same heuristics for multiple Accept role buttons
as QDialogButtonBox.
For buttons with the same role, QMessageBox will respect the order
they were added in, but this is not something we can do for the
standard buttons, as long as they are flattened to a bit mask.
Pick-to: 6.6 6.5
Change-Id: I401f202a7c2d83dc253e988531ad145624c97580
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
The default macOS behavior when an application is activated is to
bring key and main windows to the front. Any window shown after
that is order to the front as normal.
For Qt apps we show windows in main() instead of waiting for the
application to become active first, and the request to show
the window may reach the window server before or after Finder
has made the application active. If it arrives first, the window
may end up behind the currently frontmost application.
This is particularly noticeable when the application is not
activated by Finder, and we do our own activation workaround.
In this case all our windows are hidden, except for the key
window.
To ensure a consistent behavior here, we explicitly activate
all windows of the application on launch.
Pick-to: 6.5 6.6
Change-Id: Ice55f7d03e077c5a5ca843f75f1a7296ebb47aa7
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
We override the macOS default behavior of not activating applications
unless they are launched from Finder. To play a bit nicer, we now
try to detect if we're already the frontmost application, and skip
the explicit activateIgnoringOtherApps if so.
Pick-to: 6.5 6.6
Change-Id: Iff4ddc3dc50aeb9700c88882dd7a270cfea5b737
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
We handle this in applicationDidFinishLaunching nowadays.
Pick-to: 6.5 6.6
Change-Id: I447e8923fba3eac4cb0a2727f369fff21054f9a1
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Without this optional NSTextInputClient method the input methods
will assume it's safe to place the input panel somewhere above
NSFloatingWindowLevel.
But our NSWindow level can potentially be higher than that, if
set via QWindow::setFlags(), or directly on the NSWindow.
In practice this can be observed by setting a level higher
than kCGDockWindowLevel on the NSWindow.
Account for this by returning the true window level.
Pick-to: 6.6 6.5 6.2
Change-Id: I77d9ac3c59e2f6de9b768c7519b2bc0f1e5fda1d
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
AppKit will in some cases set up the key view loop for child views, even
if we don't set autorecalculatesKeyViewLoop, nor call recalculateKeyViewLoop
ourselves.
When a child window is promoted to a top level, AppKit will maintain the key
view loop between the views, even if these views now cross NSWindows, even
after we explicitly call recalculateKeyViewLoop. When the top level is then
hidden, AppKit will complain when -[NSView _setHidden:setNeedsDisplay:] tries
to transfer first responder by reading the nextValidKeyView, and it turns out
to live in a different window.
ERROR: Setting <View: 0x145e0cfd0> as the first responder for window
<Window: 0x10f904de0>, but it is in a different window (<Window: 0x147104f00>)!
This would eventually crash when the view is freed. The first responder will
be set to nil.
We mitigate this by a last second reset of the first responder, which is
what AppKit also falls back to.
It's unclear if the original situation of views having their nextKeyView
pointing to views in other windows is kosher or not, but that's left for
further investigations.
Pick-to: 6.5 6.6
Change-Id: I63636afbba85abf73a38db9701f32656c42c59cc
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Amends da754d5b65
We should avoid registering an observer multiple times for the same
NSMenu object, because it results in multiple consecutive
emitActivated() calls.
So,
- bail out early if menu is the same, i.e. we have nothing to do
- unregister an observer we added previously for the old menu
Fixes: QTBUG-119053
Pick-to: 6.6 6.5
Change-Id: I14fce693dba351b1d12f2140fa8e672227cc7a9e
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
When an invalid index is given to QStandardItemModel::mimeData() the
function bails out with a warning and returns a nullptr. But the
allocated data from QAIM::modelData() was not freed.
Pick-to: 6.6 6.5 6.2 5.15
Task-number: QTBUG-116532
Change-Id: Ibce9d51ea09d45f1b0eb3ca980aaff141af5bf68
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
QStandardItemModel::takeItem/Row/Column() return items not owned by the
model anymore and therefore need to be cleaned up manually
Pick-to: 6.6
Fixes: QTBUG-116532
Change-Id: Ic8797f58184f56b9c4ef415ce8f2363c1b352388
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
After the change for QTBUG-89145 the parent was not set to 0 when the
item was not attached to a model.
Pick-to: 6.6 6.5 6.2
Fixes: QTBUG-117900
Task-number: QTBUG-89145
Change-Id: I421e775130b03ce3eb2dd1dd05370e7391af087b
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Otherwise, for example fillRect() will fail silently.
Most operations already had the warning, but some were missing it.
Pick-to: 6.6
Change-Id: I1ef6bf880d5b0722baadcf0ced68a968f0b1a070
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Reviewed-by: David Faure <david.faure@kdab.com>
This reduces the size of the header. I renamed the arguments for fill()
because "size" would shadow a member function.
Change-Id: I85b3fc2dd45c4693be13fffd1795b706b92e0965
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
This variable supposedly holds a list of environment variables that will
be set by the Qt app, however, if a user needs to set an env variable,
it can be already done either in C++:
qputenv(key, value);
Or in Java via (the same method that Qt plugin use):
android.system.Os.setenv(key, value, override);
Thus, such field just makes things more confusing overall only.
Task-number: QTBUG-115017
Task-number: QTBUG-114593
Change-Id: I14856ed0720bfa2605da9c7d51173703df52bc58
Reviewed-by: Tinja Paavoseppä <tinja.paavoseppa@qt.io>
