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

[Kevin Rushforth]

On Fri, 12 Mar 2021 16:27:27 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)

I see that the Windows pre-submit test build failed. It's clearly not related to anything in this PR, so it can be ignored.

I'll review this PR later (hopefully next week some time), but I have a couple general comments:

1. Would it be possible to provide an automated test? Maybe not since it is sensitive to the keyboard layout.
2. For the related bugs, we can either close them as duplicates of this bug or use the `/solves` command to list them here. Generally, we would do the former in the case it really is a single fix, as this seems to be. That's what I'll do once this bug is integrated unless there is a good reason not to. Normally we would use the earliest of the bugs, but in this case, I don't think it matters, so I have no problem with your using the one you chose.

@tomsontom Since you were the one who filed [JDK-8150709](https://bugs.openjdk.java.net/browse/JDK-8150709), and it's currently assigned to you, do you want to be the second reviewer on this?

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

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