dspr
dspr

Reputation: 2433

Xcode keyboard layout and shortcuts

In a macOS application project, passing from Xcode 12 (on Catalina) to Xcode 13 (on Monterey), I encountered a strange issue with my menu shortcuts. I usually add a shortcut to a menu item programmatically using these methods:

    [menuItem setKeyEquivalent:@"1"];
    [menuItem setKeyEquivalentModifierMask:NSEventModifierFlagCommand]; 

With Xcode 12, the resulting behaviour was that the shortcut remained the same whatever are the language and the input source used by the target: thus, in this case, Command-1 remained Command-1 (although it could require more modifier keys: on an Azerty keyboard, the Shift modifier is required to type '1', but this is implicit, not really member of the shortcut).

Now, Xcode 13 seems to work differently because, for the same shortcut, and with a French Azerty keyboard as the input source, I read ⌘& instead of ⌘1 in the menu item (on an Azerty keyboard, '&' is the character located at the same position than '1' on a Querty keyboard).

Because of that change, all my shortcuts using numbers or special characters of the keyboard's top row, as well as some special characters of the bottom row, produce wrong shortcuts when used with an Azerty input source.

Is this the expected behaviour on macOS 12 ? And is it still possible to keep the same shortcut across input sources instead of the same key code as it seems to be now ?

Any help appreciated

Upvotes: 1

Views: 194

Answers (1)

dspr
dspr

Reputation: 2433

I should have read the doc before posting this question but, for anyone interested in this topic, here is the solution.

Apple introduced a new property to NSMenuItem on macOS12: allowsAutomaticKeyEquivalentLocalization which is YES by default and changes the behaviour in the direction I observed. Adding this to the method I use to build menu items fixed that issue:

    if (@available(macOS 12, *))
        [item setAllowsAutomaticKeyEquivalentLocalization:NO];

Upvotes: 0

Related Questions