On Tue, 16 Mar 2021 11:13:39 GMT, Tom Schindl <tschi...@openjdk.org> wrote:
>> On the French keyboard the digits are shifted but I assumed we would still >> want those keys to map to KeyCode.0-9 as they do on Windows. My solution was >> to hard-code those key positions to be digits but this interferes with >> Dvorak layouts. I'm tweaking the implementation to fix this. The new >> approach will be to query both the shifted and unshifted characters on a key >> and favor digits and letters over everything else (and something over >> nothing). >> >> (I've been writing Mac code to enumerate all the OS keyboard layouts and >> generate lists showing which Java key codes will change from the historic >> implementation. It also does some sanity checking.) > > Maybe this is a very dumb idea but why are we not using the char to map back > to the keycode? At least for everything in the ASCII-Range this would be ok > not? We'd only have to check for special keys (like NUM-Keys, F-Keys, ...) > first. So once we checked and the text is of length 1 we could do the mapping > from the char. The Function/arrow/number pad keys are handled using a hard-coded table since they don’t vary based on keyboard layout. Beyond that you’re asking exactly the right question. JavaFX KeyCodes seem to be modeled on similar systems present in Windows and X11. On these platforms the system assigns a key code to each key which remains stable regardless of the modifier state. The system tries to ensure that codes for A-Z and 0-9 are assigned to keys even on keyboards that don’t generate Latin characters. My implementation is conservative in that it’s trying to emulate the behavior of Windows and X11 and associate each key with a stable code including A-Z and 0-9. On the Mac that has no real utility when it comes to accelerator matching, we could use the character information in the event to generate the JavaFX key code and still match user’s expectations. But that would break other JavaFX assumptions, like that the key code is stable. Take the =/+ key on the US keyboard as an example. If Cmd is not held down it will generate = or + depending on the shift state and so vary between KeyCode.EQUALS and KeyCode.PLUS. And key events for non-Latin characters would have an UNDEFINED KeyCode until Cmd was held down and we got a useable ASCII character. I have no idea if these deviations from the original design would be an issue. At this point I’m pretty sure that any problems would lie outside accelerator processing e.g. with the Robot. P.S. What I would not do is what Swing is trying, namely to emulate Windows (stable codes, A-Z present, etc.) using just the NSEvent character information and heuristics. That’s generating all sorts of oddness under the hood. Better to generate UNDEFINED KeyCodes than bad guesses. ------------- PR: https://git.openjdk.java.net/jfx/pull/425
