On Thu, 25 Mar 2021 17:41:40 GMT, Martin Fox 
<github.com+12087024+belden...@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.

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.)

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

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

Reply via email to