Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for untranslated key codes #3141

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

thedmd
Copy link
Contributor

@thedmd thedmd commented Apr 19, 2020

Add support for untranslated key codes (scancodes) for ImGui.

Intention is to provide forward way for ImGui to handle untranslated keys in response to #2625 (comment).

I introduced GetUntranslatedKeyIndex to map ImGuiKey_ into io.KeyDown index. Similar to what GetKeyIndex does. Difference is scancodes remain the same regardless of keyboard layout used and correspond to physical placement of the keys.

    IMGUI_API int           GetUntranslatedKeyIndex(ImGuiKey imgui_key);                               // map ImGuiKey_* values into user's key index == io.ScancodeMap[key] if supported, otherwise act like GetKeyIndex

Support for untranslated keys is an optional backend feature controlled by new flag:

    ImGuiBackednFlags_HasUntranslatedKeys = 1 << 4,   // Back-end Platform supports physical keyboard layout mapping to ImGuiKey_XXX.

For backends without support for this feature GetUntranslatedKeyIndex behaves exactly like GetKeyIndex.

PR provide an implementation in imgui_impl_win32.cpp backend as an example. More will be done as this idea mature.

Things I can think of out of the box that should be discussed:

  1. Is there a need for functions converting untranslated key to translated one?
  2. Should there be a function returning key names like:
    const char* GetKeyName(int key_index);
    
    // ImGui::GetKeyName(ImGuiKey_A) -> "A"
    // ImGui::GetKeyName(ImGuiKey_Z) -> "Z"
    // ImGui::GetKeyName(ImGuiKey_LeftArrow) -> "Left Arrow"
    Should GetKeyName be hardcoded, localized and/or system dependent?
  3. Scancodes are not portable, so should ImGui provide out of the box mapping from US layout only?
    image image source
    Maybe most common physical layouts to scancode mapping should be provided? Or one is enough beacause user will be able to pick keys according to default one.

Summing things up:

int g_StrafeLeftKeyIndex = -1;
int g_StrafeRightKeyIndex = -1;
int g_MoveForwardKeyIndex = -1;
int g_MoveBackwardKeyIndex = -1;

void Init()
{
    // Map to WSAD, will map to same physical keys on French, US and others
    // keyboards.
    g_StrafeLeftKeyIndex = ImGui::GetUntranslatedKeyIndex(ImGuiKey_A);
    g_StrafeRightKeyIndex = ImGui::GetUntranslatedKeyIndex(ImGuiKey_D);
    g_MoveForwardKeyIndex = ImGui::GetUntranslatedKeyIndex(ImGuiKey_W);
    g_MoveBackwardKeyIndex = ImGui::GetUntranslatedKeyIndex(ImGuiKey_S);
}

For French keyboard:

With untranslated key support Without untranslated key support
image image

Please let me know what do you think.

Edit:

Demo for French keyboard layout. I tap keys in same order in both cases.
imgui_untranslated_keys

@ocornut ocornut added the inputs label Apr 19, 2020
@thedmd
Copy link
Contributor Author

thedmd commented Apr 20, 2020

@ocornut If you find a minute please confirm that what I got is an intended behavior. Thanks!

@thedmd
Copy link
Contributor Author

thedmd commented Nov 28, 2020

Back to green.

@ocornut ocornut force-pushed the master branch 2 times, most recently from 0c1e5bd to bb6a60b Compare August 27, 2021 19:10
@thedmd thedmd force-pushed the feature/untranslated_key_codes branch 2 times, most recently from 9f2d52e to 35e191a Compare December 12, 2021 12:52
@thedmd thedmd mentioned this pull request Dec 12, 2021
@thedmd thedmd force-pushed the feature/untranslated_key_codes branch from 35e191a to 72e4a66 Compare December 13, 2021 17:41
@ocornut ocornut force-pushed the feature/untranslated_key_codes branch from 72e4a66 to 84c6df7 Compare December 16, 2021 17:09
@ocornut ocornut force-pushed the feature/untranslated_key_codes branch from 84c6df7 to 0cd3f8c Compare December 16, 2021 17:17
@thedmd thedmd force-pushed the feature/untranslated_key_codes branch 2 times, most recently from 620285c to e604d84 Compare January 5, 2022 15:17
@ocornut ocornut force-pushed the feature/untranslated_key_codes branch from e604d84 to 9ca1e27 Compare January 10, 2022 14:31
@ocornut
Copy link
Owner

ocornut commented Jan 10, 2022

Update on this (following our work and conversation with thedmd on e.g. #4858 #2625)

TL;DR;

  • This isn't actually needed. Because GLFW and SDL backends passed untranslated keycode (the former due to an issue in GLFW, the later due to how we accidentally needed to use scancode for indexing rather than keycode) it opened a conversation on keycodes, which is now resolved.
  • The only purpose I can think of right now is to make it easy for portable imgui-code to use WASD type of mapping. Arguably this may be out of dear imgui's purpose.
  • We thought about adding untranslated keycode to the io.AddKeyEvent() API but since their purpose is likely going to relate to mapping it would be problematic to have to wait until a key is pressed. Resolve we reverted to the idea that to solve this we want either a callback into the backend, into a mapping table provided by the backend.

For now we'll let this dangling as there's isn't much immediate use for this, but the branch has now been rebased over latest.

@thedmd thedmd force-pushed the feature/untranslated_key_codes branch from 9ca1e27 to 0e3414c Compare August 19, 2022 11:18
@thedmd
Copy link
Contributor Author

thedmd commented Aug 19, 2022

Now it dangle at v1.89 (18808) :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants