diff options
author | Doris Verria <doris.verria@qt.io> | 2021-09-17 13:03:51 +0200 |
---|---|---|
committer | Qt Cherry-pick Bot <cherrypick_bot@qt-project.org> | 2021-09-24 10:10:22 +0000 |
commit | ae1921b0ea15435159dffb29b69ac2504b2932bd (patch) | |
tree | 940339c9e753cbcbc58153f7476e992b8d23eea7 /examples | |
parent | 4a6618ca68ec020d96405c00182320c2b3dd8210 (diff) |
Cocoa: Don't call makeKeyAndOrderFront for native app-modal dialogs
We show non-modal and Qt::WindowModal native dialogs as modeless
panels by calling makeKeyAndOrderFront on the panel. When we exec()
a dialog on the other hand, we start a modal event loop by calling
runModalForWindow. This method will display the dialog and make it a
key window before running the modal event loop. So we don't need to
and shouldn't call makeKeyAndOrderFront explicitly before that.
Doing so will make Cocoa lose the reference to the previous active
window (as it maintains only one level of previous active window) and
wrongly choose the main window as key after the dialog closes. Avoiding
the call to showModelessPanel for Qt::ApplicationModal dialogs fixes it.
Also, in order to display a modal when show() is called and app modality
is set via setModality, display it as a modeless dialog as well. This
keeps the same behavior we have currently, but it is still not the right
way to handle it as we don't respect the modality set by the user.
A clean-up of that logic to come in a follow-up commit.
Fixes: QTBUG-42661
Change-Id: I8f33e3866b191d775a64a5d9ec3dd65736114e62
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
(cherry picked from commit 7c26d7f482b9c15cc6ff850d5954151031010226)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Diffstat (limited to 'examples')
0 files changed, 0 insertions, 0 deletions