Problem or Motivation
OpenWork renders the chat transcript (and the composer) inside a fixed reading
width — CHAT_LAYOUT.maxWidth = max-w-[840px] (see packages/ui/src/lib/layout.ts,
applied in ChatDisplay.tsx and ChatInputZone.tsx). There is no way for the
user to change it.
On large / ultrawide desktop displays this leaves most of the window empty, and
for code-heavy conversations (wide diffs, long tool output, tables) the 840px
column forces unnecessary wrapping and horizontal scrolling inside blocks.
Comparable desktop clients all expose this as a preference:
- Claude Desktop — "wider chat" width control,
- ChatGPT desktop — chat width setting,
- Codex / VS Code — editor/content width preferences.
OpenWork's otherwise rich Appearance page (theme, color theme, font, language,
rich tool descriptions, reduce motion) is missing this one common affordance.
Proposed Solution
Add a "Conversation width" segmented control to Settings → Appearance →
Interface, right below the existing "Reduce motion" toggle, with three options:
- Comfortable (default) — the current 840px reading column,
- Wide — 1100px, a roomier column for code-heavy chats,
- Full — no max-width, uses the full available panel width.
Behavior:
- Renderer-only preference persisted in
localStorage, mirroring the existing
ReduceMotionContext pattern (no backend/qwen-code change).
- A
ConversationWidthProvider reflects the choice onto <html> as
data-conversation-width and drives a CSS custom property
--chat-content-max-width (840px / 1100px / none).
- The transcript container and the composer read that variable via an inline
max-width: var(--chat-content-max-width, 840px), so the fallback keeps the
shared web viewer (packages/ui SessionViewer) unchanged at 840px.
Feasibility
Frontend-only. Pure renderer/CSS state — the width is a presentation concern
in apps/electron/src/renderer. No qwen-code backend involvement. Follows the
already-merged reduce-motion preference precedent (#50 / #51).
Acceptance criteria (CDP assertion)
A new e2e/assertions/conversation-width.assert.ts drives the real UI over CDP
and asserts, for each of the three options selected from the Appearance page:
- the segmented control button reports
aria-checked="true",
<html> carries the matching data-conversation-width value,
- the computed CSS custom property
--chat-content-max-width on <html>
equals the expected value (840px / 1100px / none),
- the choice is persisted in
localStorage under craft-conversation-width,
cycling through the options to prove it both applies and reverts.
Problem or Motivation
OpenWork renders the chat transcript (and the composer) inside a fixed reading
width —
CHAT_LAYOUT.maxWidth=max-w-[840px](seepackages/ui/src/lib/layout.ts,applied in
ChatDisplay.tsxandChatInputZone.tsx). There is no way for theuser to change it.
On large / ultrawide desktop displays this leaves most of the window empty, and
for code-heavy conversations (wide diffs, long tool output, tables) the 840px
column forces unnecessary wrapping and horizontal scrolling inside blocks.
Comparable desktop clients all expose this as a preference:
OpenWork's otherwise rich Appearance page (theme, color theme, font, language,
rich tool descriptions, reduce motion) is missing this one common affordance.
Proposed Solution
Add a "Conversation width" segmented control to Settings → Appearance →
Interface, right below the existing "Reduce motion" toggle, with three options:
Behavior:
localStorage, mirroring the existingReduceMotionContextpattern (no backend/qwen-code change).ConversationWidthProviderreflects the choice onto<html>asdata-conversation-widthand drives a CSS custom property--chat-content-max-width(840px/1100px/none).max-width: var(--chat-content-max-width, 840px), so the fallback keeps theshared web viewer (
packages/uiSessionViewer) unchanged at 840px.Feasibility
Frontend-only. Pure renderer/CSS state — the width is a presentation concern
in
apps/electron/src/renderer. No qwen-code backend involvement. Follows thealready-merged reduce-motion preference precedent (#50 / #51).
Acceptance criteria (CDP assertion)
A new
e2e/assertions/conversation-width.assert.tsdrives the real UI over CDPand asserts, for each of the three options selected from the Appearance page:
aria-checked="true",<html>carries the matchingdata-conversation-widthvalue,--chat-content-max-widthon<html>equals the expected value (
840px/1100px/none),localStorageundercraft-conversation-width,cycling through the options to prove it both applies and reverts.