This is definitely a hole in the API. However, key tokens like GLFW_KP_7 represent physical keys and not the function assigned to them by the OS, and changing that during 3.x would break existing applications.

Instead, I can add queries for lock key states and you can choose the behavior of the key based on the Num Lock state. Would that be sufficient for your purposes?

Being able to query num lock state is certainly a first step, however, it is a hack -- since the behavior of num lock is configurable at the OS level, and applications should follow the OS as much as possible. Otherwise, glfw based applications will behave differently than all other applications on systems where the behavior of num lock has been changed.

The ideal solution would be a key callback API that reports logical key names as reported by the OS after any keyboard layout/lock key mapping etc takes place. This will not break existing applications, which could continue to use the old API. The new API could either use a new callback function or a switch that changes the behavior of the existing one at runtime.

Yup, it won't work on systems with home-made keyboard layouts. Normally I'd argue that this is extremely rare, but you're writing a terminal emulator so that probably isn't true for your users.

The input system for GLFW is by design a simplified abstraction of the OS APIs geared towards games and related tools. I won't add another key callback but once it's time for 4.0 we can look into improving the existing key event. For now, with many higher priority features still to be implemented, lock key state is what I can offer.

Sure, I wont refuse the ability to probe the lock key state :)

And let me just say thanks for glfw, which apart from a few minor issues, works very well.

Either solution would be useful. I'm currently hacking around this by using a Windows system call.

I'm currently considering one of the following solutions:

Option 1: A function to query the current lock state:

int glfwGetKeyLock(GLFWwindow* window, int key);

Where key is one of GLFW_KEY_*_LOCK. The returned value would be up-to-date wrt the event currently being processed (think GetKeyState, not GetAsyncKeyState).

Option 2: Additional bits in the modifiers passed to the key and charmods callbacks:

#define GLFW_MOD_CAPS_LOCK 0x0010
#define GLFW_MOD_NUM_LOCK  0x0020

I vote for option 1 on the grounds that it is less likely to cause compatibility issues with code that checks the masks incorrectly.

You read my mind. Option 1 it is.

FWIW seeing this in GLFW 3.3 would be amazing!!

The modifier bit path was so much cleaner internally and conceptually simpler externally (no potentially out-of-date cached state) that I had to give it a try.

What do you think of f3de10d?

Fine by me.

I'd argue that this is extremely rare

I'm another guy who needed it for https://vcvrack.com/ to implement a togglable "virtual computer keyboard MIDI device" when Caps Lock is enabled. This is how most DAWs do it. Much thanks, and good API choice!

@AndrewBelt Good to know, thank you!

@elmindreda is this also released, like #1098 ?

@AngelDeaD Sort of. The 0e8c4ea patch above is merged and if you turn lock key modifiers on (see GLFW_LOCK_KEY_MODS) then you can tell them apart by GLFW_MOD_NUM_LOCK. Having actual separate symbols for the different uses of the same physical keys has to wait until 4.0.