Zoom the app with ⌘+ / ⌘− / ⌘0

[tosinamuda]

Compose had no way to make the text bigger. For a writing app whose audience is not technical, that is an accessibility gap.

One property scales everything

The app was already well-placed for this: 926 rem declarations against 317 px, and the px ones are overwhelmingly hairlines (48), radii (90) and shadows (22). The editor package sizes its content in rem/em too. So one root font size scales chrome and document together:

--ui-zoom: 1;
font-size: calc(100% * var(--ui-zoom));

100% rather than a fixed base, so this multiplies whatever text size the user's system already asks for instead of replacing it. Borders stay px deliberately — a 1px rule is 1px at any zoom.

Six stray px font sizes became rem, along with the fixed-height boxes around them that would have clipped the larger text.

The window chrome deliberately does not scale

macOS draws the traffic lights at a position fixed when the window is created, and Tauri 2.11 exposes traffic_light_position only as a builder option — there is no runtime setter (the runtime trait has one; it is not public). A title bar that grew with zoom slid out from under lights that stayed put:

at 150% the lights sit high in the row while the tabs centre below them

So the strip is pinned in px, matching --traffic-lights-inset, which was already fixed for exactly this reason. OS chrome doesn't scale, content does — the rule browsers apply to their own toolbars.

Details worth knowing

• Discrete stops (0.8 … 2.0) compared with an epsilon. A stored 1.25 returns from JSON as 1.2500000000000002, and a naive step > current skips 1.25 and jumps to 1.5. Covered by a test.
• A persisted scale is untrusted and clamped. Everything is sized off the root, so a bad value is not a cosmetic bug — it is an app nobody can read.
• Applied before first paint in main.tsx, not from a mount effect, so launches don't render at 100% and jump. The hook sits at the app root rather than in MainApp, because the person most likely to need bigger text is the one who cannot read the setup screen.
• Settings → General gets a labelled control with the current percentage. The View menu carries the shortcuts, but someone who needs larger text is the least likely to go hunting through a menu bar.

The accelerator trap

muda — the parser Tauri hands these strings to — has no bare Plus, only NumpadPlus. So CmdOrCtrl+Plus parses as nothing and the item ships with no shortcut: no build error, no runtime error, just a key that does nothing. Zoom In uses =, and ⌘⇧= is caught in the web view where the shifted character is what actually arrives.

A test parses every accelerator against muda, and a second asserts the Plus spelling still fails, so the workaround can be deleted if that ever changes.

To make that testable the menu moved out of a closure in lib.rs into menu.rs — lib.rs drops 451 → 363 lines, back under budget. Event routing now reads the same id list the menu is built from, so an item cannot ship with nothing listening; two tests hold both directions.

Verified

576 front-end tests, 260 Rust tests. Live on a bundled build: the View menu shows ⌘=, ⌘− and ⌘0; both the menu item and the keys step; --ui-zoom moves 1 → 1.1 → 1.25 → 1.5 and the whole interface scales with it.

Dark mode is the next piece — the token layer it needs is already in place, since the app and the editor package both read the same --cds-* custom properties.