summaryrefslogtreecommitdiffstats
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
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
-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;
}
}