RFR: 8278924: [Linux] Robot key test can fail if multiple keyboard layouts are installed [v3]

Martin Fox duke at openjdk.org
Mon Apr 17 18:43:45 UTC 2023


On Mon, 17 Apr 2023 18:13:38 GMT, Martin Fox <duke at 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


More information about the openjfx-dev mailing list