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

[Martin Fox]

On Tue, 16 Mar 2021 19:48:56 GMT, Martin Fox <github.com+12087024+beldenfox at openjdk.org> wrote:

>> Maybe this is a very dumb idea but why are we not using the char to map back to the keycode? At least for everything in the ASCII-Range this would be ok not? We'd only have to check for special keys (like NUM-Keys, F-Keys, ...) first. So once we checked and the text is of length 1 we could do the mapping from the char.
>
> The Function/arrow/number pad keys are handled using a hard-coded table since they don’t vary based on keyboard layout. Beyond that you’re asking exactly the right question.
> 
> JavaFX KeyCodes seem to be modeled on similar systems present in Windows and X11. On these platforms the system assigns a key code to each key which remains stable regardless of the modifier state. The system tries to ensure that codes for A-Z and 0-9 are assigned to keys even on keyboards that don’t generate Latin characters.
> 
> My implementation is conservative in that it’s trying to emulate the behavior of Windows and X11 and associate each key with a stable code including A-Z and 0-9. On the Mac that has no real utility when it comes to accelerator matching, we could use the character information in the event to generate the JavaFX key code and still match user’s expectations. But that would break other JavaFX assumptions, like that the key code is stable. Take the =/+ key on the US keyboard as an example. If Cmd is not held down it will generate = or + depending on the shift state and so vary between KeyCode.EQUALS and KeyCode.PLUS. And key events for non-Latin characters would have an UNDEFINED KeyCode until Cmd was held down and we got a useable ASCII character.
> 
> I have no idea if these deviations from the original design would be an issue. At this point I’m pretty sure that any problems would lie outside accelerator processing e.g. with the Robot.
> 
> P.S. What I would not do is what Swing is trying, namely to emulate Windows  (stable codes, A-Z present, etc.) using just the NSEvent character information and heuristics. That’s generating all sorts of oddness under the hood. Better to generate UNDEFINED KeyCodes than bad guesses.

I've written a command line utility that runs through all the keyboard layouts available in macOS 11.2.3 and generates a report on how this PR would change the Java key codes for each layout. I used it to spot-check the behavior on various layouts and to flag potential trouble spots (like Lithuanian where digits are typed using a dead key.) I thought it would also be useful for this review. For example, I can now say that with this PR Meta-, (comma) will still be available on all layouts.

If the report would be of interest where should I put it? Add it to this PR, attach it to a comment in this thread, put it someplace public and link to it?

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

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