On Tue, 20 Feb 2024 18:07:43 GMT, Martin Fox <m...@openjdk.org> wrote:
> On Linux getKeyCodeForChar does not consult the current keyboard layout. For > example, it assumes the “+” character is on KeyCode.PLUS even on layouts > which don’t generate KeyCode.PLUS. The result is that most > KeyCharacterCombinations don’t work. > > This PR fixes this using the same approach that Mac glass uses. When the user > types a key we lookup all the characters that key might generate and put them > in a map. getKeyCodeForChar then consults the map to find the Java key code. > This ensures that we only pay attention to keys that are on the user’s > physical keyboard. > > (Some Linux layout maps are expansive and include entries for keys that may > be on the user’s keyboard but probably aren’t, like “(“ and “)” on the > numeric keypad. If we simply ask for all entries that generate a given > character we can get multiple hits with no good way to determine which ones > are physically present.) > > This PR also contains fixes to the Robot to enable testing. When Glass > consults the GdkKeymap to determine which keys might generate a keyval GDK > returns a list covering every installed layout and shift level. The old Glass > code simply picked the first entry in the list. This PR iterates through the > list looking for one that works for the current layout and correct shift > level. Comment added to keep the bots at bay. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1373#issuecomment-2048610696
