ImGuiKey is missing a value suitable for the extra ISO keyboard key

[tom-seddon]

Version/Branch of Dear ImGui:

Version: 8add6bc
Branch: docking

Back-end/Renderer/Compiler/OS

Back-ends: Win32+DirectX11 example_win32_directx11
Compiler: VS2019
Operating System: Windows 10 22H2

My Issue/Question:

ISO-type keyboard layouts have an extra key compared to US ANSI layout keyboards. But if you're trying to support this extra key in your custom backend, you'll find there's no suitable entry in the ImGuiKey_ enum for it.

For many purposes, this won't matter. Provided the correct char comes through in the text input chars queue, you'll get the right effect when typing into a text input widget, and that will cover the vast majority of case where you'll want to enter an arbitrary key.

But if you want to use the Dear ImGui keyboard state for all your app's input, it would be useful to be able to track this extra key's state properly.

[ocornut]

What does that keys maps to at lower level in various backends?
(VK_ value, GLFW_KEY_ value etc?). What appears in Demo->Inputs when pressing it ?

[tom-seddon]

All tests performed using an ISO-style UK English keyboard. The extra key is between Left Shift and Z and is marked \|.

I used the imgui demo metrics/debugger window, input section, and I watched the keys down/pressed/released row.

(The chars queue looked to be behaving correctly - I think! The demo app seems to have a 7-bit font so a few of the chars are unprintable.)

Windows, United Kingdom keyboard layout:

Windows SDL3+DX11: the extra key comes through as Backslash, corresponding to its key markings. There is no key status for the key marked #~ (SDLK_HASH in SDL3 terms)

Windows Win32+DX11: the extra key comes through as Backslash, corresponding to its key markings. There is no key status for the key marked `¬ (VK_OEM_8). (Also, the '@ (VK_OEM_3) and #~ (VK_OEM_7) keys are incorrectly reported - looks like the vkey setup for the UK layout is just noticeably different from the US layout - probably a rabbithole trying to fix this properly)

macOS, British keyboard layout:

macOS OSX+Metal: there is no key status for the extra key, which comes through as key 0x0a (kVK_ISO_Section)

macOS SDL2+SDL_Render: there is no key status for the extra key, which comes through as key 0xa7 (167) (there seems to be no constant for this - it's the codepoint for the symbol it produces: §)

--Tom

[ocornut]

I'm a bit confused by your message. You seem to be talking about multiple keys?
Afaik the extra key in UK keyboard is this one:

Yet you talk about |\ which exists in both UK and US keyboard (albeit at different locations).

(Also, the '@ (VK_OEM_3) and #~ (VK_OEM_7) keys are incorrectly reported

How are they reported?

Are you able to run the GLFW examples as well?

[tom-seddon]

Yet you talk about |\ which exists in both UK and US keyboard (albeit at different locations).

Apologies, yes, I was thinking from the point of view of my fingers: there's a key between Left Shift and Z on a UK keyboard, and no such key on a US keyboard, so that must be the extra one! But it does probably make more sense to think of UK #~ as the extra key instead.

For whatever it's worth, here are some GLFW results. Cap(Unsh) is what's on the keycap for the unshifted case, and Cap(Sh) is what's on the keycap for the shifted case. GLFW key code is the value passed in to ImGui_ImplGlfw_KeyToImGuiKey, and ImGui key is the ImGuiKey value that results.

Windows, UK PC keyboard, United Kingdom keyboard layout. The keycaps reflect the chars the keys produce in other apps.

Cap(Unsh)	Cap(Sh)	GLFW key code	ImGui key
\	|	92	Backslash
#	~	92	Backslash
`	¬	96	GraveAccent

macOS, UK PC keyboard, British keyboard layout. I also list the chars produced when the keys are pressed in other apps, as UK Apple keyboards have a slightly different layout. Sorry, I only have UK PC keyboards available.

