QWindowsScreen uses setupAPI.h's SetupDiOpenDevRegKey function to read
EDID data for monitors. This function is documented as returning
INVALID_HANDLE_VALUE in case of failure.
The QWindowsScreen code was ambiguous in the sense that it considered
both nullptr and INVALID_HANDLE_VALUE as being invalid handle values.
This inconsistency is likely not a bug, but makes the code harder to
understand.
This patch removes this ambiguity, and QWindowsScreen now follows the
documented behavior when SetupDiOpenDevRegKey fails. In addition, we
replace use of unique_ptr with the new QUniqueHandle template class
because HKEY is a handle type, not a regular pointer type.
Pick-to: 6.5 6.6
Change-Id: Ia863bda504077e59833f6f7a0f855e7915e4edd9
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
In rare situation, base size could be (-1,-1) or (-2,-2) for high
dpi, it will be converted into huge positive numbers.
https://tronche.com/gui/x/icccm/sec-4.html
If a base size is not provided, the minimum size is to be used
in its place and vice versa.
Pick-to: 6.6 6.5 6.2 5.15
Task-number: QTBUG-117702
Change-Id: I900ed82f2291fb454d7e34a0dee27459d0a57240
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Method is trying to infer the signature from the types of the
arguments, but since the argument for the view is a plain jobject
this signature is wrong, method is not found and the view is never
inserted.
Change-Id: I3cbf9bccbcb1e5526f843213ba0f66e5bd1e7107
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
It follows f9e4402ffe.
Fixes: QTBUG-105395
Pick-to: 6.6 6.5
Change-Id: I399c448517b7dbdc28ba33f75ae43102836a8998
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Get the rotation value from the Core Graphics API, and map it to the
Qt::ScreenOrientation values.
Change-Id: I9bc9f37f34e00affee15e6ce0eace70d853eab0c
Reviewed-by: Doris Verria <doris.verria@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Follow-up change from enabling DPI awareness, which
caused some style elements (for instance check boxes)
to be rendered incorrectly on non-primary displays,
when there is a difference in DPI between displays.
Use two approaches to get system metrics and themes:
* Use forDpi() API variants and query at 96 DPI for style
metrics, that are in device independent pixels. These are
metrics which are used for layout calculations.
* Get theme metrics at the target display DPI, and scale
to device independent pixels when needed. This is used
for OpenThemeData(), since this theme is used for drawing
as well and needs to be in device pixels.
One approach is not used any more:
* Get metrics for the main display, and scale by the ratio
between the main and target display.
Change the theme cache to cache themes per window handle (HWND).
This is required since OpenThemeData() returns theme data for
a specific DPI, which means we can no longer use a shared
cache.
Clear the cache on theme change, DPI change, and when
the window is destroyed. This handles cache invalidation
when the window is moved to a different screen, and also
when the DPI for a screen is changed.
Move the cache implementation to QWindowsStyleSupport
in QtGui, where it can be accessed by both the style and
windows platform plugins.
Task-number: QTBUG-110681
Change-Id: I5a4ff3a3753762bad8a51d08e51e8013bc7816a1
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Jøger Hansegård <joger.hansegard@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The toLatin1 wasn't necessary, the argument should be QString.
The plugin isn't currently built with the ASCII ctors disabled,
so it passed through CI unnoticed.
Amends 3159b337f0
Pick-to: 6.6 6.5
Change-Id: Ib63ccaffacc46e5a313551f1e7c0e02ae09b1a01
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
A foreign window used to embed a Qt window into it should not end up
with changes to its own parent, as its only job is to give the embedded
Qt window a parent handle.
Pick-to: 6.6
Change-Id: If1bc89658fedf449d266bc0cc750c90b6a841a68
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
The implementation of [NSApplication setWindowsMenu:] seems to look
for the last item in the menu, but doesn't guard the check for the
menu having items. Instead it guards on another array being non-empty,
and in some situation this array has items of type NSWindowMenuItem
while our window menu is empty (FB13369198).
To work around this we insert a hidden dummy item into the menu.
Fixes: PYSIDE-2525
Pick-to: 6.5 6.6
Change-Id: Iaa9dbc9454249f4eb34f8a338d0cc23685f0025a
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Although not explicitly documented, this is the behavior in practice
on XCB and Windows, and we rely on this behavior in our implementation
of QApplication::widgetAt(), where we punch a temporary hole in the
widget using a mask if it has Qt::WA_TransparentForMouseEvents set.
Pick-to: 6.5 6.6
Fixes: QTBUG-41696
Task-number: QTBUG-119092
Change-Id: Ie7abc31b6930ee6b56fcdf391befc625c1ddf502
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Because it happens in some (unknown precondition) cases.
While it would be nice to know what the client is doing to trigger this,
it's not worth crashing over in the meantime.
Fixes: QTBUG-118458
Pick-to: 6.6 6.5 6.2
Change-Id: I261a17578e7cd3a95e591a3228b33561000fd336
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Implementing NSTextInputClient.windowLevel to return the level of the
current input client window is not sufficient, as there may be other
windows visible with a higher window level than that.
For example, QCompleter's completion is shown using a Qt::Popup
window, which has a NSPopUpMenuWindowLevel.
Ideally we'd hide the QCompleter's completion when the IM is
in the process of compositing, but as a first step, and as
safeguard for other similar scenarios, we now return a minimum
window level of NSPopUpMenuWindowLevel for our text input
client.
Fixes: QTBUG-102831
Pick-to: 6.6 6.5 6.2
Change-Id: Id74a6350595bd136027a9af470f6700ee90f52a7
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Implement support for getting the strikethrough
style (UIA attribute UIA_StrikethroughStyleAttributeId [1])
by checking for the corresponding IAccessible2
text attribute "text-line-through-type" [2] and
mapping the value accordingly if set.
Only report those attributes from the
QAccessibleTextInterface::attributes return value,
if they apply for the whole range of the
QWindowsUiaTextRangeProvider.
With this in place, the NVDA screen reader on
Windows announces "strikethrough" as expected
when asked to report the formatting information
(e.g. via NVDA+f shortcut) for the QTBUG-118106 example.
[1] https://learn.microsoft.com/en-us/windows/win32/winauto/uiauto-textattribute-ids
[2] https://wiki.linuxfoundation.org/accessibility/iaccessible2/textattributes
Task-number: QTBUG-118106
Change-Id: I2fa060bd3bf493227bba766385f34d224497784c
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
It is possible to have several desktops on macOS, and even more - assign
an app to one particular desktop. Then, moving such an app to a different
desktop and using Qt's widgets like combobox may result in a strange
behavior: since it's not a native 'combo button', we create a popup
to show contents (list of items) of Qt's combobox and this popup
may open on a 'wrong' desktop (the one to which the app is assigned to).
To address this, combine the existing collection behavior for popups
with NSWindowCollectionBehaviorMoveToActiveSpace.
Pick-to: 6.6 6.5
Fixes: QTBUG-113507
Change-Id: Icbbc930fd1fc91089774340793e4bc452b939c1c
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
For QAccessible::Paragraph and QAccessible::Heading, use
UIA_TextControlTypeId as specified in the Core Accessibility
API Mappings specification [1] [2].
For QAccessible::WebDocument use UIA_DocumentControlTypeId.
[1] https://w3c.github.io/core-aam/#role-map-paragraph
[2] https://w3c.github.io/core-aam/#role-map-heading
Change-Id: Idae1e2da28b495d5d639df63c3de1260f2177142
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
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>
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>
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>
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>
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>
It's no more defined in opensslv.h, try to use OPENSSL_SHLIB_VERSION
instead.
Pick-to: 6.6 6.5
Fixes: QTBUG-116295
Change-Id: Ie465f4147e0ec95897bd8d35f71241884bf64b4e
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Fixes the complication issue since the typedef was used as class member.
Replace the typedef with using statement.
Fixes: QTBUG-118627
Pick-to: 6.6 6.5
Change-Id: Ie3d341fb8f18a7341d018f51947127ace941a620
Reviewed-by: James McDonnell <jmcdonnell@blackberry.com>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Remove yet another two layers of delegation, QtNative calling
QtActivityDelegate and that in turn calls QtAccessibilityDelegate.
Now from c++ native code, acquire the a11y delegate and use it to
call a11y operations that live in QtAccessibilityDelegate.
Task-number: QTBUG-118077
Change-Id: I9e84520c2caa281a6f786a687b0106d702f92a67
Reviewed-by: Tinja Paavoseppä <tinja.paavoseppa@qt.io>
In a couple places we already check if the socket is connected,
however we can be connected _and_ have the socket be closed.
The logic behind that I don't really understand, but there are
similar checks for validity in the OpenSSL backend.
This happens when calling close() on a still-connecting
socket. The QIODevice is marked as closed, but the connection
cannot yet be aborted. And when it finishes connecting we
handle the signal, start encryption, and then disconnect.
Pick-to: 6.6 6.5
Fixes: QTBUG-116550
Change-Id: I06c0a2db32bea0b573a99a971b8fb0b66a7a73d5
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
I forgot to add this to the features list when adding support for it.
Amends d2c5494c3d
Pick-to: 6.6 6.5
Fixes: QTBUG-118741
Change-Id: Ieabf086ef66777e6178476934b88448ad88bc738
Reviewed-by: Erik Verbruggen <erik.verbruggen@me.com>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Crash reports imply the `certBackend` we extract in
QSslCertificate_from_CERT_CONTEXT is null, which means that
something went wrong when parsing the certificate data we get from
the certificate chain.
We assume the rest is okay since it must be inside the bounds of the
length of the chain.
It's not clear why the certificate would be invalid, but it's better
to avoid the crash for now.
Pick-to: 6.5 6.6
Task-number: QTBUG-118569
Change-Id: I76ce07fc38bf82ef5c93097d839724ddee1edeef
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Introduce dark mode to QWindows11Style and increase frame contrast on
highcontrast themes.
Change-Id: I18d10a314fb11828b8c3a116396e2d3cd2247b65
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Have all or most of Android code dealing with displays in
QtDisplayManager. Also, simplify setApplicationDisplayMetrics()
call and avoid caching any uneccessary members.
Task-number: QTBUG-118077
Change-Id: I943069c24bb40ae3016db5896e553b501e700a6b
Reviewed-by: Tinja Paavoseppä <tinja.paavoseppa@qt.io>
The text handle should not be visible in case when it is out of
the text-object, or when it is hidden by other object. That is why we
should call updateSelectionHandles() method after touch only in case
when cursor position fits to clipped input item rectangle.
Fixes: QTBUG-115005
Pick-to: 6.6 6.5
Change-Id: I35c083acd8fd4d5240e3bb15afa1afbec4ea0b26
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Should not unset all the old state and set the new ones.
Only unset the state that needs to be unset.
If states changes from maximized to minimized, there is no need to
unset the maximized state and set the maximized states again.
(minimized and maximized can exist simultaneously :)
This amends f61b140482 .
Pick-to: 6.6 6.5 6.2
Change-Id: Ic93122b92fafcdba973b885e299b282408da7a1c
Reviewed-by: Liang Qi <liang.qi@qt.io>
Emit log output and return false immediately if we fail to get both the
Activity and the Service objects. Standardize the registerNative methods
to return bool and take a QJniEnvironment, and adjust the macros
accordingly.
Simplify the startup routine to use QJniEnvironment.
Change-Id: I11be35426520dc803f5a07bbb495e908592f254e
Reviewed-by: Tinja Paavoseppä <tinja.paavoseppa@qt.io>
