bsl/GLFW-b — pull request #21 by christiaanb (2012-04-02 10:28:59+00:00)
Title: Character Release Event

Let me start with the comment found in the bundled GLFW C-Library (glfw/lib/window.c _glfwInputChar):

if( action != GLFW_PRESS )
{
// This intentionally breaks release notifications for Unicode
// characters, partly to see if anyone cares but mostly because it's
// a nonsensical concept to begin with
//
// It will remain broken either until its removal in the 3.0 API or
// until someone explains, in a way that makes sense to people outside
// the US and Scandinavia, what "Unicode character up" actually means
//
// If what you want is "physical key up" then you should be using the
// key functions and/or the key callback, NOT the Unicode input
//
// However, if your particular application uses this misfeature for...
// something, you can re-enable it by removing this if-statement
return;
}
As long as the GLFW-b bindings are bundled with this version (2.7.3) of the GLFW C-library I would like to have the above if-statement removed or comment out. As my argument I want to present the current bizarre sequence of events:
* I register both char and key callbacks
* I hold down the 'shift' key on my US Intl. Keyboard
* While still holding down the 'shift' key, I press the '.'-button
* The char callback mechanism passes "Char '<' True" to my registered char-callback function
* I release the '.' button
* The key callback mechanism passes "Char '.' False" to my registered key-callback function

When the above mentioned if-statement would be removed, I would at least get a corresponding "Char '<' False" event. Now it feels like the '.'-button is released without ever being pressed, and the '>'-char is never being released.

p.s. Somehow I can't convince github to only include the changes to glfw/lib/window.c, so please ignore all the other files in the pull request.