On Mon, 17 Apr 2023 18:13:38 GMT, Martin Fox <d...@openjdk.org> wrote:
>> The Robot implementation on Linux did not consult the current layout when >> mapping from a KeyCode to a hardware code. Internally it retrieved results >> for all the layouts but just picked the first one it saw leading to random >> effects. Though not part of the original bug report, the code also ignored >> the shift level when choosing which result to pick. On a French layout the >> dollar sign is on two keys (AltGr 4 is the second one) and the code could >> choose either one. Same is true for pound. >> >> This PR consults the current layout and only on shift level 0 which is the >> same level used in get_glass_key to figure out which KeyCode to assign when >> generating a KeyEvent. > > Martin Fox has updated the pull request incrementally with one additional > commit since the last revision: > > The Robot code now correctly targets numlock keypad keys and keys that > always appear on group 0. The results returned from `gdk_keymap_get_entries_for_keyval` match the way the keys events are delivered from the OS. The numlock state can affect the `level` and some keys (like ones on the numeric keypad) always appear on `group` 0 even if that's not the current group. When searching through the results we have to use `translate_keyboard_state` to find the correct group and level to match against. Code has been updated along with a few minor fixes. ------------- PR Comment: https://git.openjdk.org/jfx/pull/718#issuecomment-1511890495
