You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
A terminal tab on the drawer's edge, next to where the terminal opens
#15942
Problem. The terminal toggle is in the top-right titlebar cluster, but the terminal drawer opens at the bottom of the chat column. With the default panel animation (0 ms), the drawer appears instantly at the far side of the window from the click. While it is closed, nothing at the bottom edge shows that a terminal lives there. I kept missing what the click had done. This is my own experience, not a collected report.
Already in place and working: the titlebar toggle with its pressed state, the terminal.toggle shortcut in its tooltip (⌘J), and the toggle spacing fix from #13426 (merged; fixed accepted bug #13419). #12838 deliberately kept the panel-bottom icon. This proposal does not revisit any of that. It is only about the distance between the control and the drawer it opens.
Reproduction on current main (a1d9d72aef). Web client, isolated dev server, headless Chromium 1280×800, dark, Motion at its 0 ms default.
Open a thread in a project with the terminal closed. Nothing at the bottom of the chat column refers to the terminal.
Click the titlebar terminal toggle (at y = 12 px). The drawer appears instantly with its top edge at y = 520 px, 480 px below the control. Sampled heights jump 0 → 280 px with no intermediate frame.
Click again; it disappears instantly.
Before (main), 0 ms:
Before stills
Smallest proposed scope. Add a small tab on the terminal drawer's top edge, at the bottom-right of the chat column. It toggles the terminal and stays visible while the drawer is closed, so it marks where the terminal lives.
The titlebar toggle stays exactly as it is. This adds a control and moves none.
No motion change. The 0 ms default and reduced motion are respected exactly. The tab simply sits on the drawer's top edge. It only travels with the drawer if the user has turned panel animations on.
What I checked on the branch. All in a real web client against an isolated dev server:
At 0 ms the drawer still opens and closes with no intermediate frames. The tab's bottom edge sits on the drawer's top edge with a 0 px gap.
At 200 ms, all 26 animation samples kept a 0 px gap. With reduced motion emulated at 200 ms, opening and closing are instant.
The tab and the titlebar toggle stay in sync (aria-pressed), and both toggle the drawer.
At 1280, 900 and 600 px, hit-testing the tab's centre reaches the tab, and it overlaps no composer button or text field.
With the right panel maximized, the tab is clipped and inert, and never receives focus.
With the compact right-panel sheet open, the sheet covers the tab and the titlebar toggle stays reachable.
Targeted vp lint passes with no new warnings, and the apps/web typecheck passes. No unit test was added: the change is placement only, and the repo discourages static-markup assertions.
Not verified: desktop (Electron) and Safari. Desktop wraps the same web code. Mobile is unaffected; it has its own terminal controls.
Decision needed. Is a small, always-visible tab on the terminal drawer's edge, added alongside the existing titlebar toggle, acceptable? If yes, I'll open the PR from the prepared branch. If you'd prefer it only while the drawer is open, or not at all, I'll follow that.
Prepared with Claude Opus 5.5 in Claude Code (T3 Code); browser evidence captured by GPT-6 Astra in Codex; code reviewed by GPT-6.1 Sol.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Problem. The terminal toggle is in the top-right titlebar cluster, but the terminal drawer opens at the bottom of the chat column. With the default panel animation (0 ms), the drawer appears instantly at the far side of the window from the click. While it is closed, nothing at the bottom edge shows that a terminal lives there. I kept missing what the click had done. This is my own experience, not a collected report.
Already in place and working: the titlebar toggle with its pressed state, the
terminal.toggleshortcut in its tooltip (⌘J), and the toggle spacing fix from #13426 (merged; fixed accepted bug #13419). #12838 deliberately kept thepanel-bottomicon. This proposal does not revisit any of that. It is only about the distance between the control and the drawer it opens.Reproduction on current main (
a1d9d72aef). Web client, isolated dev server, headless Chromium 1280×800, dark, Motion at its 0 ms default.Before (main), 0 ms:
Before stills
Smallest proposed scope. Add a small tab on the terminal drawer's top edge, at the bottom-right of the chat column. It toggles the terminal and stays visible while the drawer is closed, so it marks where the terminal lives.
PanelLayoutControls.tsx,ChatView.tsx). The tab is a plain button styled in its own component, not a newTogglevariant.After (prepared branch, no PR opened), 0 ms: the tab is visible while closed and rides the drawer's top edge when open.
After, with panel animations set to 200 ms in Settings: the tab stays attached as the drawer moves.
After stills (closed, open, 600 px, maximized panel, compact sheet)
Branch: main...saphid:t3code:fix/terminal-drawer-edge-tab
What I checked on the branch. All in a real web client against an isolated dev server:
aria-pressed), and both toggle the drawer.vp lintpasses with no new warnings, and theapps/webtypecheck passes. No unit test was added: the change is placement only, and the repo discourages static-markup assertions.Not verified: desktop (Electron) and Safari. Desktop wraps the same web code. Mobile is unaffected; it has its own terminal controls.
Decision needed. Is a small, always-visible tab on the terminal drawer's edge, added alongside the existing titlebar toggle, acceptable? If yes, I'll open the PR from the prepared branch. If you'd prefer it only while the drawer is open, or not at all, I'll follow that.
Prepared with Claude Opus 5.5 in Claude Code (T3 Code); browser evidence captured by GPT-6 Astra in Codex; code reviewed by GPT-6.1 Sol.
All reactions