[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-openjfx-dev
Subject:    Re: RFR: 8273743: KeyCharacterCombination for "+" does not work on US QWERTY keyboard layout [v5]
From:       Martin Fox <duke () openjdk ! org>
Date:       2023-04-27 18:07:53
Message-ID: hQxaXr7HAn--nyUFbfLy7CFvK73oxxQ-o-Ugmr6MWGE=.b3a0d8db-933f-4806-82a3-d0ce03c4785a () github ! com
[Download RAW message or body]

> 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:

  Updating classpath for Eclipse users

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/694/files
  - new: https://git.openjdk.org/jfx/pull/694/files/5cd7e9a2..ddaf808c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=694&range=04
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=694&range=03-04

  Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jfx/pull/694.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/694/head:pull/694

PR: https://git.openjdk.org/jfx/pull/694


[prev in list] [next in list] [prev in thread] [next in thread]