Skip to content

Put the menus in the system bar on macOS - #3

Merged
IAmJSD merged 1 commit into
mainfrom
macos-menu-bar
Aug 21, 2026
Merged

Put the menus in the system bar on macOS#3
IAmJSD merged 1 commit into
mainfrom
macos-menu-bar

Conversation

@IAmJSD

@IAmJSD IAmJSD commented Aug 21, 2026

Copy link
Copy Markdown
Member

macOS expects an application's menus at the top of the screen, not inside its windows, so Schist's own bar looked out of place there and left the system bar holding nothing but the app's name.

Both bars are now built from the same panels::menus description. GPUI's menus can only carry actions, so AppItem moves into actions.rs behind a new RunAppItem, filters get an OpenFilter action, and the items that already have a keybinding name the action that binding names -- which is how ⌘N, ⌘T and ⌘0 come to show beside them, GPUI reading each key equivalent out of the keymap.

Three things follow from what GPUI's menu API can express:

  • It has no check marks, so View's toggles say what the click will do ("Hide Rulers"), as Finder does. The in-window bar keeps its ticks.
  • Screen Mode's only binding is a bare "f", and a key equivalent without modifiers is swallowed before the letter can reach a tool that is taking typing -- so that item dispatches an unbound action instead.
  • Quit, Preferences and Check for Updates move to the application menu and are dropped from File and View, rather than appearing twice.

AddAdjustment knew five adjustment ids and warned about the rest, which was invisible while only the keymap built one; the macOS Adjust menu builds sixteen. It now round-trips through adjustment_id.

Cannot be run here: this box has no macOS. The Linux bar is unchanged, ⌘L and ⌘Q were re-tested, and none of the new code is cfg-gated.

macOS expects an application's menus at the top of the screen, not inside
its windows, so Schist's own bar looked out of place there and left the
system bar holding nothing but the app's name.

Both bars are now built from the same panels::menus description. GPUI's
menus can only carry actions, so AppItem moves into actions.rs behind a
new RunAppItem, filters get an OpenFilter action, and the items that
already have a keybinding name the action that binding names -- which is
how ⌘N, ⌘T and ⌘0 come to show beside them, GPUI reading each key
equivalent out of the keymap.

Three things follow from what GPUI's menu API can express:

- It has no check marks, so View's toggles say what the click will do
  ("Hide Rulers"), as Finder does. The in-window bar keeps its ticks.
- Screen Mode's only binding is a bare "f", and a key equivalent without
  modifiers is swallowed before the letter can reach a tool that is
  taking typing -- so that item dispatches an unbound action instead.
- Quit, Preferences and Check for Updates move to the application menu
  and are dropped from File and View, rather than appearing twice.

AddAdjustment knew five adjustment ids and warned about the rest, which
was invisible while only the keymap built one; the macOS Adjust menu
builds sixteen. It now round-trips through adjustment_id.

Cannot be run here: this box has no macOS. The Linux bar is unchanged,
⌘L and ⌘Q were re-tested, and none of the new code is cfg-gated.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@IAmJSD
IAmJSD merged commit 6a39fb2 into main Aug 21, 2026
3 checks passed
@IAmJSD
IAmJSD deleted the macos-menu-bar branch August 21, 2026 23:33
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.

1 participant