summaryrefslogtreecommitdiffstats
path: root/src/gui/widgets/qcocoamenu_mac.mm
diff options
context:
space:
mode:
authorNorwegian Rock Cat <qt-info@nokia.com>2009-04-07 11:17:05 (GMT)
committerNorwegian Rock Cat <qt-info@nokia.com>2009-04-07 11:23:01 (GMT)
commitacff913a6287ad50b0ac782d817d51072ccb479c (patch)
tree7cd4d5028bf80bdfee11977368c4d4de60d577c8 /src/gui/widgets/qcocoamenu_mac.mm
parenta6ab4f638a63755a601b61141fa7730d5ac6e793 (diff)
downloadQt-acff913a6287ad50b0ac782d817d51072ccb479c.zip
Qt-acff913a6287ad50b0ac782d817d51072ccb479c.tar.gz
Qt-acff913a6287ad50b0ac782d817d51072ccb479c.tar.bz2
BT: Send the keyevent after we send the shortcutoverride in menu
In our Cocoa menu we check if we need to send the key event to the qwidget before the menu has a chance at it, because logically in Qt, the key event should go to the widget and not the menubar first (a bit different than what happens on the mac). The way to determine this is to send a shortcut override event and see if it accepts it. If it does, that means we should just send it the key event. Previously we were sending the shortcut override, but not following through on the key event because we thought (however foolishly). That returning "YES" but not setting an action would somehow forward the event (it doesn't). There still seems to be some problems if you have a Dvorak-QWERTY+CWD layout, but this probably needs to be dealt with at the key mapper level. Reviewed-by: Prasanth Ullattil
Diffstat (limited to 'src/gui/widgets/qcocoamenu_mac.mm')
-rw-r--r--src/gui/widgets/qcocoamenu_mac.mm1
1 files changed, 1 insertions, 0 deletions
diff --git a/src/gui/widgets/qcocoamenu_mac.mm b/src/gui/widgets/qcocoamenu_mac.mm
index 64da141..bae270a 100644
--- a/src/gui/widgets/qcocoamenu_mac.mm
+++ b/src/gui/widgets/qcocoamenu_mac.mm
@@ -161,6 +161,7 @@ QT_END_NAMESPACE
if (accel_ev.isAccepted()) {
*target = nil;
*action = nil;
+ [qt_mac_nativeview_for(widget) keyDown:event];
return YES;
}
}