feat: support accelerator key strings , - . Space Tab and F13-F24

[probablykasper]

What kind of change does this PR introduce? (check at least one)

• Bugfix
• Feature
• Code style update
• Refactor
• Documentation
• Build-related changes
• Other, please describe:

Does this PR introduce a breaking change? (check one)

• Yes. Issue #___
• No

The PR fulfills these requirements:

• When resolving a specific issue, it's referenced in the PR's title (e.g. fix: #xxx[,#xxx], where "xxx" is the issue number)
• A change file is added if any packages will require a version bump due to this PR per the instructions in the readme.

If adding a new feature, the PR's description includes:

• A convincing reason for adding this feature (to avoid wasting your time, it's best to open a suggestion issue first and wait for approval before working on it)

Other information:
Add support for more accelerator keys: , - . = ; / \ ' ` [ ] Space Tab and F13-F24

[amrbashir]

Yeah we definitely need to make sure they are consistent across all platforms before we merge this, good thing I will be back by Saturday morning and I can help test this if no one beats me to it.

[amrbashir]

You can add these also to other platforms.

• Windows - format_hotkey() function in src/platform_impl/windows/menu.rs
• Linux - register_accelerator() function in src/platform_impl/linux/menu.rs and key_to_raw_key() function in src/platform_impl/linux/keyboard.rs, (this one is using the gdk keys from here)

[probablykasper]

Support here is already inconsistent between platforms. Tab and Esc are already supported on Windows, but weren't on macOS. You might think specifying unsupported keys is ok because nothing happens on macOS, but on Windows it actually panics.

On Windows, the format_hotkey() function already works fine, but key_to_vk() in keyboard.rs is what's lacking support. A bunch of keys in winapi don't have an obvious one corresponding to macOS.

The following are keys I didn't manage to add, so I've removed them from the PR:

• `
• \
• [
• ]
• =
• '
• ;
• /
• F25-F35

[probablykasper]

Brought Linux up to speed as well. Esc was already supported.

Tab is supposed to already be supported, but it's not working for me (even though it shows up correctly in the menu, and doesn't panic). Not something I'll tackle in this PR tho.

[amrbashir]

the missing vkeys on windows can be obtained by VkKeyScanW(']' as u16) in key_to_vk function. check how KeyCode::Digit1 is mapped in that function for reference.

[amrbashir]

Tab and Esc are not necessary imo so you can ignore them. Also F keys like >=F13 won't be used a lot so it is okay if they are not supported on all platforms.

[nothingismagick]

I think tab is important for keyboard navigation for visually impaired. Right @parker-codes ?

[amrbashir]

Keyboard navigation using Tab will still work, this PR addresses custom menu Accelerators and possibly global hotkeys.

But there is no harm in adding it this PR I guess, only macOS doesn't support Tab as accelerator so there is a minor inconsistency.

[parker-codes]

Yeah, as long as keys like Tab (or Shift + Tab) and Space are usable in general, as in they aren't being overridden, we're good.

It sounds like this is for combinations and shortcuts which doesn't seem like an issue to me. In fact, that can increase accessibility by allowing apps to offer quicker access!

[probablykasper]

the missing vkeys on windows can be obtained by VkKeyScanW(']' as u16) in key_to_vk function. check how KeyCode::Digit1 is mapped in that function for reference.

Will try that out, thanks!

About Tab, it's just on Linux that it's not working. Windows already supports it fine, and macOS support is added in this PR. Opened issue #242 for it.

[probablykasper]

All good now!