binding console to accent key

[Tes96]

So Bug 1420 is rejected because it is a duplicate, which is fine. But it looks like in Issue 371 they are saying to deny binding the console to any symbolic keys. So why can't this be fixed? Vanilla Morrowind uses the ` symbol for the console so I'm not understanding why OpenMW can't do the same.

[cc9cii]

I tend to agree on this one. I don't know what is involved but once I find some time I'll see what can be done.

[potatoesmaster]

The text is added to the console in InputManager::textInput (apps/openmw/inputmanagerimp.cpp). This method is used when SDL's text input mode is enabled (it is when text widgets are focused). The text input event does not mention the pressed key, only a text (an utf-8 code point?). Ignoring the console key requires to have the text it produces ("`", "~" or whatever else is set). We need to figure out how to get the string representation of a SDL_KeyCode (not the key name).

[Chris]

The text is added to the console in InputManager::textInput (apps/openmw/inputmanagerimp.cpp). This method is used when SDL's text input mode is enabled (it is when text widgets are focused). The text input event does not mention the pressed key, only a text (an utf-8 code point?). Ignoring the console key requires to have the text it produces ("`", "~" or whatever else is set). We need to figure out how to get the string representation of a SDL_KeyCode (not the key name).

Wouldn't it be better to process the console key event before attempting to add the key to the console input buffer? That way the console would never get the key in the first place.

[potatoesmaster]

The key is not specified in a TextInputEvent, only the text. I checked, both events are sent in text input mode. Assuming the order remain the same (it does for me), the keyboard event is received before the textinput event. We can cheat by ignoring the next text input event when the console key is received.

[Tes96]

I don't know what you guys are talking about and I'm sure this has been mentioned, but why not reverse-engineer what Bethesda did with Morrowind and copy the way they got their ` console to work?

[potatoesmaster]

Some said we don't reverse-engineer (i.e. disassemble) anything for legal reasons. Anyway, figuring how things work by that mean is not easy (having exploitable results is difficult). And it wouldn't be useful for the current problem, as OpenMW works differently from Vanilla in the way we handle keyboard events (we use different libraries).

[potatoesmaster]

@cc9cii, @chris:
The possible solution I evoked doesn't work (ignoring text event when the console key event is received). It would cause a random text input to be ignored after the console is close if the console is bound to a key that does not produce text (F2 for example). Also, I tried unfocusing the console widget when the console is closed. It doesn't work neither, though it prevents the character to be appended multiple times if the console key remains pressed. I suspect OICS to defer key events, because we receive text input events first, contrarily to my test program which uses SDL directly.

[Chris]

@cc9cii, @chris:
The possible solution I evoked doesn't work (ignoring text event when the console key event is received). It would cause a random text input to be ignored after the console is close if the console is bound to a key that does not produce text (F2 for example). Also, I tried unfocusing the console widget when the console is closed. It doesn't work neither, though it prevents the character to be appended multiple times if the console key remains pressed. I suspect OICS to defer key events, because we receive text input events first, contrarily to my test program which uses SDL directly.

Should be possible to delay opening the console until after all key events are processed, so the console key's text input doesn't get sent to the console, while still closing the console immediately on key press, so the console shouldn't receive any following text input.

If there's a problem with text events getting sent before the corresponding key events, we could buffer the text and process it after input events are handled. And instead of delaying the console opening, we could just skip processing text input when the console was toggled.

[cc9cii]

I think Chris's idea might work. One of the things I might have tried was to create a mini statemachine (a bit like input processing in shells or editors where hotkeys can be mapped & remapped at will - although they have low level access to key events if the input is buffered the same should be possible)