> Note: the Java-side changes in this PR are also in #694 which fixes the same > issue (and more) on Linux. Unfortunately the Linux Robot code is not working > making it difficult to test on that platform (see #718). > > KeyCharacterCombinations allow the specification of accelerators based on > characters whose KeyCodes vary across keyboard layouts. For example, the + > character is on KeyCode.EQUALS on a U.S. English layout, KeyCode.PLUS on a > German layout, and KeyCode.DIGIT1 on a Mac Swiss German layout. > KeyCharacterCombinations finds the correct KeyCode by calling > `Toolkit.getKeyCodeForChar`. > > `getKeyCodeForChar` can only return one KeyCode for a given character so it > can't easily handle characters which appear in more than one location, like + > which is on the main keyboard and the numeric keypad. It's also reliant on > KeyCodes which prevents KeyCharacterCombinations from working on keys with no > codes (e.g. the base character contains a diacritic). It also relies on the > platform to map from a character to a key which is the reverse of how key > mapping normally works making it slow and/or imprecise to implement on Mac > and Linux (Windows is the only platform with a system call to do this). > > This PR introduces a new way for a platform to pass key information to the > Java core. `View.notifyKeyEx` takes an additional platform-specific > `hardwareCode` which identifies the key and is tracked in a private field in > the KeyEvent. This is opt-in; a platform can continue to call the old > `View.notifyKey` method and allow the `hardwareCode` to default to -1. > > On the back-end `KeyCharacterCombination.match` calls the new routine > `Toolkit.getKeyCanGenerateCharacter` which unpacks the KeyEvent information > and sends it on to the Application. This is also opt-in; the default > implementation falls back to the Application's `getKeyCodeForChar` call. > Platforms which call `View.notifyKeyEx` will be handed the `hardwareCode` for > the key in addition to the Java KeyCode. > > The new `View.notifyKeyEx` returns a boolean indicating whether the event was > consumed or not. This plays no role here but will be used later to fix > [JDK-8087863](https://bugs.openjdk.org/browse/JDK-8087863). > > For testing I've included the manual KeyboardTest app that also appears in PR > #425. Tests with keypad combinations should now work. > > Note: this PR only fixes Windows. Fixes for Mac and Linux but can't be > submitted until #425 and #718 are integrated.
Martin Fox has updated the pull request incrementally with one additional commit since the last revision: Rename new routine to canKeyGenerateCharacter, other review cleanup ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1126/files - new: https://git.openjdk.org/jfx/pull/1126/files/a2fd0046..8c3a5c09 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1126&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1126&range=00-01 Stats: 18 lines in 9 files changed: 0 ins; 1 del; 17 mod Patch: https://git.openjdk.org/jfx/pull/1126.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1126/head:pull/1126 PR: https://git.openjdk.org/jfx/pull/1126