Cap(Unsh)	Cap(Sh)	Char(Unsh)	Char(Sh)	GLFW key code	ImGui key
\	|	U+00A7 § SECTION SIGN	U+00B1 ± PLUS-MINUS SIGN	161	<none>
#	~	U+005C \ REVERSE SOLIDUS	U+007C | VERTICAL BAR	92	Backslash
`	¬	U+0060 ` GRAVE ACCENT	U+007E ~ TILDE	96	GraveAccent

Thanks,

--Tom

P.S., regarding the VK_OEM thing, I will file a separate bug for the Win32 backend specifically later, with a proper table for the full results across both keyboard types. The same basic problem does apply though: there's a key you can press that currently has no ImGuiKey value for it, and there are currently no spare values in the ImGuiKey enum that could be assigned to it

[Dregu]

To clear the confusion, the fake extra key next to ISO enter (occupying half of the ANSI enter) is functionally and electrically the same as the key above ANSI enter (occupying half of the ISO enter).

The actual physical "extra key next to Z" also produces different things depending on the Windows layout. On Finnish, it's just Char 0x3C (<), with not KeyDown at all. On UK, it at least produces KeyDown.

KeyDown Backslash on Finnish is actually produced by the "key next to 1" and on UK that is the one with no KeyDown.

Every single non-alpha-num character is actually misrepresented in KeyDown on Finnish, like in every application, but that's another story... The real problem to me is the keys that might not produce KeyDown at all, which to my knowledge is only those two.

Tested with the same Windows version, commit and backend in Demo->Inputs.

[tom-seddon]

but that's another story...

Indeed. I figure Dear ImGui's text input mechanism covers a useful proportion of the problem cases in practice here, i.e., you are typing text in your preferred language in a text box and you want your usual keyboard layout to be in effect.

(but I am an UK English speaker, so all I need is 7-bit ASCII, and maybe £, so take this with a pinch of salt...)

The real problem to me is the keys that might not produce KeyDown at all, which to my knowledge is only those two

Interesting to hear about the additional problem key with the Finnish layout, thanks. And, yes, this bug is very much about the fact you can press keys that don't have a Dear ImGui key enum value for them and are therefore invisible from the point of view of the key up/down info.

The actual Dear ImGui key enum value in each case is not quite irrelevant, but, especially for non-alphanumeric keys, it's probably hard to solve this problem perfectly without going down a real rabbit hole.

For my part I would be satisfied by having an extra (say) 16 values in the enum called ImGuiKey_ExtraKey0...ImGuiKey_ExtraKeyF, and if the default backends support them then great but if not then this leaves space for custom backends to deal with this as suits them best.

[tom-seddon]

Submitted a PR with a new ImGuiKey enum value, and a case for it in the WIn32 backend. The new key has a somewhat generic name, on the basis that ImGuiKey values are named after US keyboard keys and this key doesn't exist on US keyboards.

An additional value is necessary, but the name in the PR is just a suggestion.

[Kazade]

FWIW SDL calls this key: SDL_SCANCODE_NONUSBACKSLASH :)

[ocornut]

FWIW SDL calls this key: SDL_SCANCODE_NONUSBACKSLASH :)

That's not a key that's a scancode though.
As mentioned in #7201 i don't think we can get anywhere without a solid global view of everything.

[ocornut]

I have pushed a9e5382 which sensibly rework a few things.

• A Oem102 key was added. It's emitted based on scancode 86 rather than VK_OEM_102.
• Other surrounding keys are relying on scancodes rather than keycodes for Win32, SDL2, SDL3 backends.
• As a result some of those keys are now "untranslated" aka referring to US layout.
• There's no perfect solution to the larger problem discussed in those issues, so trying to come up with a reasonable one.

I would appreciate if you can test the new code.
I believe the OSX backend may need an update too.

I have amended https://docs.google.com/spreadsheets/d/1TwAHusBpxf_avmk03FUSrni17RP8qXmbJeDzs5fs0nY/edit?pli=1&gid=0#gid=0 with a column describing expected result with newer code.