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:
- The VirtualKeyCode enum maps to U.S. keyboard characters
- 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?
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:
The first one is pretty obvious: on my keyboard, typing an
åsendsVirtualKeyCode::LBracket, and there are plenty of other mismatched keys.-isSlash,+isMinus, 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 mappingVirtualKeyCode::Xback 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 reversingVirtualKeyCode::Backslashinto\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?