summaryrefslogtreecommitdiffstats
path: root/examples/corelib/tools/customtype
diff options
context:
space:
mode:
authorDoris Verria <doris.verria@qt.io>2021-09-17 13:03:51 +0200
committerQt Cherry-pick Bot <cherrypick_bot@qt-project.org>2021-09-24 10:10:22 +0000
commitae1921b0ea15435159dffb29b69ac2504b2932bd (patch)
tree940339c9e753cbcbc58153f7476e992b8d23eea7 /examples/corelib/tools/customtype
parent4a6618ca68ec020d96405c00182320c2b3dd8210 (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/corelib/tools/customtype')
0 files changed, 0 insertions, 0 deletions