> The algorithm in `KeyCharacterCombination.match` relies on the call > `Toolkit.getKeyCodeForChar` which is difficult to implement correctly. It > defies the way most keyboard API’s work and no platform has got it right yet. > In particular the Mac and Linux implementations have to resort to a > brute-force approach which monitors keystrokes to learn the relationship > between keys and characters. > > This PR introduces an alternative mechanism which directly asks the platform > whether a given key can generate a specific character. It also allows the > platform to attach identifying key information to each KeyEvent to make it > easier to answer the question (much, much easier). > > This is mostly dumb plumbing. On the front-end there’s a new call > `View.notifyKeyEx` that takes an additional platform-specific `hardwareCode` > parameter. It also returns a boolean indicating whether the event was > consumed or not so I can fix JDK-8087863. If you want to follow the path > visit the files in this order: > > View.java > GlassViewEventHandler.java > TKSceneListener.java > Scene.java > > The `KeyEvent` class has been expanded with an additional `hardwareCode` > member that can only be accessed internally. See KeyEvent.java and > KeyEventHelper.java. > > On the back-end `KeyCharacterCombination.match` calls a new routine > `Toolkit.getKeyCanGenerateCharacter` which unpacks the `KeyEvent` information > and sends it on to the Application. The default implementation falls back to > the old `getKeyCodeForChar` call but platform specific Applications can send > it on to the native glass code. > > KeyCharacterCombination.java > Toolkit.java > QuantumToolkit.java > Application.java > GtkApplication.java > > The glass code can use the `hardwareCode` to answer the question directly. It > also has enough information to fall back on the old `getKeyCodeForChar` logic > while also enabling the keypad (a common complaint is that Ctrl+’+’ only > works on the main keyboard and not the keypad, see JDK-8090275). > > This PR improves the situation for key events generated by keystrokes. > Manually constructed key events won’t work any better or worse than they > already do. Based on the bug database I don't think this is an issue.
Martin Fox has updated the pull request incrementally with one additional commit since the last revision: Added manual test for KeyCharacterCombination matching ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/694/files - new: https://git.openjdk.java.net/jfx/pull/694/files/9c5dcbcb..7cb6c5bc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=694&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=694&range=00-01 Stats: 160 lines in 1 file changed: 160 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/694.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/694/head:pull/694 PR: https://git.openjdk.java.net/jfx/pull/694
