denemo-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Running Denemo on macOS Catalina


From: David Richmond
Subject: Re: Running Denemo on macOS Catalina
Date: Tue, 30 Jun 2020 08:53:24 -0500

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 <richard@rshann.plus.com> 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]