-
Notifications
You must be signed in to change notification settings - Fork 220
KeyCode string for KeyEquivalent depends of the current keyboard layout #60
Comments
This is an interesting challenge. As I understand the issue, the core problem is this: On different keyboard layouts (such as US and Czech), a single shortcut (a combination of physical keys) can have different “names”. For example, the default system shortcut for toggling directly to space no. 2 is Control–2. But when you switch to the Czech keyboard layout, the physical key with the This is reflected by the system: When you open the System Preferences → Keyboard → Shortcuts pane, the shortcuts displayed depend on the currently selected keyboard layout (try switching between the US and Czech keyboard layouts and reopening the preference pane). MASShortcut seems to handle this exactly like system does: When you run the demo with different keyboard layouts, you may get different shortcut strings in the recording control (even in the current version). But when I try to assign a shortcut like // Try this with the Czech keyboard layout active
MASShortcut *shortcut = [MASShortcut shortcutWithKeyCode:kVK_ANSI_5 modifierFlags:NSControlKeyMask];
[menuItem setKeyEquivalentModifierMask:[shortcut modifierFlags]];
[menuItem setKeyEquivalent:[shortcut keyCodeStringForKeyEquivalent]]; That’s a problem. On the other hand, setting a key equivalent to The proposed switch to |
You have to watch a keyboard shortcut with a key that’s different on the two keyboard layouts. Here’s is an animated screenshot – one frame with the US keyboard layout, the other one with the CS layout: All that’s needed is to switch to the previous tab (Text), switch keyboard layout and switch back to the Shortcuts tab. |
Interesting.. got it with 1,2 etc, but what about A-Z? Nevertheless In my case the main problem is A-Z characters with different layout, in Russian layout for example |
Current summary:
MASShortcutFormatter *formatter = [MASShortcutFormatter new];
[formatter setKeyboardLayout:[MASKeyboardLayout currentLayout]];
NSString *keyCodeString = [formatter keyCodeStringForShortcut:someShortcut]; This would place all the code responsible for formatting shortcuts in one class and if we could pass an explicit keyboard layout (like US or CS), we could add automatic tests for shortcut rendering (which is not currently possible since the code depends on the current keyboard layout).
|
I’ve just read your last comment, @stel. Thank you, that’s a clear argument in favour of the “ASCII-capable” API call. |
See #60 for a discussion. In short, keyCodeStringForKeyEquivalent should be now correct even with non-ASCII keyboard layouts such as Russian.
Thanks 👍 |
TLDR Use TISCopyCurrentASCIICapableKeyboardLayoutInputSource instead of TISCopyCurrentASCIICapableKeyboardInputSource This fixes the issues with shortcuts not appearing correctly in Japanese. I am not sure what the difference is but: 1. We were using TISCopyCurrentASCIICapableKeyboardLayoutInputSource elsewhere in our code for the recorder shortcuts and that has been working. 1. MASSShortcut uses TISCopyCurrentASCIICapableKeyboardLayoutInputSource cocoabits/MASShortcut#60
When switching to non US (non-ASCII capable) keyboard layout
-keyCodeStringForKeyEquivalent
returns string with non-ASCII character, if a printable character was used in shortcut. But this character couldn't be used forkeyEquivalent
of theNSMenuItem
.I suppose it is better to use
TISCopyCurrentASCIICapableKeyboardLayoutInputSource
instead ofTISCopyCurrentKeyboardLayoutInputSource
in-keyCodeString
ofMASShortcut
.The text was updated successfully, but these errors were encountered: