On Tue, 16 Mar 2021 19:48:56 GMT, Martin Fox <github.com+12087024+belden...@openjdk.org> wrote:
>> 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. I've written a command line utility that runs through all the keyboard layouts available in macOS 11.2.3 and generates a report on how this PR would change the Java key codes for each layout. I used it to spot-check the behavior on various layouts and to flag potential trouble spots (like Lithuanian where digits are typed using a dead key.) I thought it would also be useful for this review. For example, I can now say that with this PR Meta-, (comma) will still be available on all layouts. If the report would be of interest where should I put it? Add it to this PR, attach it to a comment in this thread, put it someplace public and link to it? ------------- PR: https://git.openjdk.java.net/jfx/pull/425
