yunxiyang/dsh-wide-conversation

Give the DSH web client a conversation column that uses the width it has.

The built-in layout sizes the transcript from --dsh-chat-content-width: clamp(680px, 64% of the column, 920px): on a wide window a long conversation still reads in a narrow strip with large empty margins. This plugin pins that axis to a configurable percentage of the conversation column — 100% means the transcript spans the whole column — and exposes the percentage as a collapsible Wide Conversation card on the plugin's own page under Settings > Plugins.

简介 / 快速上手(中文)

这个插件让 DSH 桌面/网页客户端的对话列按可用宽度铺开。

• 内置布局把正文宽度锁在 clamp(680px, 列的 64%, 920px) —— 宽窗口下长对话仍挤在一条窄栏里,两侧留大片空白。本插件把这条宽度轴改成对话列宽度的百分比,100 即铺满整列。
• 百分比可以在 设置 > 插件 里调整:已安装 分组里打开 dsh-wide-conversation,在 wide-conversation 这一行点配置,就会出现 Wide Conversation 卡片。卡片默认收起,点标题行展开后可在 40–100 之间调整,点保存生效;收起时标题行右侧直接显示当前百分比。
• 切换宽度即时生效,不需要重启应用;但安装/卸载插件后需要重启该 profile。
• 安装:dsh plugin --profile <name> add dsh-wide-conversation。
• 插件只影响客户端布局,不碰模型、网络或会话日志,也不写入任何自定义会话事件。

Install

Install into a profile with the dsh CLI. Its plugin subcommand forwards to pnpm inside the profile directory, so add/remove behave as usual:

dsh plugin --profile <name> add dsh-wide-conversation

Then restart the profile (desktop: Settings → Desktop settings → Restart, or quit and reopen). The profile's package.json gains the dependency and the dsh.profile.bundles entry, and the bundled cordis.patch.yml inserts the plugin into the layer stack — no manual patch editing is required. The insert declares the row id the browser half claims:

- insert:
    - id: wide-conversation
      name: 'dsh-wide-conversation'

To remove it:

dsh plugin --profile <name> remove dsh-wide-conversation

Working from a local checkout instead? Point the profile at the directory:

dsh plugin --profile <name> add link:/path/to/dsh-wide-conversation

Before importing a plugin, DSH compares every @deepseek-ai/dsh* range in its peerDependencies against the running runtime version, so an install into a newer harness fails at the version check rather than at startup. This package declares both lines it supports (^0.1.1-rc.2 || ^0.2.0-rc.1) and CI checks the declaration against them.

Config

Settings > Plugins → the installed dsh-wide-conversation bundle → the wide-conversation row → Configure opens the Wide Conversation card. Collapsed by default, opened by clicking its header, which also shows the current percentage while collapsed.

field	default	range	meaning
widthPercent	100	40–100	Width of the conversation content as a percentage of the conversation column. 100 spans the whole column.

The card stages its edits and writes only on Save; the save is fenced by the revision the draft started from, so a change made elsewhere in the meantime is refused and the draft kept for correction rather than overwritten. The value lives on the plugin's loader entry in the profile's cordis.patch.yml — the profile is the authority a 0.2 harness validates against. On a 0.1.x harness the same field is registered as the wide-conversation settings namespace and stored in the Host settings document instead; the card is the same disclosure. Values outside the range are rejected by both the card and the schema, so a hand-edited document cannot drive the column outside it.

How it works

The conversation skeleton resolves its entire horizontal axis from --dsh-chat-content-width, declared on its own root and overridden by a dragged --dsh-chat-user-width. Both land as inline styles on the skeleton root, so an ordinary stylesheet rule loses to the style attribute — the override carries !important.

1. lib/client.js injects one stylesheet that pins both custom properties to calc(var(--dsh-wide-percent, 100) * 1%), reclaims the clearance the read column reserved for the old centred 920px measure, and hides the drag handles the percentage now supersedes.
2. The live percentage is published once onto document.documentElement as --dsh-wide-percent, so a change repaints on the next style recalculation instead of re-creating the stylesheet or re-rendering React.
3. The preference is read from whichever settings surface the host provides, and the card is registered on the seat that surface dispatches by:
   • 0.2.x — the entry's form through the configForms service, addressed by the Loader entry id the bundle patch declares (wide-conversation), and the card into plugins.row.config under <package name>#<row id> (dsh-wide-conversation#wide-conversation), which is what gives the row its Configure control.
   • 0.1.x — the wide-conversation namespace through settingsScope, and the card into settings.plugin.item under that namespace key. Neither service is named in the module-level inject, so a host that provides only one of the two loses the card rather than the width axis.
4. The card itself is a disclosure, matching the built-in plugin cards: a collapsed row using their tokens and radii, opening to the single width field — plus Save/Discard on the 0.2 row page, which owns its draft. A contributed card inherits no styling from the settings section, so it restates what they use.

The composer card is derived as content + 32px, so it follows the axis automatically.

No build step

The browser half is a hand-written window.__ModuleLoader__.load closure factory — the only shape the client module system accepts — so the package ships no bundler, no build script, and no client dependencies of its own. react arrives through the injected require table.

The Node half imports @deepseek-ai/schemastery for the Config schema a 0.2 harness reads its form from, marked volatile with extra('volatile', true) — the marker volatileForm() requires, set through extra() rather than the later .volatile() builder so a profile whose schemastery predates that builder still gets a form. That one import is declared twice on purpose, because the two install shapes resolve it differently:

• as a peer dependency, which is what the harness's profile resolution reads. A plugin installed with link: lives outside the profiles tree, so it is a "linked root": its bare imports are routed by the names in its own peerDependencies, and the harness hands it the schemastery the harness itself uses. Leave the peer out and the import falls back to native resolution from the checkout, finds no node_modules above it, and the Host half fails to import — taking the whole plugin down with it;
• as a dependency, which is what pnpm installs for a package installed from the registry. A plugin installed that way is not offered installation-scope resolution and resolves its own copy instead.

DSH's admission check only evaluates @deepseek-ai/dsh and @deepseek-ai/dsh* peers, so the schemastery peer neither widens nor narrows what DSH will load.

Compatibility

• Client platform: web (dsh.client.platform, i.e. the desktop and browser GUI). There is no terminal-face behavior.
• Host lines: 0.1.x (settings.register + settingsScope) and 0.2.x (exported volatile Config + configForms). The declared DSH peer range covers both; tests/compatibility.test.mjs proves the admission check accepts each.
• Writes no session events, so it cannot affect session-log loading.
• The stylesheet rescapes nothing outside the conversation area, but it does target the skeleton by attribute ([data-phase] + [data-conversation-scroll]) rather than by hashed CSS-module class name, so it keeps working when class names change. If a future build renames those attributes, the plugin degrades to a no-op rather than breaking the layout.

License

MIT