Character callback with modifiers that is ALWAYS invoked for chars with pressed mods

[christianparpart]

Hi,

• initially discussed here: https://discourse.glfw.org/t/glfw-character-text-input-with-modifier-keys-control-meta-alt/1467
• GLFW version: 3.3 (on Ubuntu 19.10)

It is currently not possible to receive character events with modifiers for all characters that were typed in.

My demo was: A user is typing in Ctrl+[ in standard (en_US) keyboard layout works just fine with key as well as char callback but if you use (for example) de_DE (German[y]) keyboard layout, then in order to send a Ctrl=[, what the user has to press is Ctrl+AltGr+8. This is captured by the key callback as Ctrl+Alt+8 (which is not helpful because the user app itself SHOULD NOT re-implement keyboard layout mapping nor do I know what keyboard mapping the user has) and more importantly, the character callback is not invoked for that, neither is the character-with-modifier callback being invoked for that.

My request basically is to let the character-with-mods callback know about ALL characters being typed in with all modifiers - it also feels like a bug to me that this callback isn't invoked on non-en_US keyboard layouts (my test-case: de_DE), so I'm not sure it actually is a bug or a feature request.

p.s.: I didn't find any resource telling me why glfwSetCharModsCallback is being deprecated. It seems this is the only function that makes sense for me to use (even though it's currently not really fully working); maybe someone knows where to look at for this decision?

Many thanks in advance,
Christian.

[dougbinks]

If you take a look at the issues for glfwSetCharCallback you'll see that it didn't work for the use-case you've described.

Basically a key press such as CTRL+ALT+8 will not result in a character, so there will be no call to glfwSetCharCallback nor to glfwCharCallback. This is not because GLFW is doing something to remove it, but because no character exists to represent this key combination.

However, the key combination ALT+8 does represent a character, [ for the keyboard layout in your example.

So the solution I proposed on the forum is that we need to extent glfwGetKeyName to be able to handle translations in the presence of modifier keys. So the new version would be something like:

const char* glfwGetKeyName ( int key, int scancode, int mods );

Note that glfw would either have to ignore the CTRL mods, or users of the API would need to know that CTRL as a mod will result in no character. I would prefer the later as being more obvious.

[christianparpart]

Many thanks for clarifying.

[zokrezyl]

Believe or not, working also on a C++ terminal emulator with OpenGL and facing exactly the same issue. Practically I am porting the work under https://github.com/zokrezyl/asciterm to C++.

Do we have any workaround atm? Btw. @christianparpart , would be happy to chat about your design approach if you are planning an open source implementation.

EDIT: @christianparpart I asume this is the source code: https://github.com/christianparpart/contour

[christianparpart]

Hey @zokrezyl

That sounds amazing, I think it is best to just email me if you want details. I would be happy to chat. ... christian@parpart.family is how you can reach me .

But with regards to glfw. Kitty maintains its own fork and I just ported to QtGui. And to be honest, I don't regret it. :)

See you in your email,
Christian.

[xslendix]

Hello, any updates on this?

[christianparpart]

Hello, any updates on this?

@xslendix I gave up on GLFW3 a long time ago. My way to fix all the input issues I had with GLFW was to simply move to Qt. While it may sound heavy, I only link against QtGui (and now also Qt's QML), because all I needed from it was Window creation and input handling. Qt can be quite slim. I also lately made use of QML and so far do not regret in having moved off GLFW for a project like a GUI terminal emulator. -- I keep the frontend connector code quite slim however, to be free to switch in the future just in case i feel like it must be done (again).

[ghost]

any more updates in 2024?

[christianparpart]

any more updates in 2024?

Port to QtOpenGL, seriously. Let go of glfw. I gave up on it. I do not regret it. :)