vue-dockable-desktop 1.9.0 → 1.10.0

package/CHANGELOG.md

@@ -11,6 +11,48 @@ correspondence lives, alongside the feature-by-feature map in [docs/PARITY.md](d
 
 ## [Unreleased]
 
+## [1.10.0] — 2026-10-06
+
+**Parity: react-dockable-desktop 7.9.0.** Control over where users can move panels: per-kind rules and
+an app-wide veto, all opt-in. Without them nothing changes, and the app's own calls are never
+restricted. Same names as rdd 7.9.0.
+
+### Added
+
+- **`canFloat` and `canDock` per kind**, next to `canDrag`, `canMinimize` and `canClose`.
+  `canFloat: false` keeps a panel in the grid: a tab drag can't end in a floating window, and
+  "Float Window" and the taskbar's "Maximize" are hidden. `canDock: false` keeps a panel floating:
+  dragging it offers no group, tab or edge targets.
+- **`canDrop`, an app-wide veto.** `createWorkspace({ canDrop: ({ panelId, component, to }) => boolean })`
+  is asked for every place a dragged panel could go, and for the "Float" and "Maximize" menu items;
+  `to` is a `PanelDropTarget` (a group, an edge, or a float). A forbidden target isn't offered, and
+  it's asked again at release. Positions and corners are the ones the move applies, mirrored under
+  RTL. If it throws, the move is allowed and the error is logged. New types: `PanelDrop`,
+  `PanelDropTarget`.
+- Both apply only to what the user does; the app's own calls always work.
+
+### Fixed
+
+- **A drag built on `startPointerDrag` could outlive its element.** It ended on pointerup,
+  pointercancel and window blur, but not when the capturing element was removed mid-drag (an
+  overlay widget closed during its own drag), which left its listeners attached and its classes on
+  the page. It now also ends on a lost pointer capture, listened for on the document, where browsers
+  fire it; `onCancel` runs if given.
+
+### Docs
+
+- Layout (Chapter 4): **Controlling where users can move panels**. Panels (Chapter 3) and the API
+  reference: the new options. `PARITY.md`: the rdd 7.9.0 trace.
+
+### Tests
+
+- `test/components/releaseB.test.ts` (12 tests): `canFloat` (no float on nothing, no corners, no
+  "Float Window" or "Maximize" from a group, the app's `floatPanel` still works), `canDock` (no group
+  or edge targets, only corners), `canDrop` (its argument, vetoed zones and edges not offered, RTL
+  positions, tab insertion into a vetoed group, rules changed mid-drag for zones and tabs, a throwing
+  `canDrop`, no rules meaning every target), and `startPointerDrag` ending on a lost capture. Each
+  rule was seen failing with it broken. `api-surface.json` gains the two types.
+
 ## [1.9.0] — 2026-10-06
 
 **Parity: react-dockable-desktop 7.8.0.** More control over how the desktop looks and where panels

package/dist/core/dockRules.d.ts

@@ -0,0 +1,9 @@
+/**
+ * Docking rules (1.10.0): what the *user* may do with a panel. The kind's own `canFloat` /
+ * `canDock` first, then the workspace's `canDrop`. Never consulted by the app's own calls.
+ */
+import type { PanelDropTarget } from '../types';
+import type { Workspace } from './workspace';
+type RuleHost = Pick<Workspace<never>, 'state' | 'registry' | 'config'>;
+export declare function isDropAllowed(ws: RuleHost, panelId: string, to: PanelDropTarget): boolean;
+export {};

package/dist/core/panelMenu.d.ts

@@ -8,6 +8,7 @@
 import type { ContextMenuItem } from './contextMenu';
 import type { PanelDefaultOptions } from './registry';
 import type { Label, MessageDescriptor } from '../types';
+import type { Workspace } from './workspace';
 /**
  * Just enough of the workspace to build a menu, so this module does not depend on the store.
  *
@@ -19,6 +20,10 @@ interface MenuHost {
     format: (label: Label | undefined) => string;
     messages: Record<string, MessageDescriptor>;
     panelMenuItems: (id: string) => ContextMenuItem[];
+    /** For the docking rules (1.10.0): floating is a move they decide. */
+    state: Workspace<never>['state'];
+    registry: Workspace<never>['registry'];
+    config: Workspace<never>['config'];
 }
 export interface PanelMenuActions {
     float: () => void;

package/dist/core/registry.d.ts

@@ -23,6 +23,19 @@ export interface PanelDefaultOptions {
     canMinimize?: boolean;
     /** Allow dragging the tab, which is also what allows floating by drag. @default true */
     canDrag?: boolean;
+    /**
+     * `false`: the user can't make this panel floating. A tab drag can't end in a floating window
+     * (dropped on nothing or on a corner, it stays where it was), and "Float Window" and the taskbar's
+     * "Maximize" are hidden. A window the app floated itself can still be moved. The app's own
+     * `floatPanel` always works. @default true (1.10.0)
+     */
+    canFloat?: boolean;
+    /**
+     * `false`: the user can't dock this panel. Dragging it offers no group, tab or edge targets
+     * (corners still pin a floating window), so it stays floating. The app's own docking calls always
+     * work; give the kind `initialTarget: 'floating'` so it opens floating. @default true (1.10.0)
+     */
+    canDock?: boolean;
     /** Show a letter tile instead of a live thumbnail in the taskbar hover preview. @default false */
     disableLivePreview?: boolean;
     /**

package/dist/core/workspace.d.ts

@@ -1,5 +1,5 @@
 import type { App, Component, ComputedRef, InjectionKey } from 'vue';
-import type { DirtyStateOptions, DropPosition, FloatAnchor, FloatingWindow, Label, LayoutNode, MessageDescriptor, MessageFormatter, PanelInfo, SplitDirection } from '../types';
+import type { DirtyStateOptions, DropPosition, FloatAnchor, PanelDrop, FloatingWindow, Label, LayoutNode, MessageDescriptor, MessageFormatter, PanelInfo, SplitDirection } from '../types';
 import { PanelRegistry } from './registry';
 import type { PanelDefaultOptions } from './registry';
 import type { ContextMenuItem, ContextMenuRequest, ShowContextMenuOptions } from './contextMenu';
@@ -43,6 +43,14 @@ export interface WorkspaceConfig {
      * rendered elements, which is the part that can actually break.
      */
     classes?: HostClasses;
+    /**
+     * Veto where users can move panels (1.10.0). Called for each place a dragged panel could go, and
+     * for the built-in "Float" and "Maximize" menu items: return `false` and that target isn't offered
+     * and the move doesn't happen. It runs after the kind's own `canFloat` / `canDock`, and only for
+     * what the user does: the app's own calls always work. Keep it fast and pure; it runs while the
+     * pointer moves.
+     */
+    canDrop?: (drop: PanelDrop) => boolean;
 }
 /** Consumer classes added to the library's chrome. Every field is optional. */
 export interface HostClasses {