Re: Running Denemo on macOS Catalina

[Richard Shann]

On Tue, 2020-06-30 at 08:53 -0500, David Richmond 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.

ah, yes, right, it is the dnm_clean_event() which is doing it.
If you change the line src/core/kbd-custom.c:152 from
 
#ifdef G_OS_WIN32

to

#ifndef G_OS_WIN32

so that the code for Windows is used then I think the problem may go
away.

That will then raise the question of what the hell is going on with
some keyboards/OSs...

Richard

(I think _MACH_O_ may be the right flag to use for Mac builds, but we
can sort that out later)







> 
> On Tue, Jun 30, 2020 at 8:38 AM Richard Shann <richard@rshann.plus.co
> m> 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.
> >