[Top][All Lists]

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

Re: Running Denemo on macOS Catalina

From: Richard Shann
Subject: Re: Running Denemo on macOS Catalina
Date: Tue, 30 Jun 2020 13:13:24 +0100

On Mon, 2020-06-29 at 18:05 -0500, David Richmond wrote:
> Well, "2" on the MacBook Pro keyboard registers as 0, and 5 registers
> as 5. Unfortunately, 0 also registers as 0. But Shift+2 registers as
> Shift+0, while Shift+0 registers as Shift+parenright, which is why I
> thought at first I could get away with remapping.
> With control and alt, b and e still register as 2 and 5 (e.g. ctl+2).
> With shift, they register as a multiple keypress shortcut, written as
> B,s and E,E. The other pitch letters also appear to register as
> multiple keypresses with shift (e.g. C,C).
> It would be very helpful to debug the actual keycodes, thank you. Can
> you point me to a configuration setting to change at runtime or
> compile-time, or send through a patch or a git branch?

Well, quickest will be to delete the "//" at the start of
scorearea_keypress_event() in src/command/keyresponses.c which will
uncomment the line that prints out what key press event is being passed
to Denemo from the Gtk library call:

scorearea_keypress_event (GtkWidget * widget, GdkEventKey * event)
  //g_print ("Scorearea key press event: keyval %d (%s), string |%s|,
length %d, state %x, keycode %d, group %d, is_modifier flag %d\n",
event->keyval, gdk_keyval_name(event->keyval), event->string, event-
>length, event->state, event->hardware_keycode, event->group, event-

I strongly suspect that what is arriving at this point is garbled, so
that fixing it inside the Denemo code may not be possible...
> You also mentioned on the earlier thread that the keycodes are being
> "munged." If it's not too much trouble to point me to the place in
> the codebase where that happens,

it's in the following few lines, I'll be able to look at fixing it if
what is arriving in Denemo is fixable - the output of that debug print
statement for various keypresses will tell us that. (The point being
that the keypresses are intercepted by the system before they read Gtk,
let alone Denemo, so if it maps, e.g. Enter to Return then there is no
way to make Denemo respond differently to the two distinct physical
keys, the one on the main keyboard the other on the keypad).

>  I could also then take a look and try to see if it needs to be
> changed for the Mac.....or at least my Mac. I don't have a lot of
> experience with C/C++, but I am very game to try. I also know
> MacPorts has a robust infrastructure for adding patches to upstream
> source at distribution time, so that is where anything that varies
> across Mac OS versions or hardware probably belongs.
If you can lay your hands on an external USB keyboard that might be
illuminating... Eddy? Gabirel?


> David
> On Mon, Jun 29, 2020 at 4:40 AM Richard Shann <
> m> wrote:
> > On Sun, 2020-06-28 at 23:22 -0500, David Richmond wrote:
> > > The sudo make install target does work and appropriately puts the
> > > executable in /usr/local/bin where it can be run as "denemo" from
> > the
> > > command line.
> > 
> > I've updated the website with this
> > 
> > > 
> > > Second, the bad news. While the keybindings for shift or alt +
> > the
> > > number keys can be fixed relatively easily from the Command
> > Center
> > > (and then with a mapping file), I am seeing the "b" and "e" keys
> > on
> > > my MacBook Pro keyboard registering as number 2 and 5,
> > respectively,
> > > with obviously annoying results for usage
> > 
> > Very strange - what do the "2" and "5" keys result in? And what
> > happens
> > with shift, control, alt ...
> > 
> > I can easily make Denemo emit the exact keycodes etc that it is
> > receiving from the environment when a key is pressed (onto the
> > console)
> > if that will help.
> > 
> > Richard
> > 

reply via email to

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