Idea: a global UI scale for the client (zoom the whole interface, not just conversation text)

[DC-507]

Problem

The client has exactly one typography control today: ui-theme.fontSize (10–22 px, default 14). It changes conversation content only. Sidebar labels, the session list, menus, settings surfaces and composer chrome are fixed pixel sizes, and the desktop shell exposes no page zoom:

• the macOS application menu template is fileMenu + editMenu + windowMenu — there is no View/zoom role;
• the shell bundle contains no setZoomLevel / zoomFactor / setVisualZoomLevelLimits;
• Cmd/Ctrl + = / - / 0 are not bound anywhere (no accelerator, no shortcut definition).

So someone who needs a larger UI — 4K/5K display, large viewing distance, or low vision — can enlarge the conversation text but not the interface around it. In the desktop app the usual escape hatch does not apply either: the window loads dsh-app://app with contextIsolation: true, sandbox: true, nodeIntegration: false, so page script cannot reach webFrame.setZoomFactor.

Idea

A first-party UI scale, for example:

• a scale field in ui-theme (or a small ui-scale namespace) with a stepper in Settings → General, and/or
• Cmd/Ctrl + = / - / 0 bound through the existing ctx.shortcuts registry.

Implementing it with webContents.setZoomFactor (or webFrame.setZoomFactor) rather than CSS would rescale viewport units and canvas-backed surfaces for free — exactly where a CSS-based approach is weakest.

What exists as a workaround today

A community plugin does this from the page side: https://github.com/DC-507/dsh-zoom (MIT, zero runtime dependencies, no build step). It applies zoom to document.documentElement, binds the three chords in the window capture phase, and persists the level in localStorage. Verified against 0.2.0-rc.2 on macOS.

Its limitations are themselves an argument for doing it natively:

• CSS zoom does not rescale viewport units, so the few overlay clamps that use 100vh/100dvh need a per-build patch;
• canvas-backed surfaces (terminal, editors, document previews) rasterize at the unzoomed size and look soft;
• the shortcuts do not fire while focus is inside a sidebar browser/preview webview;
• the macOS traffic lights are positioned in window points and do not scale.

None of those apply to webContents.setZoomFactor.

Ask

Is a global UI scale on the roadmap, or would the team consider one? Happy to share the detailed findings (which surfaces scale, which do not, and why) if that helps.

---

中文摘要

目前客户端只有 ui-theme.fontSize 一个排版设置，且只作用于对话正文；侧栏、菜单、设置页都是固定像素，桌面外壳也没有任何页面缩放（菜单里没有 View/缩放角色，包内没有 setZoomLevel/zoomFactor，Cmd+=/-/0 未绑定）。在桌面上 dsh-app://app 页面无法访问 webFrame，浏览器的页面缩放也救不了。建议内置一个 UI scale（ui-theme.scale 或独立的 ui-scale 命名空间 + ctx.shortcuts 绑定），用 webContents.setZoomFactor 实现即可顺带解决视口单位与画布类面板的清晰度问题。上面提到的社区插件可作为现有 workaround 与实测参考。