On Tue, 21 Feb 2023 17:09:32 GMT, Martin Fox <d...@openjdk.org> wrote:
>> 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 with a new target base due to a merge > or a rebase. The pull request now contains three commits: > > - Merge remote-tracking branch 'upstream/master' into scancode > - Added manual test for KeyCharacterCombination matching > - New KeyCharacterCombination implementation The ticket is a bit unclear when it talks about "US Layout" and Ctrl-+. For example, on a Mac with an attached USB 101(?) key IBM keyboard, one can find two + keys. One +/=, and one on the key pad (the latter generates "Ignored: keypad code" - is this expected?) On Mac, Ctrl-_/- generates "Ignored: control key" - is this expected? ------------- PR Comment: https://git.openjdk.org/jfx/pull/694#issuecomment-1518232573 PR Comment: https://git.openjdk.org/jfx/pull/694#issuecomment-1518233206
