@osamash/floor-planner 1.2.4 → 1.2.5

package/dist/types/react-planner/ReactPlannerLoader.d.ts

@@ -1,2 +1,21 @@
-declare const ReactPlannerLoader: () => import("react/jsx-runtime").JSX.Element;
+import "./react-planner.css";
+interface ReactPlannerLoaderProps {
+    /** Defaults to the theme the planner itself is about to open in, so the
+     *  hand-off from skeleton to real UI doesn't flash. */
+    theme?: "light" | "dark";
+}
+/** Skeleton of the planner's chrome, shown while the plan and catalog load.
+ *
+ *  It reuses the real layout classes — `.floor_planner-headerbar`,
+ *  `.fp-toolbar-rail`, `.fp-toolbar-subpanel`, `.fp-toolbar-utility`,
+ *  `.fp-zoom-controls` — instead of restating their geometry, so the
+ *  placeholder keeps lining up with the real UI when that chrome moves. Only
+ *  the grey blocks and the few `.fp-loader__*` rules are its own.
+ *
+ *  What it mirrors is the planner's *opening* state: header, the three-item
+ *  tool rail, the Build sub-panel the toolbar starts on, zoom controls
+ *  shifted clear of that panel, the utility bar and the AI bubble. No
+ *  properties sidebar — that only appears once something is selected — and no
+ *  footer, which renders nothing today. */
+declare const ReactPlannerLoader: ({ theme }: ReactPlannerLoaderProps) => import("react/jsx-runtime").JSX.Element;
 export default ReactPlannerLoader;

package/dist/types/react-planner/ai-chat/aiService.d.ts

