ReviewOS

also looking at this

craft-native/craft

feat(cli): --app-name, so an app can be itself without packaging

#55
Merged glennmichael123 wants to merge feat/app-name-flag into main
7 files +199 -2
11 days ago

Closes #50.

The App menu title and the About/Hide/Quit items are built from -[NSProcessInfo processName], which for a bare binary is the executable's name. Every app launched through the shared craft binary therefore called itself craft in the menu bar, and the only fix was to package a .app so CFBundleName answered instead.

--app-name <NAME> sets it directly. Also available as appName in craft.json and as appName on AppConfig.

Verified against a real menu bar

Not just "the flag is parsed" — I built the default bar both ways and read the titles back out of AppKit:

default (no --app-name):
  menu[0] = tmp_menu_probe  [About tmp_menu_probe; Hide tmp_menu_probe; Hide Others; Show All; Quit tmp_menu_probe]
after --app-name Harness:
  menu[0] = Harness         [About Harness; Hide Harness; Hide Others; Show All; Quit Harness]

setProcessName: is set before initPlatform(), because createApplicationMenu reads the name once and both the windowed and the tray startup paths reach it.

Two things worth flagging

It does not touch --title. The window's title and the app's name are different strings, and conflating them is exactly why --title could not already do this — a note-taking app is "Notes" in the menu bar whatever the open document has put in the title bar. There's a test pinning that they stay independent.

It is the name AppKit shows, not the kernel's. The issue mentions Activity Monitor; that one I can't deliver. ps and Activity Monitor read the process name from the executable, and nothing running inside the process can change it — renaming there still needs a real bundle or an exec under a different name (which is what the namedAs() symlink downstream was doing). The flag's own doc comment and the AppConfig JSDoc both say so rather than leaving it to be discovered.

Tests

test/cli_test.zig gets its first tests that drive parseArgs rather than constructing a WindowOptions by hand. That distinction matters here: a flag declared in the struct but never wired into the argument loop passes every existing test in that file and does nothing at all on the command line. Control-checked — deleting the parse branch fails 4 of the 5 new tests, and deleting the args.push fails 4 of the 5 new TS ones.

zig build test clean, bun test 473 pass, tsc --noEmit clean, pickier clean.

7 changed files on the files tab, with 0 review threads.

Sign in to comment on this pull request.