Page MenuHome

Support for binding additional keys
Confirmed, LowPublicDESIGN

Description

There are keys which aren't included in Blender's keymap.

However it doesn't make sense for us to include all possible keys, as there are many which don't make sense (system-wake, calculator, eject, brightness-up, ... see a full list).

Recently we have added some keys which can be useful.

  • Application key (used for context menu)
  • F20-24 (for users to have keyboards with additional F-Keys).

This task is to keep track of other possible additions to the keymap.

Open Topics:

  • How to handle non US keymaps?
    • We could support binding raw keycodes (so we don't need to expand our fixed table of keys to include keys from all keyboard layouts).
    • We could support keyboard layouts, which all include the US keymap, extending on it for keys it doesn't include. This could be selected as a preference.

Event Timeline

Campbell Barton (campbellbarton) renamed this task from Support for binding other keys to Support for binding additional keys.Jan 17 2020, 3:11 PM
Campbell Barton (campbellbarton) changed the task status from Needs Triage to Confirmed.
Campbell Barton (campbellbarton) triaged this task as Low priority.
Campbell Barton (campbellbarton) changed the subtype of this task from "Report" to "Design".
Campbell Barton (campbellbarton) updated the task description. (Show Details)

For Windows, we're mostly looking at how Blender handles the VK_OEM_1-VK_OEM_8 range when we're talking about layout support, right?

There is small issue, the quote ' key displayed as " in the keymap and cannot be found by typing ' character.
So you need to press Shift + ' which is confusing.

{QUOTEKEY, "QUOTE", 0, "\"", ""}

Open Topics:

  • How to handle non US keymaps?
    • We could support binding raw keycodes (so we don't need to expand our fixed table of keys to include keys from all keyboard layouts).
    • We could support keyboard layouts, which all include the US keymap, extending on it for keys it doesn't include. This could be selected as a preference.

@Campbell Barton (campbellbarton) For offering just more unassigned keys to the user both options might be valid. But for shipped keymaps the raw keycodes are fitting much better.

A practical problem for a keymap that would contain both, raw keycodes and logical keycodes, would arise as a keymap might be free of conflicts with an US keyboard layout and have conflicts in another layout due to different overlaps of logical keycodes and raw keycodes based on what layout is chosen.

But for the design of a keymap it would be much simpler by referring to raw keycodes than by mapping something to extended logical keysymbols.
The second option could lead to many multiple assignments to different keys and also would contain the risk of conflicts.

The cleanest approach would be to change the current keymaps to consist mostly raw keycode bindings.
Problematic here would be things like ctrl+z which would be mapped to ctrl+y on a german QWERTZ keyboard if a raw key would be used here
But especially for things like numbers on a french AERTY keyboard layout option 1 would be benefitial

Another problem the second approach is unable to handle is that some keys are the base symbol of a key on a QWERTY. But are keys with Modifiers in other layouts.

So overall just the first option really makes sense to me.

Finally there should be some conversion comfort functionality to get from us layout keys to raw keys and the keymap editor should contain input and display related to a chosen layout.