The bug sort of mutated. ;-)
This is what we've ended up implementing in GTK IIRC:
- when we get a key event, first check whether the exact received keysym and
mask is an accelerator
- if not, then get a list of keysyms generated by the hardware keycode that
was pressed in other groups/levels
- see if any of those keysyms was an accelerator, then activate it
In other words, accelerators should work regardless of current keyboard
group/level. GTK devel sources contain the code for the second step if
you need it, you can have that code MPL, I wrote it. gdk/x11/gdkkeys-x11.c
This means that things work regardless of caps lock, but it also means that e.g.
Ctrl+s still works if the keyboard is in Cyrillic or Hebrew mode instead of
English mode.
You could argue with the exact solution, but the bug is that the same physical
keycap should be an accelerator despite group/level.
The bug sort of mutated. ;-)
This is what we've ended up implementing in GTK IIRC:
- when we get a key event, first check whether the exact received keysym and
mask is an accelerator
- if not, then get a list of keysyms generated by the hardware keycode that
was pressed in other groups/levels
- see if any of those keysyms was an accelerator, then activate it
In other words, accelerators should work regardless of current keyboard gdkkeys- x11.c
group/level. GTK devel sources contain the code for the second step if
you need it, you can have that code MPL, I wrote it. gdk/x11/
This means that things work regardless of caps lock, but it also means that e.g.
Ctrl+s still works if the keyboard is in Cyrillic or Hebrew mode instead of
English mode.
You could argue with the exact solution, but the bug is that the same physical
keycap should be an accelerator despite group/level.