Skip to content

feat(macos): give NegPy a menu bar, with Window and Help - #891

Merged
marcinz606 merged 1 commit into
marcinz606:mainfrom
seanharding:feat/macos-window-menu
Aug 18, 2026
Merged

feat(macos): give NegPy a menu bar, with Window and Help#891
marcinz606 merged 1 commit into
marcinz606:mainfrom
seanharding:feat/macos-window-menu

Conversation

@seanharding

Copy link
Copy Markdown
Contributor

AppKit takes Cmd+M and Cmd+W from the standard menu bar, so in an app that builds none they do nothing: NegPy could not be minimized or closed by keyboard, and Zoom was unreachable altogether. This is the smallest bar that fixes that, plus Help.

Window carries Minimize, Zoom, Close, Bring All to Front and the list of open windows — the main window plus any live view or calibration window — with a tick against the front one. Every command acts on the front window, whichever that is, not on the main window. Help gathers what was already scattered: the tour, the shortcut overlay and its editor, the Analysis guide and the update check, plus Report an Issue, which opens the tracker. That last one gets no shortcut registry entry: a binding would advertise it in the shortcut editor and the ? overlay on Windows and Linux, where nothing can run it.

There is no View menu and no Enter Full Screen item. AppKit adds one of its own to any menu titled View, so ours only ever appeared beneath it as a duplicate. Full screen stays the platform's: the green button, and the item macOS puts in the View menu NegPy will have later.

The bar has no parent, which is what makes it application-wide. A bar owned by the main window is only shown while that window is in front, so the menus blinked out whenever the live view or a floating panel took focus.

Items dispatch through ShortcutManager.action_for, so a menu item and its shortcut can never run different code, and a rebind reaches the menu. Only Cmd combinations become key equivalents: AppKit fires those before Qt's shortcut machinery sees the event, so a bare "?" for Keyboard Shortcuts would fire while the user types into the film-strip search box. The window keys stay out of the shortcut registry — they are platform commands, and a native key equivalent silently outranks a QShortcut, so a rebindable copy could only disagree with the menu. A test proves no registry default collides with one.

macOS only. install_mac_menus returns None elsewhere, so Windows and Linux keep their menu-bar-free layout with nothing visibly changed.

Fixes #890

AppKit takes Cmd+M and Cmd+W from the standard menu bar, so in an app that
builds none they do nothing: NegPy could not be minimized or closed by keyboard,
and Zoom was unreachable altogether. This is the smallest bar that fixes that,
plus Help.

Window carries Minimize, Zoom, Close, Bring All to Front and the list of open
windows — the main window plus any live view or calibration window — with a tick
against the front one. Every command acts on the front window, whichever that
is, not on the main window. Help gathers what was already scattered: the tour,
the shortcut overlay and its editor, the Analysis guide and the update check,
plus Report an Issue, which opens the tracker. That last one gets no shortcut
registry entry: a binding would advertise it in the shortcut editor and the ?
overlay on Windows and Linux, where nothing can run it.

There is no View menu and no Enter Full Screen item. AppKit adds one of its own
to any menu titled View, so ours only ever appeared beneath it as a duplicate.
Full screen stays the platform's: the green button, and the item macOS puts in
the View menu NegPy will have later.

The bar has no parent, which is what makes it application-wide. A bar owned by
the main window is only shown while that window is in front, so the menus
blinked out whenever the live view or a floating panel took focus.

Items dispatch through ShortcutManager.action_for, so a menu item and its
shortcut can never run different code, and a rebind reaches the menu. Only Cmd
combinations become key equivalents: AppKit fires those before Qt's shortcut
machinery sees the event, so a bare "?" for Keyboard Shortcuts would fire while
the user types into the film-strip search box. The window keys stay out of the
shortcut registry — they are platform commands, and a native key equivalent
silently outranks a QShortcut, so a rebindable copy could only disagree with the
menu. A test proves no registry default collides with one.

macOS only. install_mac_menus returns None elsewhere, so Windows and Linux keep
their menu-bar-free layout with nothing visibly changed.

The File and View menus follow separately.
@seanharding

Copy link
Copy Markdown
Contributor Author

The menus, for reference (and for people who don't have macOS, so can't view them). The "Send python3 feedback" item is there because I'm running on a beta OS. It won't appear on production macOS builds.

Screenshot 2026-08-18 at 13 50 39 Screenshot 2026-08-18 at 13 52 47

@marcinz606
marcinz606 merged commit 542b843 into marcinz606:main Aug 18, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

macOS: add a menu bar

2 participants