Add ability to query CapsLock, ScrollLock, and NumLock state

[deanljohnson]

Summary

Currently there is no simple way within the Duality framework to query the state of the various 'lock' keys on a keyboard - CapsLock, ScrollLock, and NumLock. Consider how this could be supported from within Duality.

Analysis

• Could be implemented by updating a flag when the relevant key is pressed here.
• This may have issues when the initial state on app load is on for any of these locked keys.
• Does OpenTK have support for this already?

[ilexp]

Since people might find this while implementing a custom way to retrieve user entered text by manually checking key hit states:

Note: To detect text the user entered, use DualityApp.Keyboard.CharInput instead, which handles upper / lower chars, keyboard layouts and special character sequences.

[ghost]

@deanljohnson Sadly OpenTK doesn't have this functionality. I have implemented something as a test to see if I could get it working. But yes, the initial state of the key could be different to what's expected when the app loads. It sounds like this is something that's gonna be OS-specific.

@ilexp One more immediate solution is to use GLFW for this, they support it it shouldn't be too difficult to implement. I would be more than happy to get this rolling.

On the other hand, I don't know what version of OpenTK Duality uses but I know that OpenTK are slowly moving to use GLFW.

[ilexp]

I don't think this issue is high-priority enough to warrant moving away from the stable OpenTK backend to a new GLFW-based backend.

On the other hand, I don't know what version of OpenTK Duality uses but I know that OpenTK are slowly moving to use GLFW.

This might be a different story though - if OpenTK at some point gets an upgrade that makes implementing this feature possible (with or without GLFW somewhere in the background) we might still get access to it without additional overhead. Duality currently uses a somewhat old version of OpenTK in a custom fork, so upgrading isn't trivial but should considered at some point. More on this in issue #684.

[ghost]

I don't think this issue is high-priority enough to warrant moving away from the stable OpenTK backend to a new GLFW-based backend.

What I meant to say was to only include the specific GLFW methods to handle this specific issue; at least until we upstream.

This might be a different story though - if OpenTK at some point gets an upgrade that makes implementing this feature possible (with or without GLFW somewhere in the background) we might still get access to it without additional overhead. Duality currently uses a somewhat old version of OpenTK in a custom fork

If the plan is to upstream OpenTK maybe adding a GLFW backend wouldn't be a horrible idea though, right?

[ilexp]

What I meant to say was to only include the specific GLFW methods to handle this specific issue;

I'm not sure how this would be possible. The required methods are likely related to window management, and GLFW and OpenTK have completely different code for that. My guess would be those GLFW methods only work when the windows was created and is managed using GLFW.

If the plan is to upstream OpenTK maybe adding a GLFW backend wouldn't be a horrible idea though, right?

As long as our OpenTK backend (upstream or not) is stable, I don't see a reason to add a distinct GLFW one as well - it could mean a considerable maintenance overhead, so there would have to be a payoff that is equally big.