dockview-core 8.0.0 → 8.1.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -1,4 +1,5 @@
1
1
  declare class TransferObject {
2
+ protected constructor();
2
3
  }
3
4
  export declare class PanelTransfer extends TransferObject {
4
5
  readonly viewId: string;
@@ -6,26 +6,11 @@ import { DockviewWillDropEvent } from './dockviewGroupPanelModel';
6
6
  import { DockviewGroupPanel } from './dockviewGroupPanel';
7
7
  import { DockviewGroupDropLocation, DockviewWillShowOverlayLocationEvent } from './events';
8
8
  import { IAdvancedDnDHost, IAdvancedDnDService } from './moduleContracts';
9
- /**
10
- * The narrow surface the {@link AdvancedDnDService} needs from the host
11
- * (the `DockviewComponent`).
12
- *
13
- * The `onWill*` emitters stay on the component so the public event shape is
14
- * unchanged whether or not this module is registered; the service is only the
15
- * dispatch point those fires are routed through. Engine policy (e.g. the
16
- * `disableDnd` guard) stays on the component, ahead of the dispatch.
17
- */
18
9
  /**
19
10
  * Owns the dispatch of the advanced drag-and-drop hooks: `onWillDragPanel`,
20
- * `onWillDragGroup`, `onWillDrop` and `onWillShowOverlay`.
21
- *
22
- * At this stage the service is a thin dispatcher that forwards to the host's
23
- * emitters; the customisation surface it gates (custom drop overlays, custom
24
- * group drag ghosts, hook veto/transform behaviour) is currently inlined in
25
- * core and is extracted into this service in later phases. Routing the
26
- * dispatch through a module slot is what lets that customisation layer move
27
- * into a separately-distributed package in a future major version without
28
- * changing the public event surface.
11
+ * `onWillDragGroup`, `onWillDrop` and `onWillShowOverlay`, forwarding each to
12
+ * the host's emitters so the public event shape is unchanged whether or not
13
+ * this module is registered.
29
14
  *
30
15
  * The service holds no drag state of its own. The gesture is driven by the
31
16
  * DnD backends, and the per-group subscriptions live on the component's group
@@ -692,11 +692,15 @@ export declare class DockviewComponent extends BaseGrid<DockviewGroupPanel> impl
692
692
  /**
693
693
  * Reveal (create-or-fill) the edge group at `position` and move the dragged
694
694
  * item described by `data` into it. A newly created edge group is created
695
- * collapsed and flagged `autoReveal` so it tears down to zero footprint when
696
- * later emptied. If an edge group already exists there it is reused: the
697
- * panel is added to its tabs and its collapsed/toggled state is left as-is
698
- * (never re-created; `addEdgeGroup` throws on a duplicate position). No-op if
699
- * the EdgeGroup module is absent.
695
+ * collapsed, flagged `autoReveal` so it tears down to zero footprint when
696
+ * later emptied, and takes its auto-hide state from `options.autoHide`. If an
697
+ * edge group already exists there it is reused: the panel is added to its
698
+ * tabs and its collapsed/toggled *and auto-hide* state are left as-is (never
699
+ * re-created; `addEdgeGroup` throws on a duplicate position). This keeps a
700
+ * drag-reveal from silently converting a static edge group into an
701
+ * auto-hiding one; to change an existing group's auto-hide, call
702
+ * `api.getEdgeGroup(position)?.setAutoHide(...)` directly. No-op if the
703
+ * EdgeGroup module is absent.
700
704
  *
701
705
  * This is the primitive behind the dock-to-edge groups: the two-band
702
706
  * drag-reveal affordance routes its outer-band drops here.
@@ -187,6 +187,22 @@ export declare class DockviewGroupPanelModel extends CompositeDisposable impleme
187
187
  private _headerPosition;
188
188
  private _headerDirection;
189
189
  private _location;
190
+ /**
191
+ * The header (`dv-tabs-and-actions-container`) extent along its occupied
192
+ * axis — `offsetHeight` for a top/bottom header, `offsetWidth` for a
193
+ * left/right one — which `contentDimensions` subtracts from the group box.
194
+ *
195
+ * This was read via `offset*` on *every* `layout()`. Because the read comes
196
+ * after the group's container styles were written, it forces a synchronous
197
+ * reflow, and with N groups a single window-resize frame flushed layout N
198
+ * times (measured: 24 forced reflows/frame at 24 groups, ~68% of resize
199
+ * cost). The extent only changes when the header's tabs change (add/remove/
200
+ * wrap), its axis flips, or it's hidden/shown — never during a plain
201
+ * resize — so we cache it and invalidate on exactly those signals (plus a
202
+ * `ResizeObserver` that also catches CSS/theme-driven height changes and
203
+ * display:none transitions). `undefined` means "dirty; measure on read".
204
+ */
205
+ private _cachedHeaderSize;
190
206
  private mostRecentlyUsed;
191
207
  private _overwriteRenderContainer;
192
208
  private _overwriteDropTargetContainer;
@@ -384,6 +400,14 @@ export declare class DockviewGroupPanelModel extends CompositeDisposable impleme
384
400
  * width); a hidden header has `display:none` so its `offset*` is 0 and
