OSX scan_code doesn't match other platforms

[SonicZentropy]

So in glutin's application.rs, the WindowEvent::KeyboardInput branch grabs the scancode from the input event and converts it to tuix event via scan_to_code(). Scan_to_code is broken for OSX because OSX maps its scan codes differently. Using the KeyZ example from the cpal tutorial, that scancode on osx isn't KeyZ, it's Digit5

Winit solves this by providing an alternative field on KeyboardInput, virtual_keycode, which can be mapped by all OSs instead.

Ex: in keyboard.rs, rather than scan_to_code, you can use a different transform fn like this

pub fn vcode_to_code(code: VirtualKeyCode) -> Code {
    use Code::*;
    match code {
        VirtualKeyCode::Z => { Code::KeyZ }
        _ => { println!("Got something in vcode other than Z"); Code::KeyA}
    }
}

I haven't done the rest of the mappings yet because I'm not sure exactly how you want to approach this or what else it could break, but this fixes the synth example code specifically for KeyZ. Once we chat about it I'm happy to finish it off and PR

[geom3trik]

Another potential solution for this problem could be to have a different scan_to_code method for mac os. I think this would equate to about the same amount of work but would allow the removal of virtual key codes being sent in key up and key down events.

[SonicZentropy]

yup that would work too! That fn is just crazy tedious to write and I lazy'd out and went with the universal fix

[SonicZentropy]

If anyone wants the full vcode table as well, I dropped it here:

https://zerobin.net/?7979275d556ac9dc#F8vc6C3kBGEmE4vdcC669DKHwp33qrgdW/hKGXEyznM=

[geom3trik]

If anyone wants the full vcode table as well, I dropped it here:

https://zerobin.net/?7979275d556ac9dc#F8vc6C3kBGEmE4vdcC669DKHwp33qrgdW/hKGXEyznM=

Ah this is great! Would you like to add this as a PR?

[SonicZentropy]

I surely can, but I'm not certain it won't break anything. This was the first time I'd ever had OSX misbehave through winit, so I went to look at my old wgpu code and realized they use this virtual keycode instead of scancodes. I poked through winit just now and I believe it's basically doing the multiple scan_to_code per-OS internally and exposing the result via that virtual keycode.

Their docs suggest winit's normally intended to be used via those virtuals instead: https://github.com/rust-windowing/winit/blob/master/examples/control_flow.rs

The winit docs also touch on it inside their KeyboardInput struct https://docs.rs/winit/0.24.0/winit/event/struct.KeyboardInput.html and I think also suggest we use VirtualKeyCode for this.

I've tried it on Win 10/OSX/Manjaro and it seems to work just fine, but we could maybe leave every OS except mac on the current scan code impl? I'm just not sure what the smart safe answer is

[SonicZentropy]

Update on this one, I went to double check with the Winit guys and they are right now finishing off a complete refactor of this system and said our code will need to change regardless soon. I think we probably want to just table this one for now until whatever winit does is done. Tracking meta issue for that is https://github.com/rust-windowing/winit/issues/1806

[geom3trik]

Okay fair enough. Though since we don't know how long this will take it might be work just adding a quick fix just for mac os so that widgets receive the right virtual keycode.

[SonicZentropy]

Yup rather than take a risk of breaking things, I can just drop my vcode table in for osx now and leave everything else the way it is until Winit's done?