Custom Keybinds

[CosmicHorrorDev]

I'm planning on adding support for specifying custom keybinds this weekend. This is the general gist of how I want to expose it

# Custom keybinds for actions
# Each entry maps an action to a key combo
# Action -> predefined list of possible interactions to perform
# Key Combo -> Either a single modified key or an array of modified keys
# Modified Key -> Either an unmodified key or an obj with a key and modifiers
# Possible Modifiers: ["Alt", "Ctrl", "Os", "Shift"]
#     (Note: shift can only be used on keys that don't have a different key for
#     no-shift and shift like "Enter" or "Space")
# Possible Actions: [
#     "ToTop", "ToBottom",
#     "ScrollUp", "ScrollDown",
#     "PageUp", "PageDown",
#     "ZoomIn", "ZoomOut", "ZoomReset",
#     "Copy",
#     "Quit",
# ]
# Possible Keys: [
#     ... All the typical letters, numbers, and symbols
#     "Enter", "Space", "Tab", Backspace", "Esc", PageUp", "PageDown",
#     "PageLeft", "PageRight", "Home", "End", "Delete", "Insert", "F1"-"F12", etc.
# ]
keybinds = [
    ["ToTop", "Home"],
    ["ToBottom", "End"],
    ["Copy", { key = "c", mod = ["Ctrl"] }],
    ["ToTop", ["g", "g"]],
    ["ToBottom", "G"],
    ["Copy", "y"],
]

One thing that I noticed that may complicate things is that a surprising number of keys don't get picked up with a VirtualKeyCode on my keyboard like $%^&() etc.

Another thing is that there may be system differences here too. I noticed that @trimental uses VirtualKeyCode::Equals+Shift to detect a "+", but for me it registers as a VirtualKeyCode::Plus. It's actually impossible for me to use VirtualKeyCode::Equals with shift on my keyboard layout. Switching to using the scancode could fix this and the missing keys issue

[CosmicHorrorDev]

Looks like the scancode doesn't make sense for this application :/

I'll have to dig into why the virtual keycodes aren't always resolved / are resolved to different keys

[CosmicHorrorDev]

Meh rust-windowing/winit#1806

May just be an issue we get to live with for a bit. I'll just start working on customizable keybindings and then hopefully a future update to winit resolves these issues

[trimental]

@LovecraftianHorror Yeah I ran into the issue that VirtualKeyCode::Plus isn't emitted. A really annoying 'bug' of winit, or just some macOS behaviour they're yet to consolidate. Honestly looking at how long it's taken to get a clipboard feature added into winit (still waiting), it seems like we could wait a while for that to be fixed.

The problem is that with every platform winit supports, there's a thousand things that become too complicated to support properly. I created smithay-clipboard in 2019 to get around winit not handling clipboarding by pumping its own wayland events on a background thread (major hack) and its still used today by Alacritty.

Moral of that story is hacking your way around winit is practically the officially supported way to do things. I'll have a look if alacritty's solved this or its just another hack.

[trimental]

It seems Alacritty uses macros to parse key bindings into winit VirtualKeyCodes and checks for modifiers.

I would suggest just choosing some sensible defaults for key bindings and then let users configure the key bindings that work for their system. $%^&() probably is just 456790 plus Shift in your case. It'll annoy users but theres really no way around it right now, at least they have the option to try out the binding that works.

[CosmicHorrorDev]

$%^&() probably is just 456790 plus Shift in your case

I wish it made that much sense :/

It seems like it doesn't resolve to a virtual keycode at all for some reason. 4 gets picked up, but 4+Shift is None

[2022-08-24T00:15:55Z DEBUG inlyne] Keyboard input: scancode=5 keycode=Some(Key4)
[2022-08-24T00:15:56Z DEBUG inlyne] Keyboard input: scancode=54 keycode=Some(RShift)
[2022-08-24T00:15:56Z DEBUG inlyne] Keyboard input: scancode=5 keycode=None

I guess as a last resort we can let user's specify the scancodes. It's not a portable solution, but I think it's fine as long as we clearly state that it's a last resort

I would suggest just choosing some sensible defaults for key bindings and then let users configure the key bindings that work for their system

That's the plan 👍