On Thu, 25 Mar 2021 17:41:40 GMT, Martin Fox <d...@openjdk.java.net> 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’m not sure how to approach regression testing. MacOS 11 ships with 189 keyboard layouts and this PR changes the key assignments for 62 of them. On each layout there are just under 50 keys that might be affected. Some automated or manual sanity-checking tests would go a long way but the Robot code has bugs on every platform and I want to deal with the user-facing issues first (though this PR also fixes the Robot on Mac). For manual testing I run a JavaFX app that dumps out info on each key event. There’s one attached to this e-mail thread under the name KeyboardTest.txt. I use the Mac Keyboard Viewer app to visualize layouts that don’t match what’s printed on my keyboard. It’s also helpful to compare against a Windows box if you have one. When testing code changes I rely on a command line tool that runs through all the layouts and compares the results of the new algorithm against the old algorithm. This is useful for flagging issues that no amount of manual testing would be likely to find (ask me about Lithuanian digits some day) but I don’t really expect other testers to go that far. If you are testing this keep in mind that there are no key codes corresponding to accented characters or other characters that bear diacritic marks. Those keys will be assigned KeyCode.UNDEFINED. And stay away from dead keys, the way they behave on the Mac is, um, complicated. ------------- PR: https://git.openjdk.java.net/jfx/pull/425
