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

Martin Fox github.com+12087024+beldenfox at openjdk.java.net
Tue May 25 21:49:05 UTC 2021


On Tue, 25 May 2021 10:40:50 GMT, Tom Schindl <tschindl at openjdk.org> wrote:

>> Is there some reason you would prefer a Swing-style implementation over the approach I submitted in this PR? The Swing code breaks down if an accelerator calls for the Option modifier alone or in addition to Command. I'm still investigating work-arounds.
>> 
>> (Long story short, Command alters the character we receive in a good way, providing a low-ASCII character even on non-ASCII layouts like Cyrillic. Option alters the character in a bad way, often producing an arbitrary symbol. Prior to macOS 10.15 we can't toss one modifier without tossing the other short of using UCKeyTranslate.)
>
> @beldenfox I did not say that the swing version is the way to go and in the end its @kevinrushforth call what route should be taken - I just wanted to show what my initial change would have been without saying it is better than what you are proposing which sounds like is more complete than what swing provides today.

@tomsontom I've added the Swing-style code as WIP PR #519. There are comments in the PR that probably should be in the code but I wanted to reduce the code diffs.

PR #519 (and Swing) tend to get codes for punctuation keys wrong on non-US layouts. That's not a big issue for accelerator processing since accelerators involving punctuation should use KeyCharacterCombinations which work even if the underlying key codes are wrong.  (I can't seem to find documentation that tells developers how to choose between KeyCodeCombinations and KeyCharacterCombinations. Am I missing something?)

There are isolated instances where PR #519 assigns a letter code to a punctuation key. For example, on the French keyboard it assigns KeyCode.M to the comma/question mark key which is where the M key is on the US layout. This means an app that uses both M and one of those punctuation characters as accelerators might see both fire. This might be a non-issue, the same problem afflicts the current code and I didn't run across any bugs on that.

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

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


More information about the openjfx-dev mailing list