Thank you for your reply. I've observed the switch to a Latin/English-like layout (using Accessibility Keyboard) when pressing ⌘ for the Hebrew layout.
The question is how an implementation of performKeyEquivalent would correctly account for and support this?
Based on the performKeyEquivalent documentation here, and the Handling Key Events documentation here, the implementation should check the unmodified characters of the incoming events:
You should extract the characters for a key equivalent using the NSEvent method charactersIgnoringModifiers.
The implementation should extract the characters for a key equivalent from the passed-in NSEvent object using the charactersIgnoringModifiers method and then examine them to determine if they are a key equivalent it recognizes.
Which naively would be something like:
- (BOOL)performKeyEquivalent:(NSEvent *)event
{
if (event.modifierFlags & NSEventModifierFlagCommand) {
if ([event.charactersIgnoringModifiers isEqualToString:@"c"])
return YES;
}
return NO;
}
But this implementation would fail to catch the Latin layer of the Hebrew layout.
Assuming the documentation is incomplete, a more robust implementation would perhaps be something like:
- (BOOL)performKeyEquivalent:(NSEvent *)event
{
if (event.modifierFlags & NSEventModifierFlagCommand) {
if ([event.charactersIgnoringModifiers isEqualToString:@"c"])
return YES;
if ([event.characters isEqualToString:@"c"])
return YES;
}
return NO;
}
But is that correct? Are there cases where comparing against both the modified and unmodified characters will fail or produce unexpected matches? Should the behavior be different based on properties of the keyboard layout?
[NSEvent _matchesKeyEquivalent:modifierMask:] seems to handle this correctly, but contains references to text input APIs like TISCopyCurrentKeyboardInputSource, TSMGetInputSourceProperty, and TSMGetDeadKeyState, which seems to indicate the naive approach above is not sufficient to match AppKit's own behavior.
The goal would be for the custom control to respond to performKeyEquivalent the same way an NSButton or NSMenuItem would in terms of which events are considered matches and which are not. In particular, for a generic control that allows user defined key equivalents, so without relying on specifics of any particular key equivalent.
