Martin Fox
Martin Fox
The Robot implementation on Linux did not consult the current layout when mapping from a KeyCode to a hardware code. Internally it retrieved results for all the layouts but just...
Turning on warnings-as-errors for the macOS glass native code. Deprecated declarations are excluded and still appear as warnings. In the code that tries to locate the application's dock icon there...
This PR adds code to ensure that KeyCodeCombinations match KeyEvents as expected by more accurately mapping from a Mac key code to a Java key code based on the user’s...
When processing a `WM_CHAR` event on an OEM key (punctuation, symbol, dead key) the glass code will dynamically query the key's unshifted character to determine the Java code to assign...
The algorithm in `KeyCharacterCombination.match` relies on the call `Toolkit.getKeyCodeForChar` which is difficult to implement correctly. It defies the way most keyboard API’s work and no platform has got it right...
The code that maps from a Windows virtual key code to a Java key code in `getKeyCodeForChar` did not match the similar code in `ViewContainer::HandleViewKeyEvent`. The OEM keys are assigned...
There was a mismatch between the way `get_glass_key` generated the Java key code for a given key press and how `getKeyCodeForChar` determined the key code for the matching character. For...
I couldn't find any statement on the minimum version of OpenGL that LLGL is written for. While working with the sample Cpp programs I noticed that LLGL always enables GL_TEXTURE_CUBE_MAP_SEAMLESS...
I ran into divide-by-zero errors at four points in the code that led to NaN or Inf propagating through the conversion pipeline. I've come up with fixes for these based...
On Linux getKeyCodeForChar does not consult the current keyboard layout. For example, it assumes the “+” character is on KeyCode.PLUS even on layouts which don’t generate KeyCode.PLUS. The result is...