RFR: 8150709: Mac OSX and German Keyboard Layout (Y/Z) [v4]

[Martin Fox]

On Thu, 25 Mar 2021 17:41:40 GMT, Martin Fox <github.com+12087024+beldenfox at openjdk.org> wrote:

>> 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 active keyboard layout (the existing code assumes a US QWERTY layout). The new code first identifies a set of Mac keys which can produce different characters based on the user’s keyboard layout. A Mac key code outside that area is processed exactly as before. For a key inside the layout-sensitive area the code calls UCKeyTranslate to translate the key to an unshifted ASCII character based on the active keyboard and uses that to determine the Java key code.
>> 
>> When performing the reverse mapping for the Robot the code first uses the old QWERTY mapping to find a candidate key. If it lies in the layout-sensitive area the code then scans the entire area calling UCKeyTranslate until it finds a match. If the key lies outside the layout-sensitive area it’s processed exactly as before.
>> 
>> There are multiple duplicates of these bugs logged against Mac applications built with JavaFX.
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8090257 Mac: Inconsistent KeyEvents with alternative keyboard layouts
>> https://bugs.openjdk.java.net/browse/JDK-8088120 [Accelerator, Mac] CMD + Z accelerator is not working with French keyboard
>> https://bugs.openjdk.java.net/browse/JDK-8087915 Mac: accelerator doesn't take into account azerty keyboard layout
>> https://bugs.openjdk.java.net/browse/JDK-8150709 Mac OSX and German Keyboard Layout (Y/Z)
>
> Martin Fox has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed whitespace error.

I would like to get this review restarted. Sorry I let it lapse for so long.

I was asked to evaluate a Swing-style solution which determines the Java key code based on the keystroke’s character. If the character can’t be mapped to a key code the system falls back to the US QWERTY key code instead.

I’ve run some test code that loops through the keyboard layouts in macOS (all 189 of them) to sanity-check this approach. The executive summary is that it’s entirely work-able and in isolation would involve a lot less code than the current PR. I say "in isolation" because I’m also working on code to fix problems with KeyCharacterCombinations on the Mac and those fixes rely on some of the same machinery, particularly the calls to UCKeyTranslate, so even if we removed most of that code for this PR some of it would just re-appear in the next.

If you want I could put together a separate PR that uses the Swing-style solution for comparison purposes. To make it a fair comparison I would also incorporate the changes for the KeyCharacterCombination problems (I don’t have the bug numbers handy).

The one place where this approach falls down is the Robot. To send a key event using the Robot we have to map from a Java key code to a physical key. If the key code is determined based on data that’s only available while processing a keystroke it’s just not possible to map the other way reliably. Swing punts and assumes a US QWERTY layout as does the current JavaFX code. This has produced bad results for years but based on the bug database I'm not sure anyone has noticed. (The code I submitted with this PR assigns key codes without reference to key strokes and can work in both directions reliably.)

A comment in the Swing sources describes this approach as "hokey" and I agree. It relies on most keyboard layouts being similar to US QWERTY and that most of the system ignores non-letter and non-digit key codes (this algorithm often generates bogus codes). But for all it’s hokey-ness it gets the job done surprisingly well.

-------------

PR: https://git.openjdk.java.net/jfx/pull/425