@danxbot/ui 13.0.1 → 13.0.2
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.
|
@@ -26,14 +26,31 @@ export { edgePath };
|
|
|
26
26
|
export declare function layoutExplorerTree<Extra>(tree: ExplorerTree<Extra>, crossLinks?: readonly CrossLink[], options?: LayoutOptions): ExplorerLayout<Extra>;
|
|
27
27
|
/**
|
|
28
28
|
* The box a camera should keep in frame around `focusId`: the focused node
|
|
29
|
-
* itself
|
|
30
|
-
*
|
|
31
|
-
*
|
|
29
|
+
* itself and every one of its direct children (one rank down), with the
|
|
30
|
+
* frame's vertical extent alone stretched to reach its parent's rank (one
|
|
31
|
+
* rank up) — "the minimap always frames the current node, its parent and its
|
|
32
|
+
* children" (DX-3401's fix for the minimap shrinking an entire tree to
|
|
32
33
|
* specks, and for the full-screen explorer's initial view not opening
|
|
33
34
|
* focused). Computed from an ALREADY-LAID-OUT tree, so it can never disagree
|
|
34
35
|
* with what is actually on screen the way fitting a separately-computed
|
|
35
36
|
* bounding box could. `null` when `focusId` isn't laid out at all — nothing
|
|
36
37
|
* to frame (a stale id, or data still loading).
|
|
38
|
+
*
|
|
39
|
+
* THE PARENT'S X/WIDTH ARE DELIBERATELY NEVER UNIONED IN (DX-3401 follow-up).
|
|
40
|
+
* An earlier version unioned the parent's whole box in, same as a child's.
|
|
41
|
+
* dagre centres a parent horizontally over the barycenter of ALL its
|
|
42
|
+
* children, not just the focused one — so a parent with many other children
|
|
43
|
+
* spread wide (exactly the "one system, ~15 areas" shape this card exists to
|
|
44
|
+
* fix) can sit far to one side of the union of `focus` + its own children.
|
|
45
|
+
* Pulling that parent's x/width into the frame then stretches it to cover the
|
|
46
|
+
* real horizontal gap between the parent and this one child, reproducing a
|
|
47
|
+
* milder version of the original "whole tree crushed to a strip" bug for
|
|
48
|
+
* this specific shape (confirmed live against the Ringlet demo: a `frameBox`
|
|
49
|
+
* nearly as wide as the entire tree's `contentBox`). Only the parent's Y
|
|
50
|
+
* range is folded in, so the frame reaches up far enough for the connecting
|
|
51
|
+
* edge into the parent to be visible — a parent off to the side is reached by
|
|
52
|
+
* panning, the same trade-off this function already makes for siblings
|
|
53
|
+
* (drawn by `neighbourhoodTree` but never pulled into the frame's own box).
|
|
37
54
|
*/
|
|
38
55
|
export declare function frameBoxFor<Extra>(layout: ExplorerLayout<Extra>, focusId: string): Box | null;
|
|
39
56
|
/**
|