This now-closed gtk3 bug could be related, though it appears it was merged into 3.24 which I am running (3.24.21).
https://gitlab.gnome.org/GNOME/gtk/-/issues/2102 On Tue, Jun 30, 2020 at 8:53 AM David Richmond <[email protected]> wrote: > Yes, you are accurately describing the behavior, and so are the debug > statements: > > Scorearea key press event: keyval 98 (b), string |b|, length 1, state 0, > keycode 11, group 0, is_modifier flag 0 > Keyval 50 gdk name 2 > > dnm_accelerator_name using gtk_accelerator_get label 2 > gdk_keyval_name name 2 > Transformed with mods 0x0 to name 2 > Keyval 50 gdk name 2 > > So whatever is happening is happening before this subroutine. > > On Tue, Jun 30, 2020 at 8:38 AM Richard Shann <[email protected]> > wrote: > >> On Tue, 2020-06-30 at 07:58 -0500, David Richmond wrote: >> > Thanks, Richard, for all your help. It seems the key press is >> > recorded correctly by the gprint() debug. For instance, with b, e, >> > and f: >> > >> > Scorearea key press event: keyval 98 (b), string |b|, length 1, >> > state 0, keycode 11, group 0, is_modifier flag 0 >> >> ok, this is what Denemo receives on my Debian installation, so whatever >> is going on should be fixable, though it is likely to involve some Gtk >> murk - Gtk supplies names for key presses, IIRC, in two ways depending >> on whether they should be translated to the user's language or not. >> >> Let's concentrate on the simplest case - pressing "b" on your keyboard: >> >> To be clear, when you try to set the (unshifted, no caps locked, no >> alt, no ctrl) key "b" as a shortcut you find that Denemo describes it >> as keypress "2"? >> >> As a first step it would be good to uncomment the lines >> >> src/core/kbd-custom.c: 415, 444, 445, 482 >> in the file src/core/kbd-custom.c >> >> these are print statements that will step through the munging, I think, >> and tell us what Gtk is calling the keypress. >> >> Richard >> >> >> >> > Scorearea key press event: keyval 101 (e), string |e|, length 1, >> > state 0, keycode 14, group 0, is_modifier flag 0 >> > Scorearea key press event: keyval 102 (f), string |f|, length 1, >> > state 0, keycode 3, group 0, is_modifier flag 0 >> > >> > Shift + 2 reads as shift + @ (the character above the 2 on my >> > keyboard): >> > >> > Scorearea key press event: keyval 65505 (Shift_L) >> > Scorearea key press event: keyval 64 (at), string |@|, length 1, >> > state 1, keycode 19, group 0, is_modifier flag 0 >> > >> > The 2 key reads correctly as 2: >> > >> > Scorearea key press event: keyval 50 (2), string |2|, length 1, >> > state 0, keycode 19, group 0, is_modifier flag 0 >> > >> > Option + 3 reads as option + £, which I believe is a Mac remapping >> > (as I thought I could fix via the command center): >> > >> > Scorearea key press event: keyval 65513 (Alt_L), string ||, >> > length 0, state 0, keycode 58, group 1, is_modifier flag 1 >> > Scorearea key press event: keyval 163 (sterling), string |£|, >> > length 2, state 8, keycode 20, group 1, is_modifier flag 0 >> > >> > The keycode numbers may be a bit weird, but it seems like you use >> > event->keyval in process_key_event(), so if the print call is >> > printing the same correctly.... >> > >> > I will see if someone has a standard USB keyboard lying around. >> >
