Fl_Sys_Menu_Bar shortcut bug on MacOS

31 views
Skip to first unread message

rs

unread,
Oct 9, 2021, 3:28:52 AM10/9/21
to fltk.general

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

unread,
Oct 10, 2021, 9:12:44 AM10/10/21
to fltk.general
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

unread,
Oct 11, 2021, 4:48:48 AM10/11/21
to fltk.general
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_

unread,
Oct 11, 2021, 4:32:05 PM10/11/21
to fltk.general
I would also prefer the current behavior.

Ian MacArthur

unread,
Oct 12, 2021, 3:36:25 AM10/12/21
to fltk.general
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

unread,
Oct 12, 2021, 12:38:37 PM10/12/21
to fltk.general
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...
Reply all
Reply to author
Forward
0 new messages