summaryrefslogtreecommitdiffstats
path: root/src/gui
diff options
context:
space:
mode:
authorRichard Moe Gustavsen <richard.gustavsen@nokia.com>2011-04-04 08:29:40 (GMT)
committerRichard Moe Gustavsen <richard.gustavsen@nokia.com>2011-04-04 08:29:40 (GMT)
commit3c2373d7ea9bc91bb537c0725984d19ad0fbab01 (patch)
treeceb8c101baa7fac93c316069454b9542582746b4 /src/gui
parent73b32e942696156c7c9fe84682394ec26f16c5c6 (diff)
downloadQt-3c2373d7ea9bc91bb537c0725984d19ad0fbab01.zip
Qt-3c2373d7ea9bc91bb537c0725984d19ad0fbab01.tar.gz
Qt-3c2373d7ea9bc91bb537c0725984d19ad0fbab01.tar.bz2
Cocoa: p1 bugfix, add widget flag MacNoCocoaChildWindow
This problem has been known for a long time, but a good solution has never been found. The problem is that a child window should always stay on top of it's parent, if not for anything else than secure that a modal child does not block input while hiding behind the parent at the same time. The only sensible solution found to ensure this in the Cocoa port is to use Cocoa child windows. But this API has a sad side effect; it will move the child along with the parent when the parent is moved on screen. This is something it seems we have to live with. But for those users that wants to handle this issue otherwise, we now add a widget flag to switch this off. Task-number: QTBUG-11481 Reviewed-by: msorvig
Diffstat (limited to 'src/gui')
-rw-r--r--src/gui/kernel/qwidget_mac.mm23
1 files changed, 15 insertions, 8 deletions
diff --git a/src/gui/kernel/qwidget_mac.mm b/src/gui/kernel/qwidget_mac.mm
index 7e5173f..7105d23 100644
--- a/src/gui/kernel/qwidget_mac.mm
+++ b/src/gui/kernel/qwidget_mac.mm
@@ -2796,9 +2796,12 @@ void QWidgetPrivate::setSubWindowStacking(bool set)
{
// This will set/remove a visual relationship between parent and child on screen.
// The reason for doing this is to ensure that a child always stacks infront of
- // its parent. Unfortunatly is turns out that [NSWindow addChildWindow] has
+ // its parent (expecially if both windows are modal, and the child blocks input to
+ // the parent while at the same time hiding behind it). Unfortunatly is turns out
+ // that [NSWindow addChildWindow] has
// several unwanted side-effects, one of them being the moving of a child when
- // moving the parent, which we choose to accept. A way tougher side-effect is
+ // moving the parent, which we choose to accept (if this is unacceptable, consider
+ // using Qt::WA_MacNoCocoaChildWindow). A way tougher side-effect is
// that Cocoa will hide the parent if you hide the child. And in the case of
// a tool window, since it will normally hide when you deactivate the
// application, Cocoa will hide the parent upon deactivate as well. The result often
@@ -2821,12 +2824,14 @@ void QWidgetPrivate::setSubWindowStacking(bool set)
if (QWidget *parent = q->parentWidget()) {
if (NSWindow *pwin = [qt_mac_nativeview_for(parent) window]) {
if (set) {
- Qt::WindowType ptype = parent->window()->windowType();
- if ([pwin isVisible] && (ptype == Qt::Window || ptype == Qt::Dialog) && ![qwin parentWindow]) {
- NSInteger level = [qwin level];
- [pwin addChildWindow:qwin ordered:NSWindowAbove];
- if ([qwin level] < level)
- [qwin setLevel:level];
+ if (!q->testAttribute(Qt::WA_MacNoCocoaChildWindow)) {
+ Qt::WindowType ptype = parent->window()->windowType();
+ if ([pwin isVisible] && (ptype == Qt::Window || ptype == Qt::Dialog) && ![qwin parentWindow]) {
+ NSInteger level = [qwin level];
+ [pwin addChildWindow:qwin ordered:NSWindowAbove];
+ if ([qwin level] < level)
+ [qwin setLevel:level];
+ }
}
} else {
[pwin removeChildWindow:qwin];
@@ -2840,6 +2845,8 @@ void QWidgetPrivate::setSubWindowStacking(bool set)
if (child && child->isWindow()) {
if (NSWindow *cwin = [qt_mac_nativeview_for(child) window]) {
if (set) {
+ if (child->testAttribute(Qt::WA_MacNoCocoaChildWindow))
+ continue;
Qt::WindowType ctype = child->window()->windowType();
if ([cwin isVisible] && (ctype == Qt::Window || ctype == Qt::Dialog) && ![cwin parentWindow]) {
NSInteger level = [cwin level];