Key::Unicode on MacOS does not behave the same way as on Windows & Linux

[UE2020]

Describe the bug
On Windows & Linux, calling enigo.key(Key::Shift, Press) followed by enigo.key(Key::Unicode("1"), Press) produces an exclamation mark in a textarea. On MacOS, a number one is produced. This is reproducible only with numbers (shift + any letter produces the expected uppercase letter).

Expected behavior
Holding shift and a number should produce the special character associated with that combination regardless of the OS.

Environment

• OS: Tested on Windows 11, Arch Linux on X.org, and MacOS ventura 13.2.1 (22D68) running on Mac M2 Air
• Rust: rustc 1.79.0 (129f3b996 2024-06-10)
• Library Version: 0.2.1

[pentamassiv]

If you want to enter text, you should always use the text() method. Entering individual keys is slower and -at least for now - can lead to inconsistent or unexpected behavior. I need to improve it

[UE2020]

The text() method isn't a solution for me because I'm using enigo in a remote desktop app, where keys should be held for as long as the client on the other end holds them. Right now I think get_layoutdependent_keycode is at fault.

[UE2020]

@pentamassiv I fixed the issue in my project by replacing the get_layoutdependent_keycode function with a hardcoded match statement from this C function. Obviously this means that only ascii characters can be emulated with Key::Unicode, but that doesn't matter for my usecase. You can see the changes I made at my fork of enigo.