385
401
  * nothing is subtracted.
386
402
  */
403
+ /**
404
+ * Measure the header's extent along its occupied axis. This is the single
405
+ * forced-reflow read; it now runs only on a cache miss (first layout after
406
+ * a header change) and inside the header's ResizeObserver — not on every
407
+ * layout frame.
408
+ */
409
+ private measureHeaderSize;
410
+ private invalidateHeaderSize;
387
411
  private contentDimensions;
388
412
  private _removePanel;
389
413
  private doRemovePanel;
@@ -474,6 +474,11 @@ export interface IPinnedTabsHost {
474
474
  readonly options: DockviewComponentOptions;
475
475
  readonly onDidAddGroup: Event<DockviewGroupPanel>;
476
476
  readonly onDidRemoveGroup: Event<DockviewGroupPanel>;
477
+ /** Fires after `updateOptions`; the service re-applies the pinned-tabs
478
+ * presentation (mode / sticky) to every existing group so a runtime
479
+ * `pinnedTabs` change takes effect. New groups pick it up in
480
+ * `onDidAddGroup`; this retrofits the ones that already exist. */
481
+ readonly onDidOptionsChange: Event<void>;
477
482
  /** Fires after a panel's pinned flag is mutated via the gated
478
483
  * `setPanelPinned`; the service's sole trigger to re-order the strip. */
479
484
  readonly onDidPanelPinnedChange: Event<DockviewPanelPinnedChangeEvent>;
@@ -589,7 +589,6 @@ export interface PinnedTabsOptions {
589
589
  /**
590
590
  * `'inline'` (default) keeps pinned tabs first within the existing strip;
591
591
  * `'separate-row'` renders them on their own VS-Code-style row.
592
- * (Phase 1 implements `'inline'` only.)
593
592
  */
594
593
  mode?: 'inline' | 'separate-row';
595
594
  /**
@@ -7,6 +7,9 @@ import { CompositeDisposable } from '../lifecycle';
7
7
  * a raw color literal (`'#abc123'`, `'rgb(0,0,0)'`), or `undefined` to inherit
8
8
  * the default. Resolution to a concrete CSS value is handled by the
9
9
  * dockview's `TabGroupColorPalette` (see `tabGroupAccent.ts`).
10
+ *
11
+ * This is a deliberate semantic alias for a public API type; inlining it to
12
+ * `string` would be a breaking API change and lose the documented meaning.
10
13
  */
11
14
  export type DockviewTabGroupColor = string;
12
15
  export interface SerializedTabGroup {
@@ -45,7 +45,7 @@ export declare class Emitter<T> implements IDisposable {
45
45
  private _last?;
46
46
  private _listeners;
47
47
  private _disposed;
48
- private readonly _pauseTokens;
48
+ private _pauseTokens?;
49
49
  static ENABLE_TRACKING: boolean;
50
50
  static readonly MEMORY_LEAK_WATCHER: LeakageMonitor;
51
51
  static setLeakageMonitorEnabled(isEnabled: boolean): void;
@@ -13,6 +13,20 @@ export declare class BranchNode extends CompositeDisposable implements IView {
13
13
  private _size;
14
14
  private _childrenDisposable;
15
15
  readonly children: Node[];
16
+ /**
17
+ * `minimumSize`/`maximumSize`/`priority` are aggregates over all children,
18
+ * read repeatedly per frame inside `Splitview.resize` / `layoutViews`.
19
+ * Because a grid is splitviews-of-splitviews, recomputing them on every
20
+ * getter access (with array allocations) would make a sash drag O(children²)
21
+ * with per-read allocation. These values only change on a structural
22
+ * mutation, a visibility toggle, or a child's own constraints changing (which
23
+ * surfaces as the child's `onDidChange`) — none of which fire during a plain
24
+ * sash drag — so we cache them and invalidate on exactly those signals.
25
+ * `undefined` means "dirty; recompute on read".
26
+ */
27
+ private _cachedMinimumSize;
28
+ private _cachedMaximumSize;
29
+ private _cachedPriority;
16
30
  private readonly _onDidChange;
17
31
  readonly onDidChange: Event<{
18
32
  size?: number;
@@ -35,6 +49,8 @@ export declare class BranchNode extends CompositeDisposable implements IView {
35
49
  get maximumWidth(): number;
36
50
  get maximumHeight(): number;
37
51
  get priority(): LayoutPriority;
52
+ private computePriority;
53
+ private invalidateCachedSizes;
38
54
  get disabled(): boolean;
39
55
  set disabled(value: boolean);
40
56
  get margin(): number;
@@ -5,11 +5,21 @@ export declare class Scrollbar extends CompositeDisposable {
5
5
  private readonly _scrollbar;
6
6
  private _scrollOffset;
7
7
  private _animationTimer;
8
+ private _pendingStyleFrame;
8
9
  private _orientation;
9
10
  static readonly MouseWheelSpeed = 1;
10
11
  get element(): HTMLElement;
11
12
  get orientation(): 'horizontal' | 'vertical';
12
13
  set orientation(value: 'horizontal' | 'vertical');
13
14
  constructor(scrollableElement: HTMLElement);
15
+ /**
16
+ * Coalesce the scrollbar restyle to one pass per animation frame. The
17
+ * wheel / scroll / pointermove handlers can each fire many times per frame,
18
+ * and `calculateScrollbarStyles` both reads layout (`clientWidth`/
19
+ * `scrollWidth`) and writes styles + `scrollLeft`/`scrollTop`; running it
20
+ * synchronously per event caused repeated read→write→read reflow. Batching
21
+ * to a frame keeps a burst of events to a single measure+write.
22
+ */
23
+ private scheduleStyleUpdate;
14
24
  private calculateScrollbarStyles;
15
25
  }
@@ -6,7 +6,17 @@ export declare class ViewItem {
6
6
  private readonly disposable;
7
7
  private _size;
8
8
  private _cachedVisibleSize;
9
+ /**
10
+ * The geometry styles last written to `container` by `layoutViews`. Sizes
11
+ * are re-applied on every layout/resize frame, but for the many views that
12
+ * didn't move on a given frame the value is identical to last time; writing
13
+ * an unchanged inline style still dirties the element for style recalc, so
14
+ * we diff against these and skip the no-op writes. `layoutViews` is the only
15
+ * writer of these four properties (verified), so the cache cannot drift.
16
+ */
17
+ private readonly _appliedStyles;
9
18
  set size(size: number);
19
+ setContainerGeometry(prop: 'width' | 'height' | 'top' | 'left', value: string): void;
10
20
  get size(): number;
11
21
  get cachedVisibleSize(): number | undefined;
12
22
  get visible(): boolean;