Feature: vertical split of edge groups (multiple edge groups per side, stacked with sash)

[AsafMah]

Feature request

Allow multiple edge groups per side, stacked along the orthogonal axis with their own resizable sash — i.e. let the left edge be split into "top half" and "bottom half" edge groups, each with its own vertical tab strip.

What works today

api.addEdgeGroup(position, options) accepts position: 'left' | 'right' | 'top' | 'bottom'. The shell stores one group per position (not a list):

// node_modules/dockview-core/dist/esm/dockview/dockviewShell.js (v6.4.0)
// fromJSON returns a record with at most one entry per side
const edgeGroups = {};
if (left)   { edgeGroups.left   = { ... }; }
if (right)  { edgeGroups.right  = { ... }; }
if (top)    { edgeGroups.top    = { ... }; }
if (bottom) { edgeGroups.bottom = { ... }; }
return edgeGroups;

A second addEdgeGroup('left', ...) call replaces the existing one rather than adding alongside it.

Why this is awkward

VS Code, Rider, IntelliJ, etc. all support stacked sidebar groups on the same side: e.g. "Project tree" pinned to the top half of the left rail, "Outline" pinned to the bottom half, with a draggable sash between them. The two groups are independently collapsible. This is the natural way to present panels that the user wants visible simultaneously — putting them in tabs of one edge group forces the user to alt-tab.

Currently the only way to approximate this in dockview is:

1. One edge group with tabs — only one panel visible at a time; loses the "both panels open simultaneously" affordance.
2. One edge group containing a panel that internally renders a Splitview — works for the panel content, but you can't get a second vertical-tab strip, and the inner panels don't participate in dockview's drag/dock/serialization machinery.
3. Run an entire second dockview instance inside the edge group panel — heavy, breaks serialization, breaks drag-between-groups.

Concrete repro / receipt

dafman just shipped a VS Code-style activity rail using edge groups (single group per side, multiple panels as tabs). The follow-up user request was "I want Sessions on top and Logs visible underneath at the same time" — which requires split edge groups. We had to tell the user "dockview can't do that today" and file this.

Proposed API (one possible shape)

Allow more than one addEdgeGroup call per side:

const top = dock.api.addEdgeGroup('left', { id: 'left-top',    initialSize: 360 });
const bot = dock.api.addEdgeGroup('left', { id: 'left-bottom', initialSize: 240 });
// → vertical splitview on the left edge:
//   ┌──[left-top tabs]──┐
//   │  active panel     │
//   ├──── (sash) ───────┤
//   │  active panel     │
//   └──[left-bot tabs]──┘

…and let getEdgeGroup('left') return either the first one or accept an id:

dock.api.getEdgeGroup('left', 'left-top'); // returns specific
dock.api.getEdgeGroup('left');             // returns all → DockviewGroupPanelApi[]

Serialization (toJSON / fromJSON) would need to switch edgeGroups.left: EdgeGroupJSON to edgeGroups.left: EdgeGroupJSON[].

Drag-and-drop: tabs draggable between sibling edge groups on the same side and across sides; the existing edge-group drop overlays already cover the cross-side case.

Use cases

1. Stacked sidebars (above): Sessions + Logs on the left simultaneously, draggable divider.
2. Top + bottom edge for utility groups: dedicated "status / problems" group at the very bottom plus a separate "terminal" group above it, both pinned, both collapsible.
3. Multi-axis docking that doesn't compromise the main grid — keeping infrastructure panels out of the center but still letting the user see more than one at once.

Related

• Feature: pinnable overlay panels for edge groups (VS-style auto-hide) #1283 (pinnable overlay panels) — separate axis from this; pin/overlay vs split-stack are complementary, not duplicates.
• Unexpected behavior for the edge group's expand/collapse button #1241, Moving an edge group results in an empty space #1235 — confined to single-group behavior.

Version

• dockview-core 6.4.0
• dockview-vue 6.4.0

This is a bigger change than the dynamic-constraints one I'm filing alongside this (Map<Position, group> → Map<Position, group[]> plus splitview-per-side), so flagging it as a feature request / discussion starter rather than a small patch. Happy to discuss design tradeoffs if it lands on the roadmap. Thanks!