Add extra keys

[thedmd]

This PR add definitions for keys A-Z, 0-9, F1-F12 and support for them in all platform backends.

Since support for every key is optional and depends on content of io.KeyMap it should not introduce any incompatibilities.

I found myself adding support for extra keys in every project that used keyboard shortcuts. So maybe it will be useful also for others.

Note: Marmalade goes up to F10. I didn't found constants for F11 and F12.

[ocornut]

Some question:
A-Z keys are not localized and this has been the main issue that has been blocking me (see #456, and from glfw/glfw#672 (comment)). How are you using them, I assume you are using them in a context where you don't cater for multiple keyboard layout?

I've been thinking about removing the indirection completely. While the intent was initially to allow people using their native defines to access keyboard functions, this bring on two issues: the code becomes not portable accross back-ends, and this is not workable when the underlying value are not small values (which is the case for SDL keycodes (not scancodes) and OSX inputs). So perhaps the solution would be to just get rid of that indirection and embrace providing a large ImGuiKey_ enum like most frameworks are using. I'd like to think about it discuss the design of that path and how it would break the IO api. I'd like to have this discussion because if we establish this is too big of a change, I'll leave it for 1.80 or even maybe 2.00 and maybe merge a PR like yours soon. If we establish there is a path for changing that IO system that wouldn't be too destructive for users, we may aim for that path directly.

( Linking to #2005, #1924 - I think I'll close #1924 as this pr is more suitable anyway )

[ocornut]

Taking a tangeant of solving the localization problem I am seeing:
I looked into what it would take to get things right with GLFW (see new issue glfw/glfw#1502)

Since we are dealing with UI, I would like to clarify that I think the ImGuiKey_XXX values should correspond to translated keys, and we'll figure out a glfwGetKeyName()-based workaround for GLFW or simply will use untranslated keys.
But since the IO layer of dear imgui is convenient for many use, including uses that could want to rely on physical layout for some use of keyboard (e.g. WASD) we might want to actually switch to using two arrays, one for translated keys, one for untranslated ones?

[thedmd]

I'm using Windows WM_* messages and Qt to feed IO with input data, so I never encountered problem with different keyboard layouts with ImGui.

That being said, there are some my initial thought on this topic.

I skewing into 'backend did the right thing' camp by feeding io.KeyMap with translated keys. Indirection doesn't look like an issue. Actually I find it handy, because I sometimes feed IO with events from Qt, sometimes from WM_* messages directly.

Access to physical keyboard layout for WASD seems to be out of the scope of the UI. It may be tackled by providing an optional IO extension + some convenience API on top and leaving heavy lifting on backend side.

I read related all linked issues and never encountered pattern already present in ImGui:

#ifdef __APPLE__
ImGui::SetNextShortcut(ImGuiKey_A, ImGuiModKey_Cmd);
#else
ImGui::SetNextShortcut(ImGuiKey_A, ImGuiModKey_Ctrl);
#endif
if (ImGui::Buton("Select All"))
{
    // ...
}

One may argue that define is not a convenient solution. I agree that it is not typing friendly. Another approach may be more convenient:

// after creating context
#ifdef __APPLE__
ImGui::DefineAction("SelectAll", ImGuiKey_A, ImGuiModKey_Cmd);
#else
ImGui::DefineAction("SelectAll", ImGuiKey_A, ImGuiModKey_Ctrl);
#endif

ImGui::SetNextAction("SelectAll");
if (ImGui::Buton("Select All"))
{
    // ...
}

Or pushing things even further:

// after creating context
// void DefineAction(const char* id, const char* label, int key, int mods);
#ifdef __APPLE__
ImGui::DefineAction("SelectAll", "Select All", ImGuiKey_A, ImGuiModKey_Cmd);
#else
ImGui::DefineAction("SelectAll", "Select All", ImGuiKey_A, ImGuiModKey_Ctrl);
#endif

// `##!<id>` Will make button query action details.
if (ImGui::Buton("##!SelectAll"))
{
    // ...
}

In any case I don't know for sure if there is a reasonable way of getting rid of platform dependent action descriptions. Maybe if ImGui predefine some common ones. User may always add more.

[thedmd]

Should I move shortcut discussion elsewhere?

[ocornut]

You may post the shortcut specific stuff in #456
(I'm terribly late with other work I'd like to make progress on soon - tables - so I'll leave this topic dangling but I think the key enum is something we can be looking at in the near/mid future).

[thedmd]

Green again.

[thedmd]

Rebased on 1.74

[ocornut]

Thank you Michał for the rebase. I hope we can tackle the keys for 1.75 (my biggest issue loosely associated to this is that Glfw currently doesn’t provide an obvious path for translated + untranslated keys required for shortcuts - will push a little work on this front as well).

[thedmd]

Sounds great!

Issue on GLFW does not look like moving forward. Are you planning to address the issue in ImGui or to allow GLFW to be whacky until fixed?

[ocornut]

We'll do both, find the workaround on imgui_impl_glfw and pushes PR to GLFW for future versions.

[thedmd]

Rebased on 1.76.

Issues with GLFW and shortcuts don't seems to be around the corner. Ability to bind more keys to ImGui is something I find useful all the time regardless of translation issues.
Do you think this PR can get a pass?

[ocornut]

Hello,

I will try to evaluate it. I don't necessarily need to have the GLFW etc patches in to merge it, but I'd like to know we have a safe and forward-compatible way to eventually allow both types of key mapping.

Because Dear ImGui apis are used for so many things including custom widgets, it seems viable to lay out a plan where both translated and untranslated keys are somehow available. When the use of a key relates strongly to the actual letter (e.g. shortcuts CTRL+S = Save) we'd want to use translated key. Then the use of a key relates to the physical position on the keyboard (QWSD) we want to use untranslated keys.

Without necessarily making a PR for it, if you can help me come up with a design that would satisfy this, we'll faster have the visibility we need to merge this. (If I merge this today I think we'll also increase the incentive for people to stop using their native keys indexes. Which is good because native keys indexes are problematic for portability.)

[ocornut]

This has now been merged along with a rework of IO api. See #4858 for details.