mirror of
https://github.com/block/buzz.git
synced 2026-08-18 06:50:31 +02:00
## Summary - ship **Buzz Term** end to end: the terminal engine/runtime, mounted desktop substrate, and user-visible naming - add Quinn's tape-deck-inspired banner: a beveled chassis filled by the `buzz term` wordmark, surrounded by a complete-hex field - derive the wordmark's three-stop sweep from each theme's terminal palette so primary, secondary, and accent roles remain visibly distinct across all 62 shipped themes, including light themes - paint the banner once on its own pointer-transparent canvas; PTY rendering beneath it remains unchanged ## Banner behavior - uses the renderer's shared `8.4 × 17` cell metrics and production aspect ratio `2.0238` - regenerates only for viewport/theme changes; palette switches repaint correctly while the banner is visible - dismisses on non-empty output from the active terminal session; empty output and inactive sessions do not dismiss it - fails closed below **70 columns** rather than squeezing or clipping the wordmark - adds **8 lines** to `terminalRenderer.ts` for shared cell metrics and **zero lines inside `paint()`** ## Screenshots | Buzz (light) | Buzz Dark | |---|---| |  |  | | Kanagawa Lotus (light) | Red | |---|---| |  |  | Additional production-aspect finals: [Vesper](https://buzz.block.builderlab.xyz/media/9ca6514b63f8cfb2107a85ca46f16a940c0883848e6fbc718e411af94aa13100.png), [Min Dark](https://buzz.block.builderlab.xyz/media/f67bd2970e5d64ffb07b1ae78ab58c847e6ebc23e7e7a48e067eb024dba64ec8.png), and [Dark Plus](https://buzz.block.builderlab.xyz/media/290fee08924f37d064abc687ecf3e9526ab05b87e8e56d610f23048949793dbe.png). The screenshot harness was checked against the shipped painter at this exact head: all **2,541 draw calls** matched on color, glyph, x, and y; four deliberate divergence controls fired. ## Verification at `98ebc8f9048bd5f0ceb7e843b67874d642f0b7fd` - desktop tests: **3,946 / 3,946** - TypeScript: clean - checks: pass (two pre-existing informational `useTemplate` notices only) - integration/e2e: PASS (independent exact-SHA lane; artifacts recorded in the originating Buzz thread) - artifact/dead-path sweep: clean - redteam G1–G7: PASS - all six named banner emitter-deletion mutants die - independent handwritten five-row full-wordmark fixture kills Quinn's seven-mutant battery, including a one-pixel glyph change - real `112 × 46` canvas-rect dismissal tests separately cover active non-empty, active empty, and inactive non-empty output - layer-drop and zero-draw painter mutants die; z-order and pointer-events verified - CI's `tsc && vite build` includes all three banner modules - performance at DPR 2 (worst-case measured envelope): - one-time content paint: **~0.7–0.8 ms**, paid only when the banner is built or its palette changes - busy compositor, CSS `1277 × 697`, backing `2554 × 1394`: **470–497 µs/frame** for the full banner (**2.82–2.98%** of a 60 Hz frame) - busy compositor, CSS `1920 × 1080`, backing `3840 × 2160`: **1,139–1,212 µs/frame** (**6.83–7.27%**) - empty, one-glyph, and full-banner controls converge: compositor cost follows backing-layer area and DPR rather than painted-cell count - in the actual idle welcome state, cost is below both vsync-clamped rigs' resolution; it is not claimed as zero - **Pane cross-rig spread: resolved at matched loop rate.** Two independent rigs initially differed 2.3× (58–68 vs 136 µs/Mpx of backing store; pane, CSS 1277×697 / backing 2554×1394, DPR 2). The cause of *that* spread is rAF loop rate: the higher figure came from a free-running loop at ~1600fps. Throttled to ~200–236fps, both rigs read 58–68 µs/Mpx (1.25–1.44% of a 60Hz frame). The busy-composite figures quoted above remain the **unthrottled worst case** and are conservative by ~2.3× at the pane. Not established: the mechanism and sign of free-running distortion (one rig under-charges ~15%, the other over-charges 2.3×), and the 1080p figure has not been re-measured throttled. - the layer paints only on generation/theme/resize and dismisses on first non-empty active-session output, so the measurable busy cost is a short-lived worst case rather than a persistent PTY paint-path tax ## Follow-ups in this PR These are intentionally subsequent commits after the certified static-banner head, not claims about `98ebc8f90`: 1. close the compositor metrology: remeasure the 1080p point throttled and characterize the opposite-sign free-running rAF distortion, with each measurement regime stated 2. add Tyler's animated honeycomb color waves, gated by `prefers-reduced-motion`, a full 62-theme phase-sweep contrast check, and DPR-2 per-tick performance certification 3. land the already-proven mounted theme-switch regression probe from `RESEARCH/BUZZ_TERM_G3A_PROBE/` 4. bound the slow/hang-shaped G1-c mutant `waitFor` 5. optionally trim the generator to its ink bounding box, reducing the minimum viewport from 70 to 62 columns --------- Signed-off-by: tlongwell-block <109685178+tlongwell-block@users.noreply.github.com> Signed-off-by: npub1mprnacetjua2xx3p5eddmhxyk6wv929ymm5py8kd2xfxurxahspqqlgyta <d8473ee32b973aa31a21a65adddcc4b69cc2a8a4dee8121ecd51926e0cddbc02@buzz.block.builderlab.xyz> Signed-off-by: npub1jh9wn95s0472h86ahapupaf7m6kx4v9sx2n0atj2hltcfer8k06s5n3pyf <95cae996907d7cab9f5dbf43c0f53edeac6ab0b032a6feae4abfd784e467b3f5@buzz.block.builderlab.xyz> Signed-off-by: npub17jjz49l9jjmhhk7cac63j8yt9z555n9cw8vk7v5jz4vzw4ppld5qgj57cc <f4a42a97e594b77bdbd8ee35191c8b28a94a4cb871d96f32921558275421fb68@buzz.block.builderlab.xyz> Signed-off-by: npub1qyvc0c5kl4gqv2fd97fsk46tu378sqgy35vc83rvgfwne90sel7s0ed67d <011987e296fd5006292d2f930b574be47c7801048d1983c46c425d3c95f0cffd@buzz.block.builderlab.xyz> Co-authored-by: Dawn (sprout agent) <c6237ef84fa537c78dcee78efd2d4e59f728859c7f194da42ac51ededfa0be05@sprout-oss.stage.blox.sqprod.co> Co-authored-by: npub1t2tgm7d8f995uqvmnm8h88sg3wnpp9a5xysjf6dg3tjmgt3ltulqdp8ehr <5a968df9a7494b4e019b9ecf739e088ba61097b4312124e9a88ae5b42e3f5f3e@buzz.block.builderlab.xyz> Co-authored-by: npub1cc3ha7z055mu0rwwu7806t2wt8mj3pvu0uv5mfp2c50dahaqhczshdalg6 <c6237ef84fa537c78dcee78efd2d4e59f728859c7f194da42ac51ededfa0be05@buzz.block.builderlab.xyz> Co-authored-by: npub17jjz49l9jjmhhk7cac63j8yt9z555n9cw8vk7v5jz4vzw4ppld5qgj57cc <f4a42a97e594b77bdbd8ee35191c8b28a94a4cb871d96f32921558275421fb68@buzz.block.builderlab.xyz> Co-authored-by: npub1jh9wn95s0472h86ahapupaf7m6kx4v9sx2n0atj2hltcfer8k06s5n3pyf <95cae996907d7cab9f5dbf43c0f53edeac6ab0b032a6feae4abfd784e467b3f5@buzz.block.builderlab.xyz> Co-authored-by: npub1mprnacetjua2xx3p5eddmhxyk6wv929ymm5py8kd2xfxurxahspqqlgyta <d8473ee32b973aa31a21a65adddcc4b69cc2a8a4dee8121ecd51926e0cddbc02@buzz.block.builderlab.xyz> Co-authored-by: npub1qyvc0c5kl4gqv2fd97fsk46tu378sqgy35vc83rvgfwne90sel7s0ed67d <011987e296fd5006292d2f930b574be47c7801048d1983c46c425d3c95f0cffd@buzz.block.builderlab.xyz>
116 lines
4.7 KiB
Rust
116 lines
4.7 KiB
Rust
//! The macOS application menu.
|
|
//!
|
|
//! Buzz never called `Builder::menu()`, so Tauri installed `Menu::default()`
|
|
//! for us (`tauri::app::Builder::build`, macOS arm). That default puts a
|
|
//! `close_window` item in both the File and Window submenus, and muda gives
|
|
//! that item a Cmd+W key equivalent bound to `performClose:`.
|
|
//!
|
|
//! Two consequences, both wrong for Buzz:
|
|
//!
|
|
//! 1. `CloseRequested` on the main window is intercepted in `lib.rs` and turned
|
|
//! into hide-to-tray, so Cmd+W never closed a window -- it hid the whole
|
|
//! app. That is already redundant with Cmd+H (Hide), which stays.
|
|
//! 2. macOS resolves a menu key equivalent before the webview receives any key
|
|
//! event, so Buzz Term could never bind Cmd+W to "close this terminal tab"
|
|
//! while the accelerator was claimed here.
|
|
//!
|
|
//! So this module builds the standard menu minus both `close_window` items.
|
|
//! Everything else matches `Menu::default()` deliberately: the goal is to drop
|
|
//! one item, not to design a menu.
|
|
//!
|
|
//! If hide-on-Cmd+W is ever wanted back in Buzz mode, the revisit path is to
|
|
//! restore the item and disable it while the terminal owns input (a disabled
|
|
//! item does not consume its key equivalent) -- at the cost of an owner->Rust
|
|
//! IPC hop this approach does not need.
|
|
|
|
#[cfg(target_os = "macos")]
|
|
use tauri::menu::{
|
|
AboutMetadata, Menu, PredefinedMenuItem, Submenu, HELP_SUBMENU_ID, WINDOW_SUBMENU_ID,
|
|
};
|
|
#[cfg(target_os = "macos")]
|
|
use tauri::AppHandle;
|
|
use tauri::{Builder, Runtime};
|
|
|
|
/// Installs Buzz's menu, replacing the `Menu::default()` Tauri would otherwise
|
|
/// auto-install. A no-op off macOS, where that default is never created and
|
|
/// the Cmd+W accelerator does not exist.
|
|
pub fn install<R: Runtime>(builder: Builder<R>) -> Builder<R> {
|
|
#[cfg(target_os = "macos")]
|
|
let builder = builder.menu(build);
|
|
builder
|
|
}
|
|
|
|
/// Mirrors `Menu::default()` with every `close_window` item omitted.
|
|
///
|
|
/// The Window and Help submenus keep Tauri's well-known ids: `init_app_menu`
|
|
/// looks them up by id to call `set_as_windows_menu_for_nsapp` and
|
|
/// `set_as_help_menu_for_nsapp`, and a plain `with_items` submenu would skip
|
|
/// both silently -- no error, just a Window menu AppKit no longer manages.
|
|
#[cfg(target_os = "macos")]
|
|
pub fn build<R: Runtime>(app: &AppHandle<R>) -> tauri::Result<Menu<R>> {
|
|
let pkg_info = app.package_info();
|
|
let config = app.config();
|
|
let about_metadata = AboutMetadata {
|
|
name: Some(pkg_info.name.clone()),
|
|
version: Some(pkg_info.version.to_string()),
|
|
copyright: config.bundle.copyright.clone(),
|
|
authors: config.bundle.publisher.clone().map(|p| vec![p]),
|
|
..Default::default()
|
|
};
|
|
|
|
Menu::with_items(
|
|
app,
|
|
&[
|
|
&Submenu::with_items(
|
|
app,
|
|
pkg_info.name.clone(),
|
|
true,
|
|
&[
|
|
&PredefinedMenuItem::about(app, None, Some(about_metadata))?,
|
|
&PredefinedMenuItem::separator(app)?,
|
|
&PredefinedMenuItem::services(app, None)?,
|
|
&PredefinedMenuItem::separator(app)?,
|
|
&PredefinedMenuItem::hide(app, None)?,
|
|
&PredefinedMenuItem::hide_others(app, None)?,
|
|
&PredefinedMenuItem::separator(app)?,
|
|
&PredefinedMenuItem::quit(app, None)?,
|
|
],
|
|
)?,
|
|
// `Menu::default()`'s File submenu holds exactly one item on macOS
|
|
// -- close_window -- so dropping that item drops the submenu too.
|
|
&Submenu::with_items(
|
|
app,
|
|
"Edit",
|
|
true,
|
|
&[
|
|
&PredefinedMenuItem::undo(app, None)?,
|
|
&PredefinedMenuItem::redo(app, None)?,
|
|
&PredefinedMenuItem::separator(app)?,
|
|
&PredefinedMenuItem::cut(app, None)?,
|
|
&PredefinedMenuItem::copy(app, None)?,
|
|
&PredefinedMenuItem::paste(app, None)?,
|
|
&PredefinedMenuItem::select_all(app, None)?,
|
|
],
|
|
)?,
|
|
&Submenu::with_items(
|
|
app,
|
|
"View",
|
|
true,
|
|
&[&PredefinedMenuItem::fullscreen(app, None)?],
|
|
)?,
|
|
&Submenu::with_id_and_items(
|
|
app,
|
|
WINDOW_SUBMENU_ID,
|
|
"Window",
|
|
true,
|
|
&[
|
|
&PredefinedMenuItem::minimize(app, None)?,
|
|
&PredefinedMenuItem::maximize(app, None)?,
|
|
],
|
|
)?,
|
|
// Empty upstream too on macOS: About lives in the app submenu.
|
|
&Submenu::with_id_and_items(app, HELP_SUBMENU_ID, "Help", true, &[])?,
|
|
],
|
|
)
|
|
}
|