SDL/GLFW text input events reported to both keyPressEvent() and textInputEvent()

[Getshi]

Hi!
I have set some numeric hotkeys in my magnum application, but now whenever I type numeric input into the text field of e.g. a DragFloat, then I can edit the DragFloat value but the event is still being processed by the magnum application as well.

More specifically:

void MyApplication::keyPressEvent(KeyEvent &event) {
  if (m_imgui.handleKeyPressEvent(event))
    return;

  switch (event.key()) {
  case KeyEvent::Key::One:
    // DO SOMETHING
    break;
[...]

handleKeyPressEvent does not return true for numeric input.
Actually, it does not return true when typing anything (e.g. "r") in the DragFloat text field; however, "r" is not being written into the text field, so one might argue that imgui ignores this event so magnum can process it, though I'm not sure if I wouldn't prefer if as long as the DragFloat text field is active, no key event would be processed by magnum.

Or am I simply missing some line of code?

[mosra]

Hi!

coincidentally, we were discussing this exact issue yesterday on the Gitter channel. The problem is that, for text input, SDL2 and GLFW fire both keyPressEvent() and textInputEvent() for each key that can be treated as text input. I was digging in SDL2 sources to find out a way if this behavior can be configured, but it just unconditionally fires both. Looking at GLFW docs, there's no way to override this either (didn't check the source tho) :/

If you scroll through the channel archives in the above link, an ImGui-specific workaround involves checking ImGui::GetIO().wantCaptureMouse and ImGui::GetIO().wantTextInput in addition to the return value from handleKeyPressEvent(), so maybe that could be a (temporary) solution for you as well?

A proper fix needs to be done on the Sdl2Application / GlfwApplication side, but so far I'm pretty clueless as how the fix should look, especially since the key press is fired before the text input, which is exactly the other way than what would be ~easily fixable. Googling around, I only found this thread but it quickly turned into a heated discussion involving OOP, with no useful information whatsoever.

[Getshi]

So

if (m_imgui.handleKeyPressEvent(event) || ImGui::GetIO().WantTextInput)
    return;

seems to be working fine, thanks for the quick suggestion! I've left out the ImGui::GetIO().WantCaptureMouse, since the even hovering a DragFloat would eat but the events.

Is there any reason this solution is just a temporary fix? Otherwise this could just be done automatically by handleKeyPressEvent.

[mosra]

If I'm not mistaken, the above is doing the same as this:

if (m_imgui.handleKeyPressEvent(event) || isTextInputActive())
    return;

This in practice means, if any text input widget is active, it disallows handling of any key press events. For example, that would mean Ctrl S to trigger a file save would not be working if a text area is focused. Or F1 to open a help. Etc.

So while the above works for you (and for majority of other users as well), the proper fix is to suppress the key press event only if it really produces some text input. And that's a thing I currently don't know how to handle portably -- it needs to take into account dead keys (diacritics), Unicode, IME etc.

[Getshi]

Good to know, thanks for the explanation!