vue-dockable-desktop 1.0.1 → 1.1.1

package/CHANGELOG.md

@@ -11,6 +11,168 @@ correspondence lives, alongside the feature-by-feature map in [docs/PARITY.md](d
 
 ## [Unreleased]
 
+## [1.1.1] — 2026-09-19
+
+**Parity: react-dockable-desktop 6.3.1.**
+
+### Fixed
+
+- **Dragging the only docked panel onto its own group made it disappear.** With one panel in
+  the workspace, dropping it on its own drop cross — any side, the centre, or its own tab
+  strip — left the panel `docked` but in **no group**: no tab, nothing rendered, and still
+  listed as open. Re-opening it did nothing, because an already-open panel is only focused;
+  the only way back was to minimise and restore it, which returned it as a floating window.
+  Dropping it on a workspace edge left an empty group holding half the width instead.
+
+  The cause: the dock actions detach the panel before resolving the target, and detaching the
+  only panel of a group **deletes that group** — so the drop destroyed the very target it
+  named, and `splitLeafInTree` then had nothing to find. Dropping a lone panel onto its own
+  group is now a no-op, since the result would be the layout it already has. Guarded in the
+  store rather than in the drag layer, so `dockPanelToGroup`, `movePanelOrder` and
+  `dockPanelToWorkspaceEdge` are safe for any caller, not just the mouse. The same bug, in a
+  different shape, was [reported against react-dockable-desktop](https://github.com/felipecarrillo100/react-dockable-desktop)
+  and fixed there in 6.3.1 — there it duplicated the panel into two groups instead.
+
+- **A dock into a group that no longer exists no longer loses the panel.** Emptying a group
+  removes it, so an id held across a layout change can name one that is gone; placing into it
+  left the panel in no group. `dockPanelToGroup` and `movePanelOrder` now ignore such a call
+  with a development warning.
+
+- **Layouts already saved in the broken state are repaired when read.** `saveLayout()` wrote
+  the corrupted tree out, so the fault came back on every reload and a stored layout stayed
+  broken. Reading one now drops a panel listed in more than one group from all but the first,
+  prunes a group emptied by that unless it set `keepOnEmpty`, collapses a branch left with one
+  child, and puts a panel the layout calls docked but that no group lists back into the first
+  group, naming each repair in a development warning. Only what is *read* changes — the saved
+  format is untouched, so every rdd fixture still round-trips byte-identically.
+
+- **`openPanel` recovers a panel that is in no group** instead of only focusing it — a safety
+  net, now that nothing should produce that state.
+
+- **An emptied root group keeps its own identity.** Removing the last panel replaced the root
+  leaf with a fresh `group-default`, so a leaf the application had named, or had marked
+  `keepOnEmpty` or `canClose: false`, silently lost all three.
+
+Covered by `test/store/selfDrop.test.ts` (20), the repair and the guard as pure functions in
+`test/core/layoutTree.test.ts`, and three compatibility tests for layouts written by 1.1.0.
+New M6 rules keep the guard in the store rather than in the drag layer, and new M4 rules keep
+the repair on the shared read path.
+
+### Fixed — the gate harness itself
+
+- **`npm run gate:selftest` was proving almost nothing.** It ran each gate as `node ${gate}`
+  while 77 of its 89 checks passed a gate that already began with `node`, so the command
+  executed was `node node scripts/gates/mN.mjs` — which fails whatever the mutation did, and a
+  failing gate is exactly what the harness reads as "this rule caught its violation". Those
+  rules were reported as proven without their gate ever running. The command is now used as
+  given, and a mutation that changes no bytes is reported as a miss in its own right, since a
+  stale anchor is the other way a check quietly stops testing anything.
+
+  With the harness honest, four checks were failing: two pinned `version = '1.0.0'`, stale
+  since 1.0.1, and now match any version; and two M14 capability checks were satisfied by
+  *prose* — the capability scan read whole files, so a doc comment or a `<code>onBeforeClose()`
+  in a paragraph counted as a demonstration. Capabilities that are called are now looked for in
+  script blocks with comments stripped, and the two that are bound in markup are matched on a
+  `<Vdd…>` tag. All 89 rules now genuinely fail when their rule is broken.
+
+## [1.1.0] — 2026-09-18
+
+**Parity: react-dockable-desktop 6.3.0.**
+
+### Fixed
+
+- **`<VddDesktop :skin>` did nothing at all.** The stylesheet keyed its 104 skin selectors on
+  `data-workspace-skin` while the component emitted `data-vdd-skin`, so no skin rule had ever
+  matched in any published version: all seven skins painted identically to the default. The
+  stylesheet now uses the library's own `data-vdd-skin`, which is the name the component, its
+  test and [ADR 0008](docs/decisions/0008-css-prefix.md) already agreed on.
+
+  A consumer who wrote a custom skin against `[data-workspace-skin="…"]`, as the manual
+  previously showed, must rename it to `[data-vdd-skin="…"]`. Nothing can break in practice:
+  skins have never applied, so no such CSS was having any effect.
+
+- **Skins would have been unusable in light mode**, which the rename alone would have shipped. A
+  skin's token block matches the workspace element as well as the root, and the colour scheme was
+  only on the root — so a skin's *dark* tokens were re-declared closer to the content than the
+  root's light ones and shadowed them: dark panels with dark text. `<VddDesktop>` now mirrors
+  `data-color-scheme` onto the workspace element beside the skin, which is how rdd has always done
+  it. Measured across seven skins × two schemes on four surfaces; every surface now flips.
+
+- **The sidebar, its drawer and the workspace toolbar were unstyled in dark mode.** Twenty-nine
+  tokens — the whole `--vdd-sidebar-*` family, the rail's icon colours and the workspace toolbar's
+  button states — had their dark values only inside `[data-color-scheme="dark"]`, and that selector
+  never matches: dark is signalled by *removing* the attribute, as `useColorScheme()` documents. So
+  they were undefined exactly when they were needed, and fifteen of them are read with no `var()`
+  fallback, which drops the whole declaration instead of defaulting it. The strips had no
+  background, the drawer inherited black text, and **the selected rail icon had no colour at all**,
+  which is why it appeared not to render.
+
+  Dark is the base look, so those values now live on `:root` and the dark block is gone —
+  `[data-color-scheme="light"]` overrides them, which is all a scheme block should do. An
+  application that sets `data-color-scheme="dark"` explicitly sees no change. Reported from the
+  demo; it affects rdd too, whose own demo happens to set the attribute for both schemes and so
+  never shows it.
+
+- **The sidebar rail did not fill its own column.** `.vdd-sidebar-strip-outer` is full height,
+  but it is a block wrapper — added in this port to own the width-collapse transition — and a
+  block does not stretch its child the way rdd's flex row did. So the strip inside it shrank to
+  its buttons, 216px of a 915px column, and its background covered only the icons while the rest
+  showed the host page through. It has `height: 100%` now.
+
+- **A rail holding one tab collapsed that tab to its icon.** An active rail button takes
+  `width: var(--vdd-tab-btn-active-width, 100%)`, and that percentage resolves against the
+  shrink-to-fit tabs list; with a single tab there is no sibling to hold the list open, so button
+  and list both shrank to 26px against a normal 44px, putting the accent border 15px inboard of
+  the rail's edge. `.vdd-sidebar-tabs-list` now carries the same `min-width: 44px` floor that
+  `.vdd-sidebar-header-area` and `.vdd-sidebar-footer-area` already had for exactly this reason.
+  A rail with several tabs hid it, because the inactive buttons' own 44px kept the list open.
+
+- **Text in a side panel was black on a dark background.** `.vdd-side-panel` set a background
+  and no foreground, so content teleported into a drawer inherited the host page's text colour —
+  the user agent's black. Measured at **1.18:1** in the demo's own Panel manager, against the
+  16.31:1 of the library's title beside it. `.vdd-modal-window`, `.vdd-workspace` and
+  `.vdd-sidebar-content-drawer` all set a colour; the drawer was simply missed. rdd has the same
+  omission, hidden in its demo by Bootstrap's page-wide theme, which this demo deliberately does
+  not import. An application that wants its own colour still sets it on its content or through
+  `createWorkspace({ classes: { sidePanelBody } })`.
+
+- **The theming chapter documented three things that were not true**: the skin selector
+  (`data-workspace-skin`), the claim that *"the workspace publishes its scheme as
+  `data-color-scheme`"* — the library only ever reads it; your application sets it — and a
+  `createWorkspace({ windowClass, modalClass, … })` config shape that has never existed (it is
+  `classes: { window, modal, … }`).
+
+### Added
+
+- **A token reference**: all **119** tokens the library declares on `:root`, in sixteen groups,
+  with defaults and what each paints ([ch. 10](docs/manual/10-theming.md#token-reference)). A gate
+  checks it against the stylesheet in both directions, so a new token needs a row and a row cannot
+  outlive its token.
+
+- **`:root` is now a complete inventory.** Six measurements and off-by-default effects that
+  existed only as `var()` fallbacks are declared at exactly those values, so nothing renders
+  differently — `--vdd-tab-accent-bar-width`, `--vdd-tab-btn-active-glow/-radius/-width`,
+  `--vdd-toolbar-accent-bar-width`, `--vdd-toolbar-btn-active-glow`. Together with the
+  twenty-nine folded out of the dark block, everything a skin may override is declared and
+  documented in one place.
+
+- **Guidance for defining your own skin**, both of it learned by measurement: leave the selector
+  unqualified (`[data-vdd-skin="mono"]`, not `html[…]`, which cannot match the workspace element
+  and loses there), and import your stylesheet after the library's. The demo ships `mono` as a
+  worked example in both schemes, and the browser gate measures it beside the seven built-ins.
+
+### Changed
+
+- The M14 browser gate's skin step used to cycle the seven skins and assert nothing — which is how
+  this shipped. It now measures each skin in both schemes and fails if a surface does not change
+  between them or if a skin paints identically to the default. Two new source rules join it: every
+  `[data-*]` selector in the stylesheet must name an attribute a component emits (the rule that
+  would have caught this on day one), and the token reference must match the stylesheet. A third
+  rejects a token whose only declaration sits inside a colour-scheme block — the shape that left
+  the sidebar unstyled. The browser gate also measures the chrome *outside* the workspace now: the
+  first matrix sampled only inside it, and passed while the sidebar was unpainted. All are proven
+  non-vacuous by `gate:selftest`, now 87 rules.
+
 ## [1.0.1] — 2026-09-17
 
 **Parity: react-dockable-desktop 6.3.0.**

package/dist/core/layoutTree.d.ts

@@ -56,6 +56,36 @@ export declare function findFirstLeafId(node: LayoutNode): string | null;
 export declare function findLeafForPanel(node: LayoutNode, id: string): string | null;
 /** A leaf by id, or `null`. */
 export declare function findLeaf(node: LayoutNode | null, leafId: string): LayoutLeafNode | null;
+/**
+ * Is `panelId` the only panel in `leafId`?
+ *
+ * The question every dock action has to ask *before* it detaches anything. Detaching a panel
+ * deletes its leaf once that leaf is empty, so a drop onto the dragged panel's own leaf
+ * destroys the very target it names, and the placement that follows has nowhere to go.
+ * Dropping a lone panel onto itself is a no-op by definition: the result is the layout it
+ * already has.
+ */
+export declare function isLoneOccupant(node: LayoutNode, leafId: string, panelId: string): boolean;
+/**
+ * Heal a tree that lists a panel twice, or lists none of a docked panel.
+ *
+ * Both are states this library once produced and then *saved*: a lone docked panel dropped
+ * on its own group left rdd with the panel in two leaves and vdd with it in none, and
+ * `saveLayout()` wrote the result out, so the fault returned on every reload. Repairing on
+ * read means a layout stored by an affected version loads clean with nothing asked of the
+ * application. It changes only what is read; `saveLayout()`'s output is untouched, which is
+ * what keeps the format compatible (docs/decisions/0009-layout-json-compatibility.md).
+ *
+ * `repairs` is empty and the input object is returned unchanged when there is nothing wrong,
+ * so a healthy layout costs one walk and no allocation.
+ */
+export declare function repairLayoutTree(gridRoot: LayoutNode, panels: Record<string, {
+    id: string;
+    state: PanelInfo['state'];
+}>): {
+    gridRoot: LayoutNode;
+    repairs: string[];
+};
 /** Whether a leaf exists in the tree. */
 export declare function leafExists(node: LayoutNode, leafId: string): boolean;
 /** Update the sizes of the branch at `path` (a list of child indices from the root). */