@@ -35,6 +35,12 @@ export interface WallInfo {
     length: number;
     orientation: "horizontal" | "vertical" | "diagonal";
     holeCount: number;
+    /** cm. */
+    thickness: number | null;
+    height: number | null;
+    /** The wall's two faces. Which one looks into a given room is geometric. */
+    textureA: string | null;
+    textureB: string | null;
 }
 export interface HoleInfo {
     id: string;
@@ -49,8 +55,8 @@ export interface HoleInfo {
 export interface AreaInfo {
     id: string;
     /** "room" = enclosed by walls, "surface" = a free-standing polygon (grass,
-     *  patio, driveway…). Only surfaces can be transformed with
-     *  `set-surface-transform` / `duplicate-surface`. */
+     *  patio, driveway…). A room's corners are shared with the walls around it,
+     *  so the two are not interchangeable targets for anything that reshapes. */
     kind: "room" | "surface" | "area";
     vertices: {
         id: string;
@@ -58,6 +64,9 @@ export interface AreaInfo {
         y: number;
     }[];
     color: string | null;
+    /** Floor fill/texture. Mutually exclusive; "none" means unset. */
+    pattern: string | null;
+    texture: string | null;
     customName: string | null;
     roomCategory: string | null;
     roomType: string | null;
@@ -125,150 +134,145 @@ export interface PlanSummary {
     roomTypes: RoomCategoryOption[];
     selection: PlanSelection;
 }
-export type PlannerAction = {
-    type: "add-wall";
-    x0: number;
-    y0: number;
-    x1: number;
-    y1: number;
-    id?: string;
-} | {
+/**
+ * Which side of an existing room a new one goes on. Screen-relative, matching
+ * how a user says it; note the scene's +y is UP, so "below" is smaller y.
+ */
+export type RoomSide = "left" | "right" | "above" | "below";
+/**
+ * An action the agent may emit for the planner to apply.
+ *
+ * **No action carries coordinates, and none ever should.** The agent says what
+ * to build and which existing room it relates to; every number describing a
+ * POSITION is computed by `applyPlannerActions`. Rooms live at 5-digit scene
+ * coordinates, and a room whose edge is a few centimetres off its neighbour
+ * draws as an unreachable void in 2D and a hole in the floor in 3D — so that
+ * arithmetic belongs where it can be exact.
+ *
+ * The set is being rebuilt one action at a time; the previous 23-variant
+ * union is on the `pre-rewrite-backup` branch. Each new variant needs three
+ * things moving together: this type (what may arrive), the backend's
+ * `ACTION_SPECS` (what the model may say), and a branch in
+ * `applyPlannerActions` (what actually happens).
+ */
+export type PlannerAction = AddRoomAction | SetRoomPropertiesAction | AddHoleAction | AddItemAction | SetWallPropertiesAction | SetItemPropertiesAction | AddSurfaceAction | DeleteAction | SetSurfacePropertiesAction;
+export type AddRoomAction = {
     type: "add-room";
-    x: number;
-    y: number;
+    /**
+     * Shown on the plan, and how a later `of` refers to this room — so it has to
+     * be unique within the scene ("Bedroom 1", "Bedroom 2").
+     */
+    name: string;
+    /** cm. Defaults are applied backend-side, so these arrive populated. */
     width: number;
     height: number;
-    id?: string;
-} | {
-    type: "add-surface";
-    points: {
-        x: number;
-        y: number;
-    }[];
-    surfaceType?: string;
-    id?: string;
-} | {
-    type: "add-item";
-    itemType: string;
-    x: number;
-    y: number;
-    width?: number;
-    height?: number;
-    rotation?: number;
-    id?: string;
-} | {
-    type: "add-hole";
-    /** Real line ID, or a "$tag" / "$tag.side" reference — see note above. */
-    lineID: string;
-    holeType: string;
-    offset: number;
-    id?: string;
-} | {
-    type: "set-area-color";
-    areaID: string;
-    color: string;
-} | {
-    type: "set-area-properties";
-    areaID: string;
-    customName?: string;
+    /**
+     * The NAME of the room this one sits against — either already in the scene
+     * or created earlier in this same batch. Omitted together with `side` for
+     * the first room of a plan, which is centered in the scene instead.
+     */
+    of?: string;
+    side?: RoomSide;
+    /** Catalog room type; also sets the floor color to that type's own color. */
     roomCategory?: string;
     roomType?: string;
-    patternColor?: string;
-    /** One of PlanSummary.catalogAreaPatterns keys (or "none"). */
+    /** Explicit floor color. Wins over the room type's default when both are set. */
+    color?: string;
+};
+export type SetRoomPropertiesAction = {
+    type: "set-room-properties";
+    /** A room name, or the literal "selected" for the room highlighted in the canvas. */
+    room: string;
+    /** Renames the room. */
+    name?: string;
+    roomCategory?: string;
+    roomType?: string;
+    color?: string;
     pattern?: string;
-    /** One of PlanSummary.catalogAreaTextures keys (or "none"). */
     texture?: string;
-    showName?: boolean;
-    showSurfaceArea?: boolean;
-} | {
+};
+export type AddHoleAction = {
+    type: "add-hole";
+    /** Verbatim from PlanSummary.catalogHoleTypes. */
+    holeType: string;
+    /**
+     * The two rooms this opening connects; the shared wall is found here. One
+     * opening has one representation, so it cannot be described from both sides
+     * and land as two doors. Mutually exclusive with room/side.
+     */
+    between?: [string, string];
+    /** A particular wall — the only way to reach an exterior one. */
+    room?: string;
+    side?: RoomSide;
+};
+export type AddItemAction = {
+    type: "add-item";
+    /** Verbatim from PlanSummary.catalogItemTypes. */
+    itemType: string;
+    /** A room name, or "selected". */
+    room: string;
+    /** 1-8. col 1 is the left eighth of the room, row 1 the top. */
+    col: number;
+    row: number;
+    /** 0, 90, 180 or 270. */
+    rotation?: number;
+};
+export type SetWallPropertiesAction = {
     type: "set-wall-properties";
-    wallID: string;
-    colorA?: string;
-    colorB?: string;
-    /** One of PlanSummary.catalogWallTextures keys (or "none"). */
-    textureA?: string;
-    textureB?: string;
-    /** cm */
+    /** A room name, or "selected". All four of its walls unless `side` is given. */
+    room: string;
+    side?: RoomSide;
+    /** Applied to the wall face looking into `room`. */
+    color?: string;
+    texture?: string;
+    /** cm. Whole-wall, so a shared wall changes for both rooms. */
     thickness?: number;
-    /** cm */
     height?: number;
-    customName?: string;
-    showName?: boolean;
-} | {
-    /** Edit an existing item in place — the same set of changes the
-     *  selection toolbar offers in the 2D view. Omitted fields are left
-     *  untouched. */
+};
+export type SetItemPropertiesAction = {
     type: "set-item-properties";
-    itemID: string;
-    x?: number;
-    y?: number;
-    /** Degrees, absolute (not a delta). Positive = counter-clockwise. */
+    /** A room name, or "selected". */
+    room: string;
+    /** The furniture's catalog name, e.g. "macheroni sofa". */
+    item: string;
+    /** Move it to this cell of the room's 8x8 grid. Both or neither. */
+    col?: number;
+    row?: number;
+    /** The new angle, not a turn to add. */
     rotation?: number;
-    /** Uniform size multiplier, clamped to 0.2–8. 1 = catalog size. */
+    /** Multiplier on the catalog size; the only sizing an item has. */
     scale?: number;
     flipHorizontal?: boolean;
     flipVertical?: boolean;
-} | {
-    /** Edit an existing door / window in place. */
-    type: "set-hole-properties";
-    holeID: string;
-    /** 0..1 along its wall. */
-    offset?: number;
-    /** Mirror along the wall — moves a door's hinge to the other end. */
-    flipAlongWall?: boolean;
-    /** Mirror across the wall — flips which side a door opens into. */
-    flipAcrossWall?: boolean;
-} | {
-    /** Rotate / mirror a surface polygon about its own center. Rooms are
-     *  rejected: their vertices are shared with the walls around them. */
-    type: "set-surface-transform";
-    areaID: string;
-    /** Degrees, relative to where the surface is now. Positive =
-     *  counter-clockwise on screen, as for `set-item-properties.rotation`. */
-    rotate?: number;
-    /** "x" flips it left-right, "y" top-bottom. */
-    mirror?: "x" | "y";
-} | {
-    /** Copy a surface polygon, keeping its look, set down clear of the
-     *  original. The copy ends up selected. */
-    type: "duplicate-surface";
-    areaID: string;
-} | {
-    /** Copy an item, keeping its rotation / scale / flips, offset slightly
-     *  from the original. The copy ends up selected. */
-    type: "duplicate-item";
-    itemID: string;
-} | {
-    /** Copy a door / window along the same wall. */
-    type: "duplicate-hole";
-    holeID: string;
-} | {
-    type: "move-vertex";
-    vertexID: string;
-    x: number;
-    y: number;
-} | {
-    type: "delete-wall";
-    wallID: string;
-} | {
-    type: "delete-item";
-    itemID: string;
-} | {
-    type: "delete-hole";
-    holeID: string;
-} | {
-    type: "remove-room";
-    areaID: string;
-} | {
-    type: "clear";
-} | {
-    type: "switch-view";
-    view: "2d" | "3d";
-} | {
-    type: "toggle-dimensions";
-    show: boolean;
-} | {
-    type: "undo";
+};
+export type AddSurfaceAction = {
+    type: "add-surface";
+    /** The room whose wall it lies against, and which side. Must face outdoors. */
+    of: string;
+    side: RoomSide;
+    name?: string;
+    /** cm away from the wall; it runs that wall's full width. */
+    depth?: number;
+    texture?: string;
+    color?: string;
+};
+export type DeleteAction = {
+    type: "delete";
+    /** A room name, a surface name, or "selected". */
+    room: string;
+    /** Present to delete one piece of furniture inside it instead of the room. */
+    item?: string;
+};
+export type SetSurfacePropertiesAction = {
+    type: "set-surface-properties";
+    /** Its name from the Outdoor surfaces list. */
+    surface: string;
+    name?: string;
+    /** cm out from the wall it lies against; same wall, same width. */
+    depth?: number;
+    texture?: string;
+    pattern?: string;
+    color?: string;
 };
 export interface AIResponse {
     reply: string;
@@ -277,9 +281,9 @@ export interface AIResponse {
      * Multi-step continuation. Building something big (a whole multi-room
      * floor plan) can need more actions than fit in one well-grounded
      * response — e.g. you want to see a room's real wall IDs (from a fresh
-     * `PlanSummary`) before placing doors on it, rather than guessing with a
-     * `$tag` (see the note on `PlannerAction` above; `$tag`s work within one
-     * response, this is for spanning several).
+     * `PlanSummary`) before placing doors on it. Real IDs are random and only
+     * exist once the library has created the element, so anything that needs one
+     * has to wait for the next call.
      *
      * Set `done: false` to have the library apply this response's `actions`,
      * take a fresh `summarizePlan()` of the result, and call your handler
@@ -297,6 +301,15 @@ export interface AIResponse {
      * more than that for one user request.
      */
     done?: boolean;
+    /**
+     * Actions the backend rejected, with the reason. Fed back to the agent on the
+     * next continuation so it can correct itself instead of repeating the
+     * mistake — see the "Continue." turn in AIChatPanel.
+     */
+    dropped?: {
+        reason: string;
+        action: unknown;
+    }[];
 }
 /**
  * Extras the library hands a handler on every call. Optional on purpose: a

package/dist/types/react-planner/ai-chat/plannerActions.d.ts

@@ -1,3 +1,20 @@
 import type { PlanSummary, PlannerAction } from "./aiService";
 export declare function summarizePlan(planner: any): PlanSummary;
-export declare function applyPlannerActions(actions: PlannerAction[]): void;
+/**
+ * Applies a batch of actions from the agent to the planner.
+ *
+ * The agent never sends coordinates. It says how big a room is, what to call
+ * it, and which existing room it sits next to — every number describing a
+ * POSITION is worked out here, where it can be exact. A room with no `of` /
+ * `side` is centered in the scene, which is only ever right for the first room.
+ *
+ * Rooms created earlier in this same batch are valid anchors: each one is
+ * looked up by name from live state after it is created, so a five-room plan
+ * arrives as five actions that chain off each other.
+ *
+ * @returns `skipped` — human-readable reasons anything was not applied, shown
+ *   to the user by the caller.
+ */
+export declare function applyPlannerActions(actions: PlannerAction[]): {
+    skipped: string[];
+};

package/dist/types/react-planner/ai-chat/streamingClient.d.ts

@@ -7,7 +7,6 @@ import type { AIRequestHandler } from "./aiService";
  *
  * Wire format (Server-Sent Events, POST — so NOT `EventSource`-compatible):
  *
- *   event: meta   data: { provider, model }           once, before any output
  *   event: reply  data: { delta }                     zero or more, in order
  *   event: final  data: { reply, actions, done, … }   authoritative, terminal
  *   event: error  data: { error, type }               terminal

package/dist/types/react-planner/catalog/catalog.d.ts

@@ -47,8 +47,28 @@ export default class Catalog {
     private elements;
     categories: Record<string, CatalogCategory>;
     private propertyTypes;
+    /**
+     * Placeholders handed out for types the plan references and this catalog
+     * doesn't have. Cached so a type resolves to the same object every render,
+     * and so the warning about it is printed once.
+     */
+    private missingElements;
     unit: Unit;
     constructor(unit?: Unit);
+    /**
+     * The element `type` names, or a placeholder if the catalog has no such
+     * element.
+     *
+     * Deliberately total. Every renderer and editor reaches an element through
+     * here, and a plan can legitimately outlive the catalog it was drawn with —
+     * an item renamed, dropped, or opened by an app carrying a different subset.
+     * Throwing meant one stale `type` in a saved plan took down the render of
+     * everything around it; the placeholder keeps the rest of the plan on screen
+     * and keeps the offending element selectable, movable and — because nothing
+     * rewrites its `type` — able to come back intact against the right catalog.
+     * Callers that need to know whether something is really registered ask
+     * `hasElement`.
+     */
     getElement(type: string): CatalogElement;
     /** Every registered element of a prototype ("items", "holes", "lines"),
      *  regardless of the category it was filed under. Backs the sidebar's

package/dist/types/react-planner/catalog/factories/ItemFactory.d.ts

@@ -12,6 +12,8 @@ export default function (json: any): {
         tag: any;
         description: any;
         image: any;
+        width: any;
+        depth: any;
     };
     properties: any;
     render2D: (element: any, layer: any, scene: any) => import("react/jsx-runtime").JSX.Element;

package/dist/types/react-planner/catalog/unknown-element.d.ts

@@ -0,0 +1,10 @@
+import type { CatalogElement } from "./catalog";
+/**
+ * Build the stand-in for `type`.
+ *
+ * `prototype` is left empty on purpose: the element's own record already
+ * carries the right one, and claiming one here would file the placeholder among
+ * real elements — `getElementsOfPrototype` backs the "similar elements" list,
+ * which should never offer a missing type as something to place.
+ */
+export default function unknownElement(type: string): CatalogElement;

package/dist/types/react-planner/class/area.d.ts

@@ -1,4 +1,5 @@
 import { Set } from "immutable";
+import { type LineFamily } from "../utils/line-family";
 declare class Area {
     static getSurfaceLines(state: any, layerID: string, areaID: string): Set<string>;
     static center(state: any, layerID: string, areaID: string): {
@@ -24,7 +25,10 @@ declare class Area {
     static mirror(state: any, layerID: string, areaID: string, axis: "x" | "y"): {
         updatedState: any;
     };
-    static add(state: any, layerID: any, type: any, verticesCoords: any, catalog: any): {
+    /** `family` says which graph the boundary belongs to. Walls and surfaces can
+     *  now have distinct vertices at identical coordinates, so without it the
+     *  lookup below could bind a surface polygon to a wall's corner. */
+    static add(state: any, layerID: any, type: any, verticesCoords: any, catalog: any, family?: LineFamily): {
         updatedState: any;
         area: undefined;
     };

package/dist/types/react-planner/class/surface.d.ts

@@ -1,7 +1,27 @@
+/** Free-standing polygons — patios, lawns, decking. Drawn corner by corner
+ *  with the same lines/vertices as walls, but kept out of the wall graph by
+ *  `utils/line-family`, so laying one over a room neither welds it to the
+ *  walls it crosses nor takes the room's floor over.
+ *
+ *  Snapping is the deliberate exception: a surface *should* be able to land
+ *  exactly on a wall corner or run flush along a wall — it just must not
+ *  become attached to it. So the whole scene is offered as snap targets, the
+ *  same set the wall tool uses.
+ *
+ *  Drawing: click each corner. Click back on the first corner to close the
+ *  polygon, or leave the tool (Esc, double-click) once three corners are down
+ *  and `finishDrawingSurface` closes it for you.
+ */
 declare class Surface {
     static selectToolDrawingSurface(state: any, sceneComponentType: string): {
         updatedState: any;
     };
+    /** Snap targets for the whole scene, plus the horizontal/vertical guides
+     *  through `(x, y)` — exactly what `Line.beginDrawingLine` builds. This was
+     *  simply missing before: `snapElements` stayed empty for the surface tool,
+     *  so every `nearestSnap` downstream had nothing to find and the tool
+     *  behaved as if snapping were off. */
+    private static anchorSnaps;
     static beginDrawingSurface(state: any, layerID: string, x: number, y: number): {
         updatedState: any;
     };
@@ -11,5 +31,19 @@ declare class Surface {
     static endDrawingSurface(state: any, x: number, y: number): {
         updatedState: any;
     };
+    /** Leave the tool keeping what has been drawn, by committing the edge from
+     *  the last clicked corner back to the first.
+     *
+     *  This is what Esc and the double-click go through. The outline on screen
+     *  is already drawn closed while the tool is live, so throwing it away is
+     *  never what leaving the tool means — but only clicked corners count, not
+     *  wherever the cursor happens to be resting.
+     *
+     *  Under three corners there is no polygon to keep; `finished: false` says
+     *  so, and the caller falls back to a real rollback. */
+    static finishDrawingSurface(state: any): {
+        updatedState: any;
+        finished: boolean;
+    };
 }
 export default Surface;

package/dist/types/react-planner/class/vertex.d.ts

@@ -1,5 +1,10 @@
+import { type LineFamily } from "../utils/line-family";
 declare class Vertex {
-    static add(state: any, layerID: any, x: any, y: any, relatedPrototype: any, relatedID: any): {
+    /** `family` is what the caller is about to attach here. A coincident vertex
+     *  is only reused when it belongs to the same family, so a surface corner
+     *  dropped on a wall corner gets its own vertex and the two graphs stay
+     *  separate. Omit it to reuse any coincident vertex (the old behaviour). */
+    static add(state: any, layerID: any, x: any, y: any, relatedPrototype: any, relatedID: any, family?: LineFamily): {
         updatedState: any;
         vertex: any;
     };

package/dist/types/react-planner/hooks/usePlanThumbnail.d.ts

@@ -0,0 +1,13 @@
+/**
+ * Keeps a plan thumbnail up to date, handing each new one to `onReady`.
+ *
+ * Capture is deliberately *ahead* of unload, not during it. `beforeunload`
+ * can't await anything, and a multi-hundred-KB data URI is far past what
+ * sendBeacon or fetch({ keepalive: true }) will carry (~64KB), so there is no
+ * way to both build and ship an image once the page is going away. Instead we
+ * capture on an idle timer and again when the page is hidden — by the time the
+ * tab actually closes, the server already has a current image.
+ */
+export declare function usePlanThumbnail(onReady?: (img: string) => void): {
+    ensureScreenshot: (force?: boolean) => Promise<void>;
+};

package/dist/types/react-planner/models.d.ts

@@ -173,6 +173,18 @@ declare const Catalog_base: Record.Factory<{
 }>;
 export declare class Catalog extends Catalog_base {
     constructor(json?: any);
+    /**
+     * Build a record of `type` with its catalog defaults filled in.
+     *
+     * A type the catalog doesn't have is normally a caller's mistake, but not
+     * always: duplicating something already in the plan goes through here, and a
+     * plan can outlive the catalog it was drawn with (see
+     * `catalog/unknown-element.tsx`). So when `options.prototype` says which kind
+     * of record to build, one gets built — carrying whatever properties came in,
+     * since there are no defaults to merge — rather than taking the planner down
+     * over a copy of something already on screen. Without that hint there is
+     * nothing to construct, and it still throws.
+     */
     factoryElement(type: string, options: any, initialProperties?: Map<string, any>): Line | Hole | Area | Item;
 }
 declare const HistoryStructure_base: Record.Factory<{

package/dist/types/react-planner/sidebar/panel-element-editor/editor-ui.d.ts

@@ -34,6 +34,57 @@ export interface EditorAction {
 export declare const ActionRow: ({ actions }: {
     actions: EditorAction[];
 }) => import("react/jsx-runtime").JSX.Element;
+/**
+ * One entry of a catalog element's `textures` map, as far as the picker cares.
+ * Structural on purpose — the repeat scales matter to the renderers, not here.
+ */
+export interface MaterialTexture {
+    name: string;
+    uri: string;
+    tag?: string[];
+}
+interface MaterialPickerProps {
+    textures: Record<string, MaterialTexture>;
+    /** Currently applied key, or `"none"`. */
+    value: string;
+    onChange: (key: string) => void;
+    /** Heading, rendered only alongside the picker so it can't be left stranded
+     *  above nothing when the element has no materials. */
+    label?: string;
+}
+/**
+ * Browse a catalog element's materials.
+ *
+ * Shared by the wall and area editors because they browse the same library —
+ * the catalog hands floors and walls one `textures` map, so whatever makes it
+ * navigable for one has to be there for the other. Categories come from the
+ * materials' own tags in the order the catalog lists them, so no vocabulary is
+ * baked in here.
+ */
+export declare const MaterialPicker: ({ textures, value, onChange, label, }: MaterialPickerProps) => import("react/jsx-runtime").JSX.Element | null;
+interface FinishPickerProps {
+    /** Paint colour, as `#RRGGBB`. */
+    color: string;
+    onColorChange: (color: string) => void;
+    textures: Record<string, MaterialTexture>;
+    /** Currently applied texture key, or `"none"`. */
+    texture: string;
+    onTextureChange: (key: string) => void;
+    /**
+     * Rendered under the palette on the Colors tab. Areas put their hatch
+     * patterns here; walls have none, and pass nothing.
+     */
+    patterns?: React.ReactNode;
+}
+/**
+ * How a surface's finish is chosen: paint on one tab, materials on the other.
+ *
+ * Walls and areas both answer the same question here — what is this surface
+ * covered in — so they get the same two tabs over the same palette and the same
+ * material library. What differs is what else lives under the palette, which
+ * comes in as `patterns`.
+ */
+export declare const FinishPicker: ({ color, onColorChange, textures, texture, onTextureChange, patterns, }: FinishPickerProps) => import("react/jsx-runtime").JSX.Element;
 /** Catalog thumbnail, falling back to a neutral tile when there is no image. */
 export declare const ElementPreview: ({ imageUri, alt, }: {
     imageUri?: string;

package/dist/types/react-planner/sidebar/panel-element-editor/paint-palette.d.ts

@@ -0,0 +1,6 @@
+interface PaintPaletteProps {
+    value: string;
+    onChange: (color: string) => void;
+}
+export declare const PaintPalette: ({ value, onChange }: PaintPaletteProps) => import("react/jsx-runtime").JSX.Element;
+export default PaintPalette;

package/dist/types/react-planner/utils/index.d.ts

@@ -5,9 +5,10 @@ import * as SnapUtils from "./snap";
 import * as SnapSceneUtils from "./snap-scene";
 import * as history from "./history";
 import * as ObjectUtils from "./objects-utils";
+import * as LineFamilyUtils from "./line-family";
 import IDBroker from "./id-broker";
 import NameGenerator from "./name-generator";
-export { GeometryUtils, GraphInnerCycles, MathUtils, SnapUtils, SnapSceneUtils, history, IDBroker, NameGenerator, ObjectUtils, };
+export { GeometryUtils, GraphInnerCycles, MathUtils, SnapUtils, SnapSceneUtils, history, IDBroker, NameGenerator, ObjectUtils, LineFamilyUtils, };
 declare const _default: {
     GeometryUtils: typeof GeometryUtils;
     GraphInnerCycles: typeof GraphInnerCycles;
@@ -18,5 +19,6 @@ declare const _default: {
     IDBroker: typeof IDBroker;
     NameGenerator: typeof NameGenerator;
     ObjectUtils: typeof ObjectUtils;
+    LineFamilyUtils: typeof LineFamilyUtils;
 };
 export default _default;