Long answers and compact navigation have different reading needs. Making an entire desktop window larger can help the answer text, but it also enlarges the sidebar, buttons, and other controls.
AIClaw 3.7.30 adds a dedicated Theme settings page with separate choices for color, interface font, and conversation text size. The useful distinction is scope: changing the conversation size updates message text and the composer without applying a global zoom to navigation.
This is included in the published v3.7.30 release, the latest public release at this review. The implementation links below are pinned to that tag.
Keep reading size separate from interface density
The new page offers conversation sizes of 12, 13, 14, 15, 16, 18, 20, 22, and 24 pixels. The default is 14px.
The root component watches the saved appearance settings and sets a CSS custom property, --conversation-font-size. Message containers and the composer textarea consume that property. The settings page's text sample uses it too, so the selected size has a visible preview.
The body retains its 14px base size. This is why a user can choose 18px conversation text while sidebar conversation titles remain 14px. It is a targeted reading control rather than application-wide scaling.
The implementation is in App.vue, ChatView.vue, and ThemeView.vue.
This scope also sets a limit: the control is not a promise to resize every text surface, embedded preview, or operating system dialog. Components with their own typography rules retain those rules.
Choose local font stacks rather than assume a font exists
The interface font selector offers System, PingFang, Microsoft YaHei, Songti, and Monospace options. Each option maps to a predefined CSS font stack.
For example, the Songti stack lists Songti SC, SimSun, Noto Serif CJK SC, and then a generic serif family. The chosen font therefore does not need to be installed for text to remain renderable: the browser can fall back to another available family.
The app does not install those fonts or download a web font for this setting. The typography definitions contain local family names and generic fallbacks.
Selecting an option does not prove that its first named family rendered every glyph. Different operating systems and installed font sets can produce different results. Code also retains its separate monospace stack in the shared stylesheet; the interface font setting is not intended to erase that distinction.
Make the color choice explicit
The page includes six color choices: White, Green, Blue, Sand, Violet, and Dark. Preview tiles show a surface, sidebar, and accent, and the selected option is marked with aria-pressed and a visible check.
The root's data-theme attribute selects the corresponding CSS variables for surfaces, text, borders, and interaction colors. Color definitions and normalization live in themes.ts; the actual palette rules are in styles.css.
White remains the default, including when the operating system prefers dark mode. Dark is an explicit choice here; this release does not add an automatic follow-system mode.
Apply the saved choice, and retain the previous one on failure
Changing an appearance control sends a configuration patch through the existing desktop bridge. The renderer replaces its configuration state only after the write resolves successfully. The root watcher then applies the new appearance without requiring an application restart.
While a save is in progress, the page disables its appearance controls. If the write rejects, it reports the failure and keeps the previous saved configuration rather than committing a new application theme in renderer state.
The host normalizes missing or unsupported values to White, System font, and 14px. That gives older configurations predictable defaults. Font sizes use an allowlist, rather than accepting any number within a range: an unsupported value such as 14.5, or a string such as "18", normalizes to 14.
See configuration defaults and the renderer save action.
What was verified
For this article, I reran the two focused theme/typography tests in test-config.ts. Both passed, with zero failures or skips. They cover legacy and invalid values, supported color and font IDs, and the allowed numeric sizes.
I also rebuilt the desktop app and reran the controlled work-interface smoke suite with an isolated temporary user-data location. It passed 294/294 checks. That is the entire suite's total, not 294 checks dedicated to appearance.
Its appearance checks exercised the real Vue/preload interface with controlled host responses: color changes, selected options, renderer reload, font-stack assignment, the 18px preview and composer, unchanged sidebar title size, injected save failures, and restoring the original settings. A separate temporary configuration-store fixture verified persistence across store instances.
The relevant theme, typography, settings-view, defaults, and test files matched the public v3.7.30 source byte for byte. The suite did not use paid models or the user's real application data.
These checks verify state, CSS, and fixture persistence. They do not establish identical font rendering across platforms, certify accessibility or contrast compliance, or prove that a named font is installed on another machine.
The result is a small but practical separation: users can change how they read and write a long conversation while keeping navigation compact, and their selected appearance survives the next launch through the normal saved configuration.
Top comments (0)