The multi-line composer (⌘↩ from the chat view) had three pieces of chrome around one text area: a field label, a description block explaining the Return / ⌘↩ split, and an instructional placeholder sentence. The action bar already renders "Send ⌘↩" next to the button, so the description was restating what the UI already showed.
It is now a single bare Form.TextArea — no label, no description, a one-line placeholder.
Why it can't be a true full-width text area
I checked the Vicinae source rather than guessing. A Form.TextArea is always rendered inside FormField:
FormField.qml lays out as a RowLayout of three columns with Layout.preferredWidth2 / 5 / 2 and fillWidth: true on all three
So the proportions resolve to a label gutter (2/9), the editor (5/9), and an empty right spacer (2/9) — and the right spacer stays even when no label is set. There is no prop to opt out. None of this is reachable from the extension API, so the only lever available is removing clutter, not reclaiming width.
If you want true full-width, that needs an upstream change (a label-less or full-width field variant). Happy to file it.
Verification
tsc --noEmit clean
eslint . clean
96 tests passing (unchanged — this is a presentational change, and the composer has no test coverage because it is pure JSX)
vici build succeeds
Not verified
The rendered result. I could not drive the launcher UI to look at it — osascript on this machine lacks Accessibility permission (not allowed to send keystrokes), so I could not press ⌘↩ to open the composer. The reasoning above is from the Vicinae QML source, not from seeing the new layout.
## What changed
The multi-line composer (`⌘↩` from the chat view) had three pieces of chrome around one text area: a field label, a description block explaining the Return / ⌘↩ split, and an instructional placeholder sentence. The action bar already renders **"Send ⌘↩"** next to the button, so the description was restating what the UI already showed.
It is now a single bare `Form.TextArea` — no label, no description, a one-line placeholder.
## Why it can't be a true full-width text area
I checked the Vicinae source rather than guessing. A `Form.TextArea` is **always** rendered inside `FormField`:
- `ExtensionFormView.qml` → `textareaFieldComp` → `FormField { ... }`, unconditionally
- `FormField.qml` lays out as a `RowLayout` of three columns with `Layout.preferredWidth` `2 / 5 / 2` and `fillWidth: true` on all three
So the proportions resolve to a **label gutter (2/9), the editor (5/9), and an empty right spacer (2/9)** — and the right spacer stays even when no label is set. There is no prop to opt out. None of this is reachable from the extension API, so the only lever available is removing clutter, not reclaiming width.
If you want true full-width, that needs an upstream change (a label-less or full-width field variant). Happy to file it.
## Verification
- `tsc --noEmit` clean
- `eslint .` clean
- **96 tests passing** (unchanged — this is a presentational change, and the composer has no test coverage because it is pure JSX)
- `vici build` succeeds
## Not verified
**The rendered result.** I could not drive the launcher UI to look at it — `osascript` on this machine lacks Accessibility permission (`not allowed to send keystrokes`), so I could not press ⌘↩ to open the composer. The reasoning above is from the Vicinae QML source, not from seeing the new layout.
The multi-line composer had a field label, a description block explaining
the Return / cmd-return split, and an instructional placeholder. That is
three competing pieces of chrome wrapped around one text area, and the
action bar already renders "Send cmd-return" next to the button, so the
description was restating what the UI shows.
Now it is a single bare Form.TextArea: no label, no description, a
one-line placeholder.
Also documents why it cannot go further. Vicinae always renders a
Form.TextArea inside FormField (ExtensionFormView.qml -> textareaFieldComp)
and FormField.qml lays out as 2/5/2 proportional columns: a label gutter,
the editor, and an empty right spacer. The editor therefore gets roughly
five ninths of the width, and the right spacer stays even with no label.
None of it is reachable from the extension API, so the only lever
available is removing clutter, not reclaiming width.
Verified: typecheck, eslint, 96 tests, vici build all pass.
Not verified: the rendered result. osascript on this machine has no
Accessibility permission, so the launcher UI could not be driven.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
What changed
The multi-line composer (
⌘↩from the chat view) had three pieces of chrome around one text area: a field label, a description block explaining the Return / ⌘↩ split, and an instructional placeholder sentence. The action bar already renders "Send ⌘↩" next to the button, so the description was restating what the UI already showed.It is now a single bare
Form.TextArea— no label, no description, a one-line placeholder.Why it can't be a true full-width text area
I checked the Vicinae source rather than guessing. A
Form.TextAreais always rendered insideFormField:ExtensionFormView.qml→textareaFieldComp→FormField { ... }, unconditionallyFormField.qmllays out as aRowLayoutof three columns withLayout.preferredWidth2 / 5 / 2andfillWidth: trueon all threeSo the proportions resolve to a label gutter (2/9), the editor (5/9), and an empty right spacer (2/9) — and the right spacer stays even when no label is set. There is no prop to opt out. None of this is reachable from the extension API, so the only lever available is removing clutter, not reclaiming width.
If you want true full-width, that needs an upstream change (a label-less or full-width field variant). Happy to file it.
Verification
tsc --noEmitcleaneslint .cleanvici buildsucceedsNot verified
The rendered result. I could not drive the launcher UI to look at it —
osascripton this machine lacks Accessibility permission (not allowed to send keystrokes), so I could not press ⌘↩ to open the composer. The reasoning above is from the Vicinae QML source, not from seeing the new layout.