On Mon, 13 Dec 2021 19:46:27 GMT, Martin Fox <d...@openjdk.java.net> 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. I see from your comment in PR #635 that you propose to withdraw that PR in favor of this one. Given that, why don't you change that one to "Draft" and we'll focus on this one. As a first pass, it does seem a reasonable approach. I do have a few high level questions: 1. What are the drawbacks of this approach? 2. I see that the new mechanism has a Linux implementation. Do you plan to propose this for the other platforms (particularly macOS)? It seems like you would need to in order to solve [JDK-8090275](https://bugs.openjdk.java.net/browse/JDK-8090275) 3. Would this PR help address any of the other in-flight PRs? (e.g., PR #672) presuming we eventually do this on all platforms)? 4. Can you add the manual test from PR #635 ? ------------- PR: https://git.openjdk.java.net/jfx/pull/694
