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
Copy file name to clipboardExpand all lines: .github/skills/sessions/SKILL.md
+1Lines changed: 1 addition & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -238,6 +238,7 @@ You **must** run these checks before declaring work complete:
238
238
239
239
- **Single-pane created-session default is Editor-only (Changes editor, detail closed) — the detail is not force-opened by editor activation**: a Changes/file editor becoming active must NOT auto-reveal the docked detail (aux bar). `SinglePaneDetailPanelStrategy._syncForcedDetailTarget` reveals a hidden detail ONLY when it was temporarily hidden by a full-width editor (`_hiddenByFullWidthEditor`), never when it is hidden by the per-session default or an explicit user hide; when the detail is visible it still switches the container (Changes/Files) to match the active editor. **Exception — opening the empty Files placeholder (`EmptyFileEditorInput`) reveals the Files detail** (its content, the Files tree, lives in the aux bar). This is a dedicated `onDidActiveEditorChange` listener in the strategy that reveals the aux bar when the placeholder *becomes the active editor* — NOT reactive logic inside the detail autorun (which re-reads `auxBarVisibleObs`, so it would re-reveal the instant the user hides the detail — bug: "can't hide the details view in the empty file editor at all"). Keying on **active editor** (not `onWillOpenEditor`) is deliberate: the managed auto-ensured Files tab is opened **inactive** as a background tab (`fileTabOptions`), so it never becomes active and never reveals — preserving the Editor-only default — while the `+` Files action and selecting the Files tab both make it active and reveal. Do NOT reveal from the `NewFileTabAction` instead: that misses tab-selection and other activation paths (tried and rejected — "does not work"). The listener is guarded by `isVisible(EDITOR_PART)` (don't reveal the detail alone while the whole side pane is closed, e.g. Scenario C reload) and `!ctx.isRestoringSessionLayout` (a restore-driven activation must not reveal). Because hiding the aux bar fires `onDidChangePartVisibility`, not `onDidActiveEditorChange`, the user's hide sticks while the placeholder stays active. Do NOT reintroduce a `DetailPanelTarget.FilesReveal` in the autorun or an `isEditorPartAutoVisibilitySuppressed()` layout-service API — the active-editor listener needs neither. The reopen default is workbench-layout policy via `_defaultSidePaneState` (`SinglePaneWorkbench` = editor-only); the controller only filters it against available content. When changing this, update the `[single-pane] reveals the Files detail when the empty Files placeholder becomes active` and `[Scenario C]` tests together.
240
240
-**Header overflow belongs before trailing layout controls, not promoted into the inline action strip**: keep secondary menu items in the toolbar's `secondary` group so they remain under `...`. Render trailing layout actions from a separate header menu after that toolbar, with a separator between the two action hosts; do not make secondary actions primary just to change the overflow button's position.
241
+
-**A toolbar-host separator must follow rendered actions, not menu presence**: a configured layout menu can have zero visible items after context-key evaluation. Enable the secondary toolbar's trailing separator from the layout toolbar's actual item count and rebuild it when that menu changes, or the header can retain an orphan separator.
241
242
-**Hide Editor and Toggle Details share visibility, but not enablement**: when an editor supports docked details, keep both actions visible so the trailing layout group stays stable. Gate Hide Editor with `AuxiliaryBarVisibleContext` as a `precondition`, so hiding details disables the action instead of removing it.
242
243
-**Code Review switches between right-inline and first-overflow placement**: while `MainEditorAreaVisibleContext` is true, contribute **Run Code Review** to the right header menu in the first primary group (`0_codeReview`). While false, contribute it to `secondary/1_codeReview`, so it is first in `...` with a separator after it; keep both placements mutually exclusive and retain identical applicability gates.
243
244
-**Bridge extension editor-title actions into the right header with standard semantics**: `EditorTitleMenuBridgeContribution` mirrors extension-owned `MenuId.EditorTitle` commands and submenus into `Menus.SessionsEditorHeaderSecondary`. Map `navigation` to an inline extension group and every other group to `secondary/extension/<original-group>` so non-navigation actions stay in overflow; forward the active editor's original URI as the menu argument.
Copy file name to clipboardExpand all lines: src/vs/sessions/LAYOUT.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -278,7 +278,7 @@ The entire third-pane redesign is gated behind the experimental setting `session
278
278
279
279
- The auxiliary bar is removed from the workbench grid and **docked inside the editor part** (absolutely positioned on the right, below the editor tab strip); the grid's top-right row becomes `Sessions | Editor`, and the editor part spans the editor + detail-panel width.
280
280
- The editor group's **tab strip and header-hosted breadcrumbs span the full width**, while the editor content is inset on the right by the detail-panel width via the concrete `EditorPart.setContentRightInset(px)` method (`EditorPart`/`EditorGroupView`; not on the `IEditorPart` interface; `0` = no-op for all other layouts). The detail panel is always docked on the right, so no left margin is needed.
281
-
- A **full-width header** sits below the tab bar, spanning the editor content and docked detail panel. `SinglePaneMainEditorPart.getGroupViewOptions()` enables it with `showHeader` and supplies `Menus.SessionsEditorHeaderPrimary`, `Menus.SessionsEditorHeaderSecondary`, and `Menus.SessionsEditorHeaderLayout`. `EditorHeaderControl` owns the header DOM, evaluates those menus, renders their toolbars, and exposes its fixed visible height to `EditorTitleControl`; the title control includes that height in its layout. The header directly contains breadcrumbs followed by one actions container. That actions container owns the primary and secondary action hosts, followed by a separator and the layout-action host for **Toggle Details** and **Hide Editor**. Menu items own their active-editor `when` clauses. `SessionChangesEditor.scopedInstantiationService` only supplies its editor-scoped context for evaluating those clauses; its presence does not control whether the header is created.
281
+
- A **full-width header** sits below the tab bar, spanning the editor content and docked detail panel. `SinglePaneMainEditorPart.getGroupViewOptions()` enables it with `showHeader` and supplies `Menus.SessionsEditorHeaderPrimary`, `Menus.SessionsEditorHeaderSecondary`, and `Menus.SessionsEditorHeaderLayout`. `EditorHeaderControl` owns the header DOM, evaluates those menus, renders their toolbars, and exposes its fixed visible height to `EditorTitleControl`; the title control includes that height in its layout. The header directly contains breadcrumbs followed by one actions container. That actions container owns the primary and secondary action hosts, followed by the layout-action host for **Toggle Details** and **Hide Editor**. When the layout toolbar has visible items, the secondary toolbar uses the standard trailing-separator action to divide its actions (including `...`) from those layout actions; layout menu changes rebuild the paired toolbars so an empty layout toolbar never leaves an orphan separator. The layout host supplies the same far-side action gap that an internal separator receives from a single toolbar. The header must not create or style a separate separator element. Menu items own their active-editor `when` clauses. `SessionChangesEditor.scopedInstantiationService` only supplies its editor-scoped context for evaluating those clauses; its presence does not control whether the header is created.
282
282
- Text-file breadcrumbs reuse that **same fixed-height header row**. When `IEditorGroupViewOptions.showHeader` is enabled, `EditorTitleControl` creates `BreadcrumbsControl` directly in the header; otherwise it keeps the standard below-tabs placement in the title container. Header padding defines the shared left anchor for breadcrumbs and primary actions, so either starts at the same inset when the other is absent. Header-hosted breadcrumbs lay out at their actual flexed width, accounting for the header padding and sibling actions instead of using the full editor-group width. While the editor area is visible, the empty Files placeholder exposes the active session's first mounted working directory as its resource, so the row shows that Files view root; the breadcrumb model retains an exact workspace-root resource even when ordinary single-root file breadcrumbs omit that root. Detail-only layouts keep the breadcrumb hidden. This is a single-root fallback: multi-root sessions should eventually show a workspace-level breadcrumb that identifies the workspace and exposes all roots instead of presenting the first folder as the whole workspace. Editors without breadcrumbs or applicable menu actions hide the row and report zero header height.
283
283
- A vertical **sash** on the left edge of the docked panel resizes it (`DockedAuxiliaryBarController` in `browser/dockedAuxiliaryBarController.ts` owns `layout()` / `_ensureSash()`, created/driven by `SinglePaneMainEditorPart`). The preferred first-open width is 300px; explicit user resizes persist via the part-sizes snapshot. While the panel is visible it clamps to `[220px, editorWidth - 300px]`; dragging the raw sash width down to ~0 hides the docked detail panel, leaving the editor content visible. Temporary width growth from collapsing the sessions list is restored before persistence and must not become the user's detail width.
284
284
- Collapsing the sessions list transfers the freed sidebar width to the editor grid node when the editor content is **visible**, and to the **detail panel** (`_dockedAuxiliaryBarWidth`, with the editor node kept equal to it) when the editor content is **hidden** (detail-only). Reopening the sessions list restores the pre-collapse editor-node width / detail width. Keeping the hidden-editor node equal to the detail width ensures the width-based reveal-sync never mistakes a wide detail-only node for a revealed editor.
0 commit comments