Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8090257

Mac: Inconsistent KeyEvents with alternative keyboard layouts


    • Type: Bug
    • Status: Open
    • Priority: P4
    • Resolution: Unresolved
    • Affects Version/s: 8u40
    • Fix Version/s: tbd
    • Component/s: javafx
    • Labels:
    • Environment:

      Mac OS X 10.10.1

      ❯ java -version
      java version "1.8.0_40-ea"
      Java(TM) SE Runtime Environment (build 1.8.0_40-ea-b19)
      Java HotSpot(TM) 64-Bit Server VM (build 25.40-b23, mixed mode)


      I'm using Mac OS X 10.10.1. I use the Colemak keyboard layout, provided by the operating system. For example, the "e" key in Colemak is the same key as "k" in Qwerty.

      Here is a log of some example problems, taken from the output of the KeyEvent debugging program by Michael Bayne in https://javafx-jira.kenai.com/browse/RT-37399

      ; e
      type=KEY_PRESSED code=K mods=[] char='' ( 0)
      type=KEY_TYPED code=UNDEFINED mods=[] char='e' ( 101)
      type=KEY_RELEASED code=K mods=[] char='' ( 0)

      ; C-e (Control e)
      type=KEY_PRESSED code=CONTROL mods=[ctrl] char='' ( 0)
      type=KEY_PRESSED code=K mods=[ctrl] char='' ( 0)
      type=KEY_TYPED code=UNDEFINED mods=[ctrl] char='' ( 5)
      type=KEY_RELEASED code=K mods=[ctrl] char='' ( 0)
      type=KEY_RELEASED code=CONTROL mods=[] char='' ( 0)
      ; Interpretation: KEY_TYPED char is 5. C-a is 0, C-b is 1, so C-e is 5.

      ; S-e (Shift e)
      type=KEY_PRESSED code=SHIFT mods=[shift] char='' ( 0)
      type=KEY_PRESSED code=K mods=[shift] char='' ( 0)
      type=KEY_TYPED code=UNDEFINED mods=[shift] char='E' ( 69)
      type=KEY_RELEASED code=K mods=[shift] char='' ( 0)
      type=KEY_RELEASED code=SHIFT mods=[] char='' ( 0)
      ; Interpretation: KEY_TYPED char is 69 ('E').

      ; M-e (Meta e in Emacs terminology = Option e on Mac = Alt e)
      type=KEY_PRESSED code=ALT mods=[alt] char='' ( 0)
      type=KEY_PRESSED code=K mods=[alt] char='' ( 0)
      type=KEY_TYPED code=UNDEFINED mods=[alt] char='' ()
      type=KEY_RELEASED code=K mods=[alt] char='' ( 0)
      type=KEY_RELEASED code=ALT mods=[] char='' ( 0)
      ; Interpretation: None that I can see, since KEY_TYPED char is null.

      ; s-e (Super e in Emacs terminology = Command e on Mac)
      type=KEY_PRESSED code=COMMAND mods=[meta] char='' ( 0)
      type=KEY_PRESSED code=K mods=[meta] char='' ( 0)
      type=KEY_TYPED code=UNDEFINED mods=[meta] char='e' ( 101)
      type=KEY_RELEASED code=K mods=[meta] char='' ( 0)
      type=KEY_RELEASED code=COMMAND mods=[] char='' ( 0)
      ; Interpretation: KEY_TYPED char is 101 ('e').

      This behavior seems incorrect to me.

      1. In particular, it seems to me that KEY_PRESSED should reveal the raw (Qwerty) layout key, not the physical key. (Using the physical key would only make sense for Operating System level access; it seems to me that no Mac application would want (or be allowed to) to bypass the OS's choice of keyboard layout.)

      2. In particular, how is one supposed to extract the key code from the Alt e / Option e example above? It looks as though the information you'd need is lost, unless you hack your own Colemak layout, which would not be reasonable IMO.

      I marked this as Priority=Medium ("Problem limited in scope or with a reasonable workaround.") because alternative keyboard layouts are less common. I don't know if there are workarounds yet.




            • Assignee:
              duke J. Duke (Inactive)
            • Votes:
              0 Vote for this issue
              1 Start watching this issue


              • Created: