You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So our signature for glfwGetKeyName could look like (key: int, scancode: int) =>Glfw_Key.t
This is primarily for performance consideration - if we return the string to the OCaml side, we'd have to copy the string into GC-managed memory, whereas passing the integer does not require copying.
The text was updated successfully, but these errors were encountered:
The
glfwGetKeyName
API would be useful to have: https://www.glfw.org/docs/latest/group__input.html#ga237a182e5ec0b21ce64543f3b5e7e2beI'm not sure what the JS equivalent would be, so for now, we could just implement this on the native side (and a stub with a warning in the JS code).
The one change I would consider with this API is returning the integer equivalent of the returned string (for example,
GLFW_KEY_A
should return65
: https://github.com/bryphe/reason-glfw/blob/d128062ef93afd54f0d42cf128c54e79d46be231/src/glfw_key.re#L126).So our signature for
glfwGetKeyName
could look like(key: int, scancode: int) =>Glfw_Key.t
This is primarily for performance consideration - if we return the string to the OCaml side, we'd have to copy the string into GC-managed memory, whereas passing the integer does not require copying.
The text was updated successfully, but these errors were encountered: