Complexities with international keyboard layouts (macOS)

[mrmekon]

See my two comments on the Alacritty project for more details: alacritty/alacritty#209 (comment)

Basically, there are two problems when trying to use winit for keyboard processing with non-U.S. key maps:

1. The VirtualKeyCode enum maps to U.S. keyboard characters
2. Key modifiers are always applied to the character

The first one is pretty obvious: on my keyboard, typing an å sends VirtualKeyCode::LBracket, and there are plenty of other mismatched keys. - is Slash, + is Minus, etc.

The second one is mostly a problem when you want to implement keyboard shortcuts, and is compounded by macOS always treating Option as AltGr. If you type <Option>-x, you receive the ≈ character with the alt modifier set. There's no generic way to get back the unmodified character, x. You can reverse this in your application layer on a U.S. keyboard by mapping VirtualKeyCode::X back to an 'x' yourself, but, thanks to the earlier problem, it doesn't work with other key layouts. On my keyboard, <Option>-' sends ™, and if I reversed it I would be reversing VirtualKeyCode::Backslash into \ instead of '.

It seems like one or the other of these needs to be fixed – though preferrably both – to use winit for raw key processing across key layouts.

I'm not sure if it's possible across all of the OSs, but possibly the VirtualKeyCode enum could encode the character that the key generates... so you would get VirtualKeyCode::Backslash(Some(')) when you press ™ on a swedish keyboard, and even though the name is wrong you can still extract out the 'base' key character?

[tomaka]

The VirtualKeyCode enum maps to U.S. keyboard characters

That's not supposed to happen.

[k0nserv]

What if Winit included the characters property from NSEvent in the Event struct? I believe this would have the correctly resolved character according to the user's keyboard layout. I haven't tested this, but I'll try it and report back

[k0nserv]

See my comments on alacritty/alacritty#682 for details

[jwilm]

I would like to dig into this. Does anyone with Cocoa/winit experience have any intuition what might be going wrong here?

[mrmekon]

I don't have much more insight, but just in case you missed it I did post some example code for handling dead keys in winit: mrmekon@f547bba

It's at least a reference for using those bizarre Carbon APIs. Figuring out the best way to pass all of that metadata down through winit... that's up to you ;)

[francesca64]

@mrmekon is there a reason you favored using Carbon APIs over implementing the NSTextInputClient protocol? I've mostly finished implementing that, and it seems to work with dead keys, IME, etc., but I want to make sure there's not an important reason you decided against using it.

[jwilm]

@francesca64 I'm excited to see that implementation! Does that happen to fix the issue where the emoji menu (hotkey: Cmd+Ctrl+Space) doesn't open up?

[mrmekon]

@francesca64 Nope, I had no reason for using Carbon other than that it was the first well-documented method I found. Looking forward to this being fixed!

[francesca64]

@jwilm I believe you'd need an Edit menu for that shortcut to exist. That said, I've confirmed that it's usable if I manually send orderFrontCharacterPalette.

The core of the implementation is done now, and I plan on making a PR once I've added an equivalent to send_xim_spot (which looks pretty easy). There's still future work that needs to be done, i.e. it's not currently possible to display a cute little underlined ´ prior to é appearing. This is far more bothersome when working with IME, but it's still a big improvement over the current state of affairs.

[francesca64]

@mrmekon can you test #518? I've included an Alacritty branch for it.