Fl_Sys_Menu_Bar shortcut bug on MacOS

[rs]

Hi All,

I think I've discovered a bug in Fl_Sys_Menu_Bar for MacOS.

Basically if I assign a menu item a shortcut FL_ALT+'u', the use of that shortcut appears to "block" other shortcuts in the menu bar.

I proved minimal working code demonstrating the bug below. In this case command+f or command+g work as expected until I use the shortcut alt+u after which the previous two commands stop working.

This, however *doesn't* affect an identically defined shortcut FL_COMMAND+'i' so it appears to be contingent on the precise shortcut.

If I then navigate to the menu bar with the mouse the shortcuts "reactivate" and respond  normally again.

Other key points:

1. If I replace alt+'u' with alt+'t' this bug doesn't manifest

2. This only happens with Fl_Sys_Menu_Bar on Mac. Using Fl_Menu_Bar on mac does not exhibit this bug.

This has been tested on MacOS 11.6 using both FLTK 1.3.7 and 1.4.x

Code:

#include <FL/Fl.H>
#include <FL/Fl_Double_Window.H>
#include <FL/Fl_Sys_Menu_Bar.H>
#include <stdio.h>
#include <iostream>

void ctrlf(Fl_Widget *, void *) {
  std::cout<<"in cmd f"<<std::endl;
}

void ctrlg(Fl_Widget *, void *) {
  std::cout<<"in cmd g"<<std::endl;
}

void ctrli(Fl_Widget *, void *) {
  std::cout<<"in cmd i"<<std::endl;
}

void altu(Fl_Widget *, void *) {
  std::cout<<"in alt u"<<std::endl;
}

int main() {

  Fl_Double_Window *win = new Fl_Double_Window(Fl::w() / 2 - 200, Fl::h() / 2 - 200, 400, 400, "Main Win");

  Fl_Menu_Item items[] = {
      {"Menu1", 0, 0, 0, FL_SUBMENU, 0, 0, FL_NORMAL_SIZE, FL_BLACK}, // 0
      {"cmd f", FL_COMMAND + 'f', ctrlf, NULL, 0, 0, 0, FL_NORMAL_SIZE, FL_BLACK},
      {"cmd g", FL_COMMAND + 'g', ctrlg, NULL, 0, 0, 0, FL_NORMAL_SIZE, FL_BLACK},
      {"cmd i", FL_COMMAND + 'i', ctrli, NULL, 0, 0, 0, FL_NORMAL_SIZE, FL_BLACK},
      {"alt u", FL_ALT + 'u', altu, NULL, 0, 0, 0, FL_NORMAL_SIZE, FL_BLACK},
      {0, 0, 0, 0, 0, 0, 0, 0, 0},
      {0, 0, 0, 0, 0, 0, 0, 0, 0}};

  Fl_Sys_Menu_Bar *menu = new Fl_Sys_Menu_Bar(0, 0, win->w(), 25);
  menu->menu(items);
  win->end();
  win->show();
  return Fl::run();
}

Thanks,

R.

[Manolo]

In the US keyboard layout, but not with all layouts, alt-U is a dead key that is to be used before entering another key, e. g. a or e or u,

to obtain ä, ë or ü. That's why it blocks the recognition of the following keystroke as a menu shortcut.

More generally, it's unwise to use alt-key shortcuts under macOS because many such keystrokes are used to enter

printable characters that can't be entered with a simple keystroke. alt-o is an example for ø. macOS prefers

cmd-key or cmd-alt-key for shortcuts.

[Manolo]

I've looked more into details at this issue.

The FLTK code calls cocoa when processing key events so that the system menu bar

get highlighted when a system menu item shortcut is typed, as expected in macOS.

The statement in question is this:

        [[NSApp mainMenu] performKeyEquivalent:[NSApp currentEvent]];

It would be possible to handle system menus completely inside FLTK code, and that would

be equivalent to what happens when using Fl_Menu_Bar rather than Fl_Sys_Menu_Bar.

With that, a shortcut that is also a dead key would not block recognition of the next keystroke.

But, the system menu bar would not be highlighted each time a system menu shortcut is typed.

I believe the current situation is preferable.

Opinions?

[Mo_Al_]

I would also prefer the current behavior.

[Ian MacArthur]

On Monday, 11 October 2021 at 21:32:05 UTC+1 Mo wrote:

I would also prefer the current behavior.

Yes, me too - I think that having the "system behaviour" is probably least surprising to other macOS users.

Making fully cross-platform code is often tricky, as you need to somehow select a set of behaviours that seem familiar to users on all the platforms, which often means that (as in this case) the choice of modifier key combinations can be restricted...

[rs]

Ok, thanks for this, I understand.

I think you are right, on balance, you want the highlighting behaviour that exists currently.

I appreciate that this is well outside of the scope for FLTK, so it can just be ignored, but it *might* be helpful to point that out in the Fl_Sys_Menu_Bar docs that some shortcuts are "unwise", simply because if anyone is like me, they are using FLTK to get multi-platform support, without detailed knowledge of some of the "other" platforms...