8308644: [Linux] Missing mappings for dead keys + Alt Gr#1143
8308644: [Linux] Missing mappings for dead keys + Alt Gr#1143tsayao wants to merge 16 commits intoopenjdk:masterfrom
Conversation
|
👋 Welcome back tsayao! A progress list of the required criteria for merging this PR into |
|
@beldenfox AKA master of keys :) Could you take a look? |
Webrevs
|
| { GDK_KEY_F21, com_sun_glass_events_KeyEvent_VK_F21 }, | ||
| { GDK_KEY_F22, com_sun_glass_events_KeyEvent_VK_F22 }, | ||
| { GDK_KEY_F23, com_sun_glass_events_KeyEvent_VK_F23 }, | ||
| { GDK_KEY_F24, com_sun_glass_events_KeyEvent_VK_F24 }, |
There was a problem hiding this comment.
F13 on up used to be in the mapping tables on both Mac and Windows but were commented out long ago. This happened before everything was migrated to git and there's no bug number or comment in the code that explains why this happened. I would just leave them out.
| { GDK_KEY_braceright, com_sun_glass_events_KeyEvent_VK_BRACERIGHT }, | ||
| { GDK_KEY_exclamdown, com_sun_glass_events_KeyEvent_VK_INV_EXCLAMATION }, | ||
| { GDK_KEY_EuroSign, com_sun_glass_events_KeyEvent_VK_EURO_SIGN }, | ||
| { GDK_KEY_ISO_Level3_Shift, com_sun_glass_events_KeyEvent_VK_ALT_GRAPH }, |
There was a problem hiding this comment.
The old mapping (which you kept) is to map GDK Alt_R to VK_ALT_GRAPH. That seemed to be working fine. Is this a different key? How would I go about generating this keysym?
There was a problem hiding this comment.
It was not working for me, so I did a little search and sometimes it's mapped do ISO_Level3:
xmodmap: up to 4 keys per modifier, (keycodes in parentheses):
shift Shift_L (0x32), Shift_R (0x3e)
lock Caps_Lock (0x42)
control Control_L (0x25), Control_R (0x69)
mod1 Alt_L (0x40), Meta_L (0xcd)
mod2 Num_Lock (0x4d)
mod3
mod4 Super_L (0x85), Super_R (0x86), Super_L (0xce), Hyper_L (0xcf)
mod5 ISO_Level3_Shift (0x5c), Mode_switch (0xcb)
| glass_mask |= (mask & GDK_BUTTON5_MASK) ? com_sun_glass_events_KeyEvent_MODIFIER_BUTTON_FORWARD : 0; | ||
| glass_mask |= (mask & GDK_SUPER_MASK) ? com_sun_glass_events_KeyEvent_MODIFIER_WINDOWS : 0; // XXX: is this OK? | ||
| glass_mask |= (mask & GDK_SUPER_MASK) ? com_sun_glass_events_KeyEvent_MODIFIER_WINDOWS : 0; | ||
| glass_mask |= (mask & GDK_META_MASK) ? com_sun_glass_events_KeyEvent_MODIFIER_WINDOWS : 0; |
There was a problem hiding this comment.
Have you been able to generate the Super and Meta modifiers? Googling around it seems the original keys were on the 1978 Space-cadet keyboard and there seems to be some debate as to how these modifiers should be emulated on a modern keyboard. I wouldn't change this unless a user has entered a bug.
There was a problem hiding this comment.
Yeah, they seem unused. This is mostly used on other events modifiers, like mouse dragging and probably will never touch GDK_META_MASK.
| } | ||
|
|
||
| // do not send undefined keys | ||
| if (glassKey > 0) { |
There was a problem hiding this comment.
I haven't run this code but this looks wrong. There are many keys which don't have key codes including most characters with accents or other diacritic marks (like ñ on a Spanish layout). These have always generated PRESSED and RELEASED events with undefined key codes.
There was a problem hiding this comment.
It was wrong, fixed.
| { GDK_KEY_Delete, com_sun_glass_events_KeyEvent_VK_DELETE } | ||
| }; | ||
|
|
||
| jint gdk_keyval_to_glass(guint keyval) { |
There was a problem hiding this comment.
It's almost always best to leave working code as-is. The Contributing document contains this line:
Note that it is unlikely the project will merge refactors for the sake of refactoring.
I don't find a hard-coded table and custom binary search algorithm to be simpler than a hash map, particularly if contributors are responsible for keeping the table in correct order. In any case the old code was working fine and I would leave it alone.
I'm still glad you did this work, it's good to revisit detail-oriented code like this every now and then looking for things that were overlooked.
There was a problem hiding this comment.
I was not sure about that, It does generate the hash table on the first key press, but performance-wise I don't think there are a significant difference. I like the binary search better, but without further arguments/reasons I think it's hard to convince the reviewer.
There was a problem hiding this comment.
Reverted back to hash table and added the missing dead keys mapping.
| } else { | ||
| return com_sun_glass_events_KeyEvent_KEY_LOCK_OFF; | ||
| } | ||
| return (gdk_keymap_get_num_lock_state(keymap)) |
There was a problem hiding this comment.
Have you tried testing this with a Wayland backend? I was doing some testing and it seemed that unless JavaFX opened a window we didn't connect with the Wayland server so we couldn't get accurate keyboard layout information. It wouldn't surprise me if this also prevented us from getting accurate keyboard state so the manual test for this code (which does not create a window) might fail. Beyond that I agree we should be migrating away from X11 calls if possible.
There was a problem hiding this comment.
I have attached a key_release.c on the JBS bug, it works better on Wayland. On Xorg when you release the CAPS LOCK it will report as still ON until you press another key.
Compile with gcc -o key_release key_release.c pkg-config --cflags --libs gtk+-3.0
There was a problem hiding this comment.
I reverted back for now since the CAPS LOCK key release behaviour was not ok.
|
Changed the scope of the PR to a minimum more "mergeable" approach. |
|
@tsayao This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration! |
|
I'm surprised no customer ever noticed this. On Linux the current JavaFX behavior is that the real AltGr key (the one that appears on European and UK keyboards) is assigned KeyCode.UNDEFINED. On layouts like US English the right Alt key is just an Alt key but we sill assign it KeyCode.ALT_GRAPH. So, yeah, we should be adding ISO_Level3_Shift to the map. The Robot digs through the hash map to do a reverse lookup from KeyCode to keysym. I'll add AltGr to my keyboard test app and sort out how this affects the Robot. I'm not too worried about making matters worse, as it stands the Robot can't send an ALT_GRAPH key event on layouts that actually use AltGr. The dead key additions are harmless and make the system look more professional but those codes only show up on RELEASED KeyEvents so I suspect they will be ignored. Windows doesn't even generate RELEASED events for dead keys. The Mac does but the codes are wrong. But, again, I don't see any downside to adding them. |
|
@tsayao This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration! |
|
It's a simple addition, with no hurries, just commenting to keep it on the list. |
|
@tsayao This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration! |
|
/reviewers 2 |
|
@kevinrushforth |
|
@tsayao This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration! |
|
@tsayao This pull request has been inactive for more than 8 weeks and will now be automatically closed. If you would like to continue working on this pull request in the future, feel free to reopen it! This can be done using the |
|
My apologies, I have been reviewing this but didn't get around to writing up my comments. Currently JavaFX assumes that AltGr will be reported as Alt_R. On ISO keyboards (including U.K. English) AltGr is reported as ISO_Level3_Shift. On these keyboards ISO_Level3_Shift is also the only keyval that works if we want to target AltGr using a Robot. Just adding a second entry to the table isn't sufficient to fix that, currently the Robot will only attempt one code and at the moment it's Alt_R. I'll add AltGr to the KeyboardTest app, make sure ISO_Level3_Shift is in the table, and update the Robot code as part of fixing JDK-8278924. I do want the dead key changes in at some point. There's no reason for us to misidentify keys when the changes are this easy and adding them to the table will enable testing of dead key handling using a Robot. |


This PR adds missing key mappings for dead keys and fixes "Alt Gr" for some systems.
Progress
Issue
Reviewing
Using
gitCheckout this PR locally:
$ git fetch https://git.openjdk.org/jfx.git pull/1143/head:pull/1143$ git checkout pull/1143Update a local copy of the PR:
$ git checkout pull/1143$ git pull https://git.openjdk.org/jfx.git pull/1143/headUsing Skara CLI tools
Checkout this PR locally:
$ git pr checkout 1143View PR using the GUI difftool:
$ git pr show -t 1143Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jfx/pull/1143.diff
Webrev
Link to Webrev Comment