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>
Instead of having to set a field of the class QtActivity to set extra
app parameters (i.e. passed when calling main()), make it doable via
a new API call appendApplicationParameters(). Note that this is
equivalent to setting the manifest metadata "android.app.arguments".
Providing a dedicated method for this makes it cleaner and is the
expected way.
Task-number: QTBUG-115017
Task-number: QTBUG-114593
Change-Id: I407cb68e57fa9a1be24586e42cb947f9c7f4037e
Reviewed-by: Tinja Paavoseppä <tinja.paavoseppa@qt.io>
Currently the default theme is looked for using reflection in the
android.R package to get an id and then it's set. This is not needed
if we set the theme directly in the user's QtActivity which would have
access to that id directly pre-deployment.
To make setting a theme more in line with Android, retreat to using
setTheme() call directly for user projects instead of having to maintain
some internal field to store the theme name and have the user set that
if they want a different theme for their app.
Also, the Android plugin seems to set an env var for QT_ANDROID_THEME
with that default theme's name and that's used in QAndroidPlatformTheme
to check a theme specific extracted theme style.json, however, the Java
side doesn't seem to ever write to such a path, making this approach
totally redundant. For that reason, this code path is now removed.
Fixes: QTBUG-114075
Task-number: QTBUG-115017
Task-number: QTBUG-114593
Change-Id: I9ab3c025626aac2c09bc19eb7d846eca14a45070
Reviewed-by: Tinja Paavoseppä <tinja.paavoseppa@qt.io>
The delegate classes shouldn't be used outside of the Activity/Service
classes, since they're practically private implementation, so don't use
them anywhere outside Activity/Service.
Since Qt Android apps still mainly support having one QtActivity/
QtService, QtNative heavily uses those objects to do various operations.
For that reason, we still need to use the delegate there. The aim is
to change that in future patches and do the operations where they make
more sense for example directly under QtActivityBase/QtActivityDelegate
or Service counterpart.
The QtServiceDelegate is used no where and have no special
implementation, so it's removed here.
Task-number: QTBUG-118077
Change-Id: I5e106318169be19fec8163e8e500ee573af0e1bc
Reviewed-by: Tinja Paavoseppä <tinja.paavoseppa@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
It's not immediately clear why setApplicationDisplayMetrics()
is called from within QtNative.startApplication() while it's also
called by QtLayout.onSizeChanged(), it seems to be a redundant call
when starting the native Qt app because QtLayout takes care of it
already.
Task-number: QTBUG-115016
Task-number: QTBUG-118077
Change-Id: I54e8af6356226ca5f1b849ef323be9659b9db663
Reviewed-by: Tinja Paavoseppä <tinja.paavoseppa@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
The flags were not set to the system UI with Android APIs.
Amends 58c7249ee8.
Task-number: QTBUG-118077
Change-Id: I30fb5272bdb5d7a3a3a82708b9a1604753fc4e6c
Reviewed-by: Tinja Paavoseppä <tinja.paavoseppa@qt.io>
stdext is deprecated, slated for removal.
The macros were used to work around a compiler warning generated
when using the 3-arg overload of certain STL algorithms even when
the 4-arg version (added in C++14) was not available.
These deprecation warnings seem to have been discontinued as of
MSVC++ 14.15 _MSC_VER == 1915 (Visual Studio 2017 version 15.8)
so making the macros no-ops from VS 2022 17.8 onward is not expected
to trigger these warnings again.
Pick-to: 6.6 6.5 6.2 5.15
Fixes: QTBUG-118993
Change-Id: I2c3b69d46d13f6fcccf0ffce186b984b7758f287
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
The nameMatch() function has an implicit precondition that neither
argument is nullptr: it immediately dereferences both arguments.
Prevent the crash by checking for name == nullptr early, before
passing to nameMatch().
Add tests for null and empty.
As a drive-by, make variables in the test const (needed for the
QByteArray to avoid detaching, peer pressure for the others).
Amends a639bcda1e.
Pick-to: 6.6 6.5 6.2
Change-Id: I4a30f6c130310eb701ba7c7251168294489c34db
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
As per the documentation: A message box displays a primary
text to alert the user to a situation, an informative text to
further explain the situation, and an optional detailed text to provide
even more data if the user requests it.
The AppKit NSAlert doesn't provide such a "detailed" section, and our
code just added this "even more data" detailed text to the primary text.
This breaks the UI when the detailed text is very long, perhaps a
complete log output with dozens or even hundreds of lines of text.
Since NSAlert doesn't provide a "details" space, fall-back to the non-
native message box if detailed text is provided.
[ChangeLog][QtWidgets][QMessageBox] On Apple platforms, the native
message box is no longer used when detailed text is set.
Pick-to: 6.6 6.5
Fixes: QTBUG-118992
Change-Id: I6f4764ceb8f8e57d641c0b0660223a9c26f5bd26
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
If an application has two windows, and the user tries to do multi-touch
gestures with different fingers in each window at the same time, we want
the touchpoint IDs to be unique. m_nextTouchId was a per-window variable
before; the result was that the QEventPoint delivered to the second
window was replacing values (including QEventPointPrivate::window)
in the persistent QEventPoint that was still being held in the first
window; then when the release of the first point occurred,
QGuiApplicationPrivate::processTouchEvent() saw its destination window
pointer as null because the second touchpoint had already been released.
QEventPoint::id is of type int, with negative values being invalid.
nextTouchId is of type quint16 so that it will always be positive, and
we can let it eventually overflow (wrap back to 0) rather than resetting
it to 0 after each touch gesture. The only requirement is that the IDs
need to be unique and positive (and typically they are sequential: that
makes debug output easier to understand).
Task-number: QTBUG-118909
Change-Id: Ia0f1edc9a5e2b362028bed4418fed228814cddb6
Pick-to: 6.5 6.6
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
When the per-abi external projects are built, specifying a dynamic
path in QT_ANDROID_EXTRA_LIBS based on CMAKE_ANDROID_ARCH_ABI would
not propagate that value back to the main project's deployment json
file.
While the actual library files would be copied into the apk, they
would not be loaded because the generated libs.xml file would be
missing per-abi entries in the 'bundled_libs' array (except for the
main abi).
Document that project developers should explicitly specify all the
libraries in the property.
androiddeployqt then takes care to filter out unsupported architecture
libraries in each abi build dir, but it will still copy all of them
into the final apk, as well as list all the architectures in libs.xml.
A proper fix would be to generate additional files with information
from each per-abi external project, that would then be read by
androiddeployqt (basically merge specific target property info from
each sub-project).
Hopefully this can be done without introducing new API.
Pick-to: 6.5 6.6
Fixes: QTBUG-117206
Task-number: QTBUG-118838
Change-Id: I181a170cffdb49b0b0d455d997cfae90ada312f0
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
Use pmf-style connections instead old string-based ones.
Change-Id: Idab3a9d60e7cddcd2076476a21dbb1b5d2e4189c
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Even a tab was hidden it could be accessed with the key navigation or
a scroll event which lead to painting artifacts.
Pick-to: 6.6 6.5 5.15
Fixes: QTBUG-101219
Task-number: QTBUG-63038
Change-Id: I58be694eef5f86cccecbe528891a39a4acdda15f
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
The two destcolors and the buffer are all already premultiplied. This
would double premultiply them.
Pick-to: 6.6 6.5 6.2
Change-Id: I235bee616d8e0033b87c6f96464f0926af7bd29a
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
Amends 339323b999
Capturing a function argument (or any local variable)
by address is a bad idea.
Fixes: QTBUG-118912
Fixes: QTBUG-118986
Change-Id: I521d319a37f7acd6c66732f5f7d3cf1be4d49029
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
By default, QPrinter::setPageLayout correctly rejects a layout that
specifies margins outside the printable area. However, when the layout
specifies fullpage mode, that check should be skipped, since then one
should be allowed to target the unprintable area, by definition.
Fixes: QTBUG-118580
Pick-to: 6.6 6.5
Change-Id: I8bd93d11aefee0344725ac51c2490d029657f483
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
We can not thread mono image formats as the bit access isn't atomic.
Pick-to: 6.6 6.5
Fixes: QTBUG-117494
Change-Id: Ica8e08fc3da73983f6b4da2a133f5e715fd0d787
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
The unplug() and startDrag() functions of QMainWindowLayout and
QDockWidget used a boolean argument specifying whether a single dock
widget or a group of dock widgets should be unplugged. The argument
defaulted to true.
That has lead to inconsistent unplug operations, broken item_lists and
crashes, especially when the methods were called without an argument.
To improve code readability, replace bool trap with a meaningful
enum. Remove default arguments, in order to force explicit calls.
This patch does not change behavior, it is just carved out to
facilitate reviews.
Task-number: QTBUG-118578
Task-number: QTBUG-118579
Pick-to: 6.6 6.5
Change-Id: I50341b055f0bb76c2797b2fb1126a10de1fee7dd
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
This is also highlighted by Android Studio Manifest editor.
Change-Id: If159405b0fceeb955e26f3916dd0e96b6ca76003
Reviewed-by: Tinja Paavoseppä <tinja.paavoseppa@qt.io>
If we use 'this' as context it might still try to invoke
the timer after we have left the function, leading to
stack-use-after-return.
To avoid doing an in-depth dive if it's okay to use mainWindow as the
context or not, I just added a new local QObject.
Amends 9ff40b59da
Pick-to: 6.6 6.5
Change-Id: I2c3bdc1eb06731d9c38979610303876c2748fb73
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
It's generated by clangd, when used for example from vscode.
Pick-to: 6.6
Change-Id: Iac65face9634c869eaf94881edff82471a33742a
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
GCC 13 has been complaining that QBitArray could be accessing past the
end of an array (specifically, the 1-element array QByteArray::_empty).
That's caused by the 'QByteArray::data() const' being:
#if QT5_NULL_STRINGS == 1
return d.data() ? d.data() : &_empty;
#else
return d.data();
#endif
A way to avoid this is to use operator[], which doesn't attempt to hide
null pointers (it has an assertion).
This is accomplished by writing nicer, more readable code, which is a
nice benefit.
Fixes: QTBUG-118631
Pick-to: 6.6
Change-Id: I85b3fc2dd45c4693be13fffd179579615a6ac98d
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Keep the variable where it belongs, it's not used anywhere else.
Task-number: QTBUG-115017
Change-Id: Ia421eb0cd3f57be3601754f1df11e64f0267fa5d
Reviewed-by: Tinja Paavoseppä <tinja.paavoseppa@qt.io>
Amends 0f3dbd6dc7.
JNI was calling notifyLocationChange(I)V method but it doesn't exist,
instead it was named notifyAccessibilityLocationChange(I)V.
Task-number: QTBUG-118077
Change-Id: Icc29d4aad97e730af7165d5e057d228bee9c8976
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Current versions of OpenSSL 3 don't support Keccak hashes as these are
going to be introduced with OpenSSL 3.2 so we should rather fallback to
the non-OpenSSL implementation instead of using SHA3.
Fixes: QTBUG-118814
Pick-to: 6.5 6.6
Change-Id: Iedeb81cd76d43d920fc10e1efdac261bc12a394c
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Remove obsolete parent_window_limits_moves_of_children test of moving
child window in parent. Child windows no longer have decorations,
therefore they cannot be dragged by a title bar.
Fix child_window_activation test, which now uses correct coordinates
to probe for stacked windows.
Change-Id: If5ddd8d4486673a961572de7c57df72c3cea9350
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
The QMenu pop-up used with a QToolButton could unexpectedly move to the
primary screen if it was too big to fit on the owning widget's screen.
The cause of the issue is that QMenu is a top-level window, and can not
infer its screen from any parents. Its positioning is therefore done
using heuristics in QToolButton. These heuristics attempt to calculate a
best guess point relative to the screen that contains the QToolButton.
If these heuristics result in a point that is outside all screens, the
QMenu's own screen takes precedence, and this is always the primary
screen. This way, the QMenu ends up at the calculated position, but
relative to the wrong screen.
This patch works around this issue by ensuring that the first estimate
for the pop-up position is always within the same screen as the
QToolButton. The danger with this workaround is that the menu may end up
in an inconvenient location. This does, however, seem to be handled by
subsequent adjustments in QMenuPrivate::popup.
Fixes: QTBUG-118695
Pick-to: 6.6 6.5
Change-Id: Ibb4a1c82e827c57bbb0798a6c6f5eecb6d639c62
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Vladimir Belyavsky
Tor Arne Vestbø
Ws ShawnWoo
Christian Ehrlicher
Sergio Martins
Thiago Macieira
Axel Spoerl
Assam Boudjelthia
Liang Qi
Matthias Rauter
Mårten Nordheim
Marc Mutz
Volker Hilsheimer
Shawn Rutledge
Alexandru Croitor
Allan Sandfeld Jensen
Laszlo Agocs
Eirik Aavitsland
Jarek Kobus
Friedemann Kleint
Lu YaNing
Jan Grulich
Piotr Wierciński
Jøger Hansegård