Put the menus in the system bar on macOS - #3
Merged
Merged
Conversation
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>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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:
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.