# Panel docking `craft_ui::docking` lets the user arrange an app's panels: tab groups, docks with columns, splits, floating windows and iconic columns. craft-ui owns the layout model, the renderer and the gestures. The app owns panel contents, commands, document state and where layouts are saved. Office apps that draw their own document with a few task panes beside it use [`craft_ui::panes`](ui-panes.md) instead. ## Arrangements One model serves every app. What differs between apps is the default layout and a few `DockStyle` settings. An app builds its style with `DockStyle::from_ui`, `from_visuals` or `default` and then sets fields; new fields can be added, so the struct has no literal form outside the crate. | Arrangement | Layout | Style settings | Apps | |---|---|---|---| | Docks beside a canvas (the defaults) | `Node::Dock`s on the window's start and end edges. A dock has columns; a column has stacked groups and can collapse to icons. Frames (tab groups and splits) fill the space between the docks. | `new_dock_zones` on | Creative apps with a canvas and panel docks | | A split tree of tab groups | `Split`s and `Tabs` only. | `side_edge_zones`, `maximize_item`, `close_others_item`, `command_press_floats`, `float_hint`, `wheel_selects_tabs`, `middle_click_closes_tabs` on, `new_dock_zones`, `float_on_empty_drop` and `title_bar_docks` off; menu labels such as "Undock Panel" set on `float_label`, `float_group_label` and `close_group_label` | Apps whose whole window is frames | Sides are logical: `Side::Start` is the left edge, or the right edge when `DockStyle::right_to_left` is set. egui has no app-wide direction, so the app sets it from its locale. Right to left, tab strips also mirror: the first tab is rightmost, the group header and drag bar are at the left, and drop insertion slots follow. Accordion headers and floating title bars (`chrome::TitleBar`, through `ChromeStyle::right_to_left`) mirror too. Frame splits keep their sides. ## Model `Layout

` holds an optional root `Node

` and a list of `Floating` windows. | Node | Holds | |---|---| | `Tabs` | A tab group: panels and the active index. | | `Split` | Two children, horizontal or vertical, and a size: a ratio, a fixed first size or a fixed second size. A moved divider keeps the mode: a fixed side stores its new size in points, a ratio its new ratio. | | `Stack` | Accordion entries, each open or closed, with an optional height. | | `Dock` | A side and its columns. A `Column` has `Group`s, a width, and `iconic`. | A `Floating` window holds a tree like the docked layout's (`root`: splits, tab groups and accordions, no docks), a rect, an optional native-window rect with the monitor it is on, and `minimized`. Its `id` names the window across panel moves (see [Native windows](#native-windows)). `Floating::single` makes a window with one group, `Floating::new` one with a tree, and `Floating::stack` one with groups stacked top to bottom (a vertical split sized by the groups' heights, as an app's own stacked layouts migrate); `panels()` and `contains()` read it. Each of these calls makes a new window with a fresh `id`. Build a layout once and keep it, or give its windows ids with `with_id`: a layout built anew each frame, as an unsaved default layout might be, otherwise opens new OS windows each frame and loses their drags and places. Debug builds log a warning when native windows are replaced by new ones with the same panels three frames running. Saved layouts keep loading: a window stored as one group (v1) or as a stack of groups loads as that group or as a vertical split of the stacked groups, sized by their heights. `P` is the app's panel id: stable, not localized, `Clone + Eq + Hash`. The renderer also needs `Debug + Send + Sync + 'static`. A panel occurs at most once in a layout. Change a layout only through `Action`s: ```rust use craft_ui::docking::{Action, Floating, Layout, Node, Placement}; let mut layout = Layout { root: Some(Node::Tabs { panels: vec!["layers", "properties"], active: 0 }), floating: vec![Floating::single(vec!["brushes"], 0, [40.0, 80.0, 240.0, 300.0]).with_id(1)], }; layout.apply(Action::Move { panel: "brushes", anchor: "layers", placement: Placement::Tab { before: Some("properties") }, })?; # Ok::<(), craft_ui::docking::DockError>(()) ``` - `Move`, `MovePanel`, `Float` and `Close` act on one panel. `MoveGroup`, `MoveColumn` and `MoveWindow` move a group, a dock column or a floating window, named by any panel in it. - `Open` reveals an absent panel as the last tab of its `anchor`'s group. Without an anchor it becomes the root of an empty layout, else joins the first dock group that accepts tabs and is shown, not minimized or in an iconic column (the end-side dock's first), else gets a new frame a quarter wide at the right edge of the docked area. `OpenAt` takes any placement. - A `Target` is `At { anchor, placement }`, `Float { rect }` or `NewDock { side }`. - A `Placement` is a tab position, a split zone, a new group above or below (with an optional preferred `height`), a new column, or a new frame on an outer edge. - Containers take different placements: a dock column takes groups and columns, not splits. `Placement::for_zone(layout, anchor, zone, right_to_left)` maps a left, right, top, bottom or center zone onto what the anchor's container takes: a split in the frame tree, a new column on that side or a new group above or below in a dock. A floating window takes splits as the docked layout does; `Placement::Group` on a floating anchor splits its group above or below. - A side split zone puts what moves in a new half-size split of the anchor's frame, and no other frame changes size. The new split has its own divider. `Placement::SplitSized` sizes that split instead (`size`) and resizes the enclosing split whose divider runs along the anchor frame's side (`outer`), so the frames beyond that divider give the new frame its room. - Other actions select, minimize, collapse to icons, resize splits (`ResizeSplit` in the docked layout, `ResizeWindowSplit` in the floating window holding a panel), columns and groups, and move a floating window to its own OS window (`SetNative`, and `SetMonitor` for the monitor it is on, feature `native-windows`). - A move between windows (docked to floating, floating to floating) is one action, checked as a whole like any other. Every action checks the whole result before it commits. A bad target, a duplicate id, a stale split path or invalid geometry returns a `DockError` and leaves the layout unchanged. The source panel is never lost. `apply`, `apply_with_permissions` and `apply_all` return the panels the actions closed, so the app can release their state; `closed_by` lists them before applying. `Permissions` limit what may happen to a panel: `movable`, `floatable`, `closable`, `accepts_tabs` and `accepts_splits`. `apply_with_permissions` enforces them for every action, whoever issues it. `Permissions::PROTECTED` keeps a canvas docked and open and takes neither tabs nor side splits; a group dropped on it floats there. An app that opens panels beside its canvas uses `Permissions { accepts_splits: true, ..Permissions::PROTECTED }`. ## Workspace `Workspace

` is what an app saves: the layout, the hidden panels with where each one goes back, an optional saved arrangement for Reset, and `locked`. | Method | Does | |---|---| | `apply`, `apply_all` | Apply actions all or none, with the app's permissions. Closed panels are recorded in `hidden`. While `locked`, moving, floating and closing are refused; `SetNative`, which records the OS windows, still applies. | | `set_visible(panel, visible, fallback, permissions)` | Hide a panel that may close, or show it at its recorded place, else as `Open` beside `fallback`, or where `Open` without an anchor puts it. A group or window closed one panel at a time comes back as one group as its panels are shown again. | | `reconcile(registered, permissions, default)` | Fit a loaded workspace to the panels the app has now. Unknown panels move to `hidden`, so they come back when registered again. A registered panel that cannot close, such as the canvas, is always shown. | | `reset(default)` | Return to the saved arrangement, or to `default` for a built-in workspace. | | `validate` | Check a loaded workspace before use. | With the `serde` feature, `Workspace`, `Layout` and `Action` serialize. Files without a version are v1 and load unchanged. craft-ui does not choose where files go; the app does. ## Rendering `DockArea::new(id).show_content(ui, &layout, &style, &mut content)` draws a layout snapshot and returns a `DockOutput`. It does not change the layout. The app applies `output.actions` through its own command path, so pointer, keyboard and control commands share one path. `DockContent

` is the app's adapter. It draws each panel body and gives its label, icon, permissions, size limits, dock column heights, preferred floating size, panel menu and group header. The group header sits at the end of the tab strip; `group_header_width` gets the strip width, so a header that draws its own tabs can size them to the room left. An icon is an image (`icon`), or drawn in code by `paint_icon`, which gets a painter, the icon rect and the tint color and returns true when it painted. Panel bodies keep a stable egui id when they move, so widget memory survives. `DockOutput` also has: - `focused`: the panel the user focused this frame: a clicked tab, a drop, or a press of any pointer button in a panel body (protected panels included) or in the group header, which focuses the group's shown panel. Commands, `raise_panel` and workspace resets never set it; a host that tracks the last focused panel clears it when a reset or command hides, closes or moves that panel. - `events`: requests outside the layout, such as `DockEvent::ToggleMaximize` (`maximize_item`) and `DockEvent::ToggleAutoCollapse` and `DockEvent::FlyoutChanged { panel }` (docks): the flyout opened, switched or closed (`None`). It comes once per change, whatever made it: an icon, Escape, a press outside, a raised panel, `open_flyout` or `close_flyout`. - `error`: a rejected gesture. Builder options on `DockArea`: | Option | Use | |---|---| | `maximized(panel)` | Maximize Frame: that frame fills the area. | | `hide_panels(HidePanels)` | Hide panels for Tab and Shift+Tab. Protected panels stay. | | `auto_collapse_iconic(on)` | Close a flyout on Escape or a click outside (default on). | | `raise_panel(panel)` | Raise a panel's floating window, or open its flyout, this frame. It moves no keyboard focus and does not set `DockOutput::focused`. | | `locked(on)` | Draw `Workspace::locked`: every panel gets `Permissions::locked`, so nothing starts a move, float or close the workspace would refuse. | | `blocked_rects(rects)` | App overlays that docking gestures must ignore. | | `float_bounds(rect)` | Where floating windows, flyouts and drag ghosts may go (default: the whole viewport). Pass the viewport below a title bar drawn under a transparent OS title bar, so no floating window sits where a press moves the app window. | `DockStyle::close_menu_items` and `DockStyle::close_button` hide the built-in Close menu items and the floating window ×. They hide controls only: a panel that stays `closable` still closes by the app's own Close items and commands. `DockArea::chrome_has_focus` tells whether keyboard focus is on docking chrome (any control a `Hit` names) rather than on a panel body. Focus follows only the user's input: a tab keeps keyboard focus until a command or a workspace reset hides, closes or moves its panel, and then gives it up. A divider or a floating window's resize grip holds focus only while the pointer drags it, so the app's shortcuts and canvas arrow keys work right after; one reached with Tab or F6 keeps its focus, and arrow keys resize it. Hovering focuses nothing. `begin_drag` hands a drag that started in the app's own chrome to the area. `docking::chrome` has the floating frame, the title bar and `drop_preview` (the drag ghost and region preview docking and `craft_ui::panes` both draw) for apps that draw their own windows. ## Tab strips Tabs start at their natural width, wide enough for the panel's name. When the strip is too narrow, the widest tabs shrink first, to a common width; tabs whose names fit that width keep their natural width. A tab narrower than its name cuts the name with "…" and shows it in full as a tooltip. Shrunk tabs keep their hit areas, drag and keyboard behaviour, and accessibility labels with the full names. No tab shrinks below `DockStyle::min_tab_width`: by default about three characters and the "…" plus the tab's padding, 54 pt at the 12 pt font. Only when the tabs at that width do not all fit do the rest go to the "…" button at the end of the strip, whose menu lists the hidden panels; choosing one makes it active. The active tab is always shown, in its logical place, and the others take the remaining room in their order. An active tab with less room than its minimum width, or a lone tab wider than the strip, is cut the same way. The drag bar always keeps its reserved width: tabs shrink, then overflow, before it narrows, and only a strip narrower than the group header plus the bar shrinks it. A tab dropped on the "…" button goes to the end of the group. ## Floating size A panel or group floated by a drag, a menu or a command without a rect takes its content height: the title bar, the tab strip and the height the active panel's content used when it was last drawn (the content ui's `min_rect`), at least 120 points. The most it takes is the height of `DockContent::floating_size`, or 320 points for a panel leaving a dock or frame and a group leaving a dock. A short panel therefore floats as a short window. Content that reaches the bottom of its body (a panel that allocates its whole rect) has no height of its own: it floats at the `floating_size` height, else at 320 points. A panel's width is its `floating_size` width, else its docked width; a group keeps its docked width. A flyout fits its content the same way, without the title bar. - A panel the area has not drawn floats at the `floating_size` height, else the docked height capped at 320, or at a `FloatSpace::with_panel_size` size for commands. - A group from a frame without a `floating_size` keeps its frame size. A dock column of several groups floats at the tallest `floating_size` height, else its column height capped at 320. - A rect from a command and a window the user resized keep their size; floating windows are not refitted while open. - Docked layout does not change: a column's last group still fills the column. ## Gestures - A tab drags one panel. A group's drag bar (the space beside its tabs) or its top border drags the whole group. A column bar drags a column. A floating window's title bar drags the window; with `title_bar_docks` a release over a target docks the whole window there, else it only moves. While the drag highlights a drop target, the window is drawn at 75% opacity so the target shows through it; over empty space, and once the drag ends, it is opaque. A native window moved by its only tab or tab row fades the same way. - Inside a floating window, tabs and drag bars drag and dock as they do in the docked layout, into any window. A drag bar or border of a window's only group takes the whole window along, so, like the title bar, it looks through the window: the groups, docks and windows behind it take the drop while the pointer is still inside it. In a window of several groups, the other groups stay targets. Its groups split, join and resize like frames, with dividers and four-way handles (`Divider::WindowSplit` and `Divider::WindowIntersection`, named by the window's first panel). Double-clicking the title bar minimizes the window to its title bar, or to the tab strip of its only group; so does double-clicking that group's strip. The group menu's float item floats one group of a window that has several. Closing the window closes its panels; each reopens where it was while the window or its neighbour in it is open, else in a window at the window's last rect. - A movable floating window resizes from every edge and corner. The top edge and corners are a 4 pt band above the title bar (`chrome::RESIZE_BAND`), so they take no moves and no clicks on the title bar's buttons. A resize keeps the opposite edges in place and stays within the size limits and the screen. A focused resize handle moves its edge 8 pt per arrow key. - Over a group (a frame, a dock column's group or a floating group), the pointer's place decides: - The tab strip joins the group's tabs at the insertion slot under the pointer. - In the body below the strip, the outer `DockStyle::side_zone_fraction` (one third) of its width from the left or right edge, or of its height from the top or bottom edge, docks beside the group on that side. Where two sides meet, at a corner, the side the pointer is relatively nearer wins. - The middle third joins the group's tabs. - A group that takes no tabs, such as a protected canvas, takes nothing on its strip, and its body has no middle: every point docks beside it on the relatively nearest side. - In the docking profile (`new_dock_zones` without `side_edge_zones`), the body of a frame or floating group that takes no tabs takes nothing, whatever its `accepts_splits`: a release there is a release over no target, so a floating window stays floating and a docked panel or group floats as `float_on_empty_drop` says. Only the bands along borders (below) dock beside it, as in Adobe apps, whose document area is no drop zone. A dock column's group keeps its sides. - Beside a frame is a split of that frame. Beside a group in a dock column, the top and bottom stack a new group above or below it, and the left and right make a new column on that side. A group dragged to an edge of its own column, such as the window edge of the column it heads, makes a new column there, as one of its tabs would; when it is the column's only group, nothing changes. - A frame too narrow or short for two halves of `DockStyle::min_pane` still splits when the frames beyond it can give the room, as they do for a dragged divider. When they cannot, the frame keeps its size and the new frame takes the width (or height) the moved panels have now, at least its minimum, from the frames beyond the frame's divider on that side (`Placement::SplitSized`). When those have no room either, that side joins the frame's tabs instead, or takes nothing when the frame takes no tabs. The gap between two frames is no target. - Bands along borders come before the group zones. Each is centred on its border where the pointer can reach both sides: | Band | Drop | Field (default) | |---|---|---| | The seam between two stacked groups of a dock column | A new group between them | `seam_band` (28 pt) | | Each edge of a dock column | A new column on that side | `column_edge_band` (28 pt) | | The docked area's left or right edge without a dock, and an empty dock | A new dock | `new_dock_band` (28 pt) | | The edge area's top and bottom in `drop_edges` (all four sides with `side_edge_zones`) | A new frame along that whole side, a quarter of the edge area | `edge_band` (28 pt, 8 pt with `side_edge_zones`; at most a quarter of the edge area) | Where a band overlaps a group's outer third, both mean the same side. Without `side_edge_zones`, a band reaches only 4 pt past its line into a tab strip that takes tabs; the rest of the strip joins. The outer edge band is offered only when every frame keeps its minimum. - The edge area is the root, or the part between the docks. Without `side_edge_zones` it also narrows to the canvas column: where neither side of a side-by-side split is a dock and only one side holds a protected panel, that side. The top (bottom) band also narrows a split of rows to its first (last) row when only that row holds the canvas, so a full-width row below the canvas keeps the bottom band. Side panels in split frames then get no band across the whole window, and the drop wraps only the canvas column. A drop on a narrowed band anchors on the canvas, so `Placement::Edge` narrows the same way when applied; on a band that is not narrowed it anchors on a panel that is not protected. The renderer tries the drop with its own permissions and offers the band only when the drop wraps the panels the band shows. `window.panel.dock` to an outer edge picks its anchor the same way, from the permissions `apply` (or `to_actions`) gets and the area's `FloatSpace` (`with_side_edge_zones` before it has drawn). - `DockStyle::drop_edges` (a `Sides`, all four by default) lists which sides of the layout's outer edge, and of a group that takes no tabs (a canvas) without `new_dock_zones`, take a drop. There a canvas's whole body goes to the nearest listed side; with none listed it takes nothing. In the docking profile the canvas body takes no drop and the outer left and right edges are new docks, so only the outer top and bottom apply. Groups that take tabs keep all four sides. A dock-column app whose palettes dock only at the left and right, as in AutoCAD, sets `Sides::NONE` with `new_dock_zones` on. Not used with `side_edge_zones`. - With `side_edge_zones` (the split-tree arrangement), a frame's zones are a picture frame instead: trapezoids along the four edges of the body below the tab strip, all four the same depth, `docking::SIDE_EDGE_ZONE_DEPTH` (40 pt), or a quarter of the body's smaller side when that is less, so every frame keeps a center. A dock column's groups take the same depth. `drop_zone` and `resolve_drop` give these zones to hosts that draw their own frames. - A host that resolves drops over its own groups calls `resolve_drop_by` with `DockStyle::zone_rule()`, so its zones and previews match the dock area's in either profile. `resolve_drop` always gives the split-tree zones. - A dragged divider grows the frames that touch it on one side, up to their maximums. On the other side the frame touching it shrinks to its minimum, then the next frame along the same axis, and so on: the divider stops when every frame on that side is at its minimum. Frames side by side across the axis shrink together, and the next frame gives way once one of them is at its minimum. The line of frames ends at a split across the axis or at a dock; every other frame keeps its size. Dividers between stacked panels and between the groups of a dock column work the same way. Where a divider ends on another divider, a four-way handle (`Divider::Intersection`) moves both. - Every frame has the same minimum, `DockStyle::min_pane` (plus its tab strip), unless its panels ask for more through `PanelLimits::min`. Frames have no maximum unless every panel in them asks for one through `PanelLimits::max`: a panel without a maximum lifts the maximum of the panels it joins. - A dock column stacks its groups top to bottom. A minimized group shows only its tab strip, and a group the user resized keeps that `Group::height`. A group the user never resized (`height` is `None`) takes the default height its panels ask for through `DockContent::dock_heights`. Groups whose panels ask for a `fill` height share the rest of the column, and groups whose panels ask for no heights take their minimum. When no group asks for a fill, the groups without heights share the rest, and when every open group has a height, the last one fills the column. In a short column the groups at their default give way first, down to their `compact` heights, so the filling group gets its `fill` height. When the column is still too short, every group gives way down to its minimum, and past that the column scrolls. Defaults give way nearest the filling group first: one is at its compact height before the next gives way. Towards the minimums, groups give way in proportion to their room. A group takes the largest default, compact and fill height of its panels. All three are body heights, without the tab strip, like `PanelLimits`. - Drop previews have four shapes, the same for tab and group drags: - A drop beside something shows the rect the dragged panel, group or column will take, at its real position and size, as a 2 pt accent outline with a light fill. The renderer applies the drop to a copy of the layout and lays it out with the code that draws it, so the rect is the one the panel's group gets on release: the new frame for a split (including `Placement::SplitSized`), the new group for a stack above or below a dock group or on a seam, and the whole column, bar included, for a new column between columns or beside a dock group's side. - A drop on a band along the layout's outer edge shows a `DockStyle::drop_line_width` (4 pt) accent line along that edge: the new-dock band, the window edge of a dock's outermost column, and the outer edge band (`Placement::Edge`), whose line spans the edge area it wraps. A drop between the icon groups of an iconic column shows the same line there. - A drop that joins a group shows the same outline and fill around the whole group, and on its strip the 2 pt insertion marker. - A drop that floats shows the floating rect. A drop that would leave every panel where it is, changing only sizes, shows nothing and changes nothing: a lone group dropped beside the group it already borders, or a frame's tab on the layout edge the frame already holds. Split sizes, column widths, group heights and window rectangles are not compared, and a run of splits along one axis is the same however it nests. A group drag also shows its ghost at the pointer. With `side_edge_zones`, a drag over a group instead outlines each of its zones that a drop would change something in (the side trapezoids, the center rectangle and the tab strip; `zone_shape` gives the outlines) and fills the zone under the pointer. Sides the group does not take, by its permissions or because a split leaves no room, are not drawn; nor is the center of the group a tab comes from. A drop there that the zones do not show, such as the outer edge band, fills the region it takes, and dock drops show the line along the edge they dock to. Escape or losing window focus cancels a drag. - A drag in progress (a tab, group, column, window bar, native window bar or divider, in any of the app's windows) also ends when the layout passed to the area is not the one it drew last frame, with or without its returned actions applied: the app switched workspaces, ran Reset or changed the layout by command. Sizes and rectangles are not compared, so an app may clamp a moved window or adjust a split during the drag. Nothing is restored from before the drag; windows go where the new layout has them. `cancel_drag` ends the area's drags at any other time. A native window moved by the compositor (`ViewportCommand::StartDrag`, as on Wayland) is not the area's drag: it ends when the user releases the button. - With `float_on_empty_drop`, a release over no target floats what moves at the pointer, such as a panel dropped on a protected canvas. Without it, that release cancels the drag and nothing moves: the gap between two groups, a menu bar or a status bar is no target. A release outside the app window floats in both cases. - Ctrl (⌘ on macOS) held at the drop floats it wherever it lands. With `command_press_floats`, the key held when a tab drag of a frame starts is enough. With `float_hint`, a hint under the pointer names the modifier while a drag offers a docking target: `float_hint_label`, where `{key}` becomes ⌘ or Ctrl. - Double-click a tab or drag bar to minimize a group to its strip. - Right-click a tab for its menu, or a drag bar for the group menu; Enter or Space on a focused drag bar opens it too. A left click on the drag bar only focuses it. - With `DockStyle::wheel_selects_tabs`, the mouse wheel over a tab strip selects the next or previous tab. With `middle_click_closes_tabs`, a middle click on a closable panel's tab closes it. - A column's »/« button collapses it to icons, one icon per panel with a separator between groups. Widen an iconic column to show panel names. Click an icon to open its group as a flyout on the canvas side. Drag an icon to move its panel, or an icon group's top edge (the separator line above it) to move the group. ## Commands With the `serde` feature, `DockCommand

` is the shared control vocabulary. The app puts the command id under `"command"` in the params and deserializes them. craft-ui has no `serde_json` dependency. ```rust,ignore let mut params = params.clone(); params["command"] = json!(id); let command: DockCommand = serde_json::from_value(params)?; if command.is_app_owned() { return app.workspace_command(command); } let space = float_space(ctx, DOCK_ID).unwrap_or_else(|| FloatSpace::new(ctx.content_rect())); let closed = command.apply(&mut app.workspace, style.right_to_left, &space, |panel| app.permissions(panel))?; ``` | Id | Params (`?` is optional) | |---|---| | `window.panel.layout` | `{action}`: a serialized `Action` | | `window.panel.move` | `{panel, anchor, zone?, before?, group?, placement?}` | | `window.panel.float` | `{panel, x?, y?, width?, height?, group?, column?}` | | `window.panel.dock` | `{panel, anchor?, zone?, before?, group?, column?, side?}` | | `window.panel.activate`, `.close`, `.closeGroup`, `.closeOthers` | `{panel}` | | `window.panel.minimize` | `{panel, minimized?}` | | `window.panel.iconic` | `{panel, iconic?}` | | `window.panel.window` | `{panel, native?}` | | `window.workspace`, `.new`, `.delete` | `{name}` | | `window.workspace.reset`, `ui.dock.reset` | `{}` | | `window.workspace.lock` | `{locked?}` | | `ui.dock` | `{action}`, or `{operation, …}` | - `zone` is `tab`, `center`, `left`, `right`, `top`, `bottom`, `above` or `below`. `before` names the tab to insert before; `null` appends. `left`, `right`, `top` and `bottom` follow `Placement::for_zone`, so beside a docked panel they make a new column or group. `apply` and `to_actions` take the layout's `right_to_left` for that. - `group` moves the panel's whole group; `column` moves its dock column, or its whole window when it floats. `side` is `Start` or `End`: what moves becomes a new last column of that dock, or a new dock; when it already is that dock's last column, the command does nothing. - `window.panel.dock` with `left`, `right`, `top` or `bottom` and no `anchor` or `side` makes a new frame on that outer edge (`Placement::Edge`), wrapping what a drag to that edge would (see the edge area above). A hidden panel is shown first. - Showing a panel (`activate`, `dock` without a destination, `ui.dock` `open`) restores a hidden panel's place; a panel never laid out opens as `Open` without an anchor does. - `window.panel.float` without a rect floats what it moves at the size a drag floats it at (see Floating size). It goes inside the dock area, 24 points from its top-left corner, so it stays clear of the menu bar. The area records that geometry in a `FloatSpace` each frame; `float_space(ctx, id)` reads it and `apply` and `to_actions` take it. Before the area has drawn, `FloatSpace::new(area)` floats a panel at 260x320 and a group or column at its column width by 320. `FloatSpace::with_panel_size(panel, size)` gives a panel the area has not drawn (a hidden panel, a headless run) the host's own size; a size the area recorded wins. `x`, `y`, `width` and `height` replace the matching values, and a group or column that is already a whole floating window keeps its rect. - Without a value, `minimized`, `iconic` and `locked` toggle. - `ui.dock` operations are those of LightCraft, PDFCraft, CADCraft and SoundCraft: `open`, `close`, `activate`, `float {rect}`, `moveFloating {rect}`, `move {target, zone?, before?}`, `setStackOpen {open}`, `resizeStack {height}` and `resizeSplit {path, size}`. `rect` is `[x, y, width, height]`. `to_actions` returns the actions a command makes without applying them. `apply` applies them all or none and returns the panels it closed, so the app can release their state. Showing a hidden panel and Lock change the workspace directly. Named workspaces and Reset belong to the app: `is_app_owned` is true for them and `apply` refuses them. `DockCommand::IDS` lists every id for the app's command registry. App-specific aliases stay in the app. ## Native windows With feature `native-windows`, on a backend with egui viewports (`!ctx.embed_viewports()`, eframe on desktop), every floating window opens in its own OS window: a Ctrl/Cmd-drag, Undock Panel and Undock Panel Group, every other drop that floats, and the floating windows of a restored layout. A window still in-window opens over its place in the app window (the main viewport's `inner_rect.min` plus its rect). A window with a panel whose `DockContent::allow_native` returns false (it returns true unless the app overrides it), or that is not floatable, stays in-window. Floating windows get no taskbar or Alt-Tab entry (`with_taskbar(false)`). On Wayland floating windows stay in-window: the compositor reports no window positions, so a native window could not dock again by drag or reopen where it was. Their `native` rects are kept, and the same layout opens native windows on X11, macOS and Windows. The dock area takes Wayland to be the backend when `WAYLAND_DISPLAY` or `WAYLAND_SOCKET` is set (winit's rule) and the main window has never reported its `outer_rect`; an app that forces X11 in code gets native windows from the first frame. `DockArea::native_windows(bool)` overrides the choice either way. - **Identity.** `Floating::id` names the OS window, so a window keeps it when its panels change, including when its first panel moves out. `Floating::new` draws a fresh id and `Floating::with_id` sets one. A saved layout stores every window's id and loads with unique ids: a window saved without an id, or with one an earlier window took, gets a fresh one. A window that merges into another takes the receiver's id, and a whole window that moves (floated again, or its only group dragged) keeps its own. - **Kind and level.** `DockContent::window_kind` sorts panels into palettes (`WindowKind::Palette`, the default) and viewers (`WindowKind::Normal`), such as a video monitor on a second display. A window holding any `Normal` panel is a normal window, whichever of its tabs shows; the rest are palettes. - Palettes stay above other windows (`WindowLevel::AlwaysOnTop`), so clicking the document does not bury them. They stay shown while the app is in the background, so files dragged from another app reach them and an OS sheet attached to one stays open. While none of the app's windows has focus they take `WindowLevel::Normal`, so they do not cover other apps (on Windows `WindowLevel::AlwaysOnBottom`: there `Normal` would put them in front of the app the user switched to), and they go back to `AlwaysOnTop` when one has it again. The app counts as in the background after 250 ms without focus, so focus moving between its own windows changes nothing. The level is sent only when it changes. - Normal windows have `WindowLevel::Normal` and stay shown while the app is in the background. They stack with the main window by focus, below every palette; a drag over a normal window that lies behind the main window targets the main window where the two overlap, and the normal window outside the main window. - Like palettes, normal windows have no taskbar entry; they come forward with the app instead. When one of the app's windows gains focus after none had it for 250 ms, the main window and each normal window get `WindowLevel::AlwaysOnTop` and then `WindowLevel::Normal`, one window per frame, in their focus order from back to front. They keep their order, nothing takes focus, and the window the user activated is raised last, so it stays in front. The focus order counts a press in the main window as focusing it, since the window system raises it then. The main window is left at the normal level, so an app that keeps its main window always on top should not use normal windows. On Windows the toggle puts the window in front of every window that is not topmost, without activating it; on X11 the window manager raises a window as it takes `_NET_WM_STATE_ABOVE`. egui 0.36 cannot make the main window a native window's owner, which on Windows would bring the window forward with the main window, and `ViewportCommand::Focus` would take focus. On macOS nothing is raised: activation from the Dock or the application switcher brings all of the app's windows forward, and a click brings the clicked window alone, as with the app's other windows. - **Bar.** Each window has a bar at the top, 18 points high, in the floating title bar's style: the title (the shown panel of its first group) and ×. Dragging the bar moves the window. On Wayland, where a window cannot be placed, the bar hands the move to the compositor. On Windows and Linux the OS frame is off. On macOS the frame stays, with its title bar and buttons hidden, for its resizing, rounded corners and standard window shadow. The dock area paints no shadow of its own around a native window. - **The ×.** Its place is set in `render/native.rs` (`MACOS_CLOSE`, `OTHER_CLOSE`): the glyph's inset from the top and trailing edges, its size, and how far the hit area reaches past the glyph on each side. On macOS the 9 pt glyph sits where macOS puts the close button of its own windows: centered in the bar, its trailing side 8 pt in. AppKit's corner resize area covers the glyph's trailing half and takes presses there, so the hit area reaches 10 pt further toward the leading edge and down to the bar's bottom. Elsewhere the × is an 18 pt square, its trailing side 7 pt in. With `CRAFT_DOCK_DEBUG_CLOSE=1` in the environment, native windows outline the ×'s hit area in red and, on macOS, AppKit's resize areas in orange. - **Resize.** A movable window resizes from its edges and corners. On macOS AppKit does it, with its own areas and cursors. Its corner area reaches about 15 pt into the window along each edge (a 19 pt square, measured on macOS 26) and takes presses before the content sees them. Over AppKit's areas the window sets no cursor of its own, which would flicker with AppKit's. Elsewhere the window resizes from bands 6 pt deep along its edges, and each corner is an L along both edges, 16 pt long and as deep as the edges. The bands leave out the bar's buttons, so the corner's grab runs down beside the ×; elsewhere the top band lies over the bar's drag area. The OS runs the resize from a band (`ViewportCommand::BeginResize`). - **Close.** The bar's × and the OS close request close the window's panels, as the floating window's × does. They reopen from the app's Window menu. A window with a panel that may not close, or in a locked area, has no × and answers the OS close request with `ViewportCommand::CancelClose`. - **Place.** `Floating::native` is the desktop rect of the window's content (egui's `inner_rect`), and the in-window `rect` follows it for builds that draw the window in-window. The content is also the window's origin for drags; only `ViewportCommand::OuterPosition` takes the outer position, which the renderer works out from the reported outer and inner rects. Where the window system puts a new window's frame, not its content, at the place asked for, the window is moved once so its content is there. When the app changes `native` (undo, a workspace reset, a reloaded layout whose ids match), the OS window moves there; a report that differs from `native` while a commanded move has not landed (up to 0.5 s) is ignored. `Floating::monitor` is the monitor holding the window's center, from the list the app passes to `DockArea::monitors` (each a `Monitor { name, rect, scale }` in desktop logical points). egui 0.36 reports no monitors, so an app fills the list from its backend when it can; without one, `Floating::monitor_size` keeps the monitor size egui reports. - **Restore.** Only the windows of a loaded layout (a `native` the session has not shown yet) are restored. A window made this session (a drag out, Undock, a Ctrl/Cmd drop) opens at the rect it was given, only made safe, wherever that is on the desktop. A restored window opens on its saved monitor when one with that name (or else that rect) is connected, moved in proportion if the monitor's rect changed, and moved onto it when too little of its bar lies on a monitor to grab (40 by 9 points). Otherwise it opens on the main window's monitor at the same offset from that monitor's origin, wholly on screen. Without a monitor list, it is clamped onto the main window's monitor, taken from `monitor_size` and the main window's position. Hostile rects are made safe first. With a monitor list, a window whose `native` the app changes, or whose bar drag ends with too little of the bar on a monitor, goes onto the nearest monitor too. - **Mixed scale factors.** Rects are stored in egui points as the window reports them, and `Monitor::scale` is kept but not used. On macOS every window shares one point space, so this is exact. On Windows egui-winit divides each window's physical position by that window's own scale factor, so with monitors at different scales (say 100 % and 150 %) the points of windows on different monitors are in different units. Across such monitors, a restored or app-changed place can land off by the ratio of the scales, and a drop across windows on different monitors can resolve against the wrong point. Same-scale setups are unaffected. - **Shortcuts.** egui gives each OS window only its own input. Key, text, copy, cut and paste events that reach a native window and that none of its widgets used come back in `DockOutput::forwarded_events`, with the modifiers held in that window in `DockOutput::forwarded_modifiers` (egui-winit sends Cmd/Ctrl+C, X and V as `Copy`, `Cut` and `Paste` without the key). The app feeds them to the shortcut handling it runs on the main window. A window where any widget has keyboard focus forwards nothing, and an Escape that cancels a drag is not forwarded. - **Modal dialogs.** egui's `Modal` blocks input only in the viewport it is shown in. While the app shows one, it passes `DockArea::input_blocked(true)`. Each native window is then drawn under `DockStyle::blocked_dim` (by default the panel fill at 60 %), and its bar, tabs, body and resize edges take no input: its widgets are disabled, the pointer, key, text and scroll events are dropped at the start of its frame, and a layer over its content takes the pointer, so a popup left open takes no click either. It forwards only key releases, so a key pressed before the block does not stay down in the app's shortcuts. It reports no `window_files`, offers no drop targets, starts no move or resize, is not focused by `raise_panel`, and answers the OS close request with `ViewportCommand::CancelClose`. On macOS it is not resizable meanwhile. - *Stacking.* A palette drops to `WindowLevel::Normal` while blocked, so a click on the main window brings it in front of a palette that covers the modal. It stays shown and at that level when the app goes to the background and returns. When the app is activated meanwhile, the main window is raised last, in front of the normal windows and of a palette the user clicked. - *Edges.* Turning blocking on cancels a drag in progress, and a widget of a native window loses keyboard focus. If a native window has the OS keyboard focus then (the modal was opened from it, say by a double-click in a floating panel) and still has it 0.2 s later, the main window gets `ViewportCommand::Focus`, so the modal gets the keys. The wait lets an OS dialog opened with the modal (a file dialog) take focus first; then nothing is sent. A zoom gesture still shows in egui's `InputState::zoom_delta`, which cannot be cleared; a widget that zooms only while hovered ignores it. egui smooths wheel scrolling, so a scroll area in a native window may still scroll for about 100 ms after blocking ends, with the remainder of a wheel turn made just before it began. - Floating windows drawn in the main window need nothing: the modal covers them. - **Input hook.** eframe runs `App::raw_input_hook` for the main window only. An app that rewrites input there (say, Ctrl+click to a secondary click on macOS, or blocking input during automation) passes the same rewrite to `DockArea::native_input_hook` every frame as a closure. eframe's hook takes `&mut self`, so state it shares with the closure goes in an `Arc>`. The dock area runs it on each native window's `RawInput` (`viewport_id` names the window; see `DockArea::window_viewport`). It runs as an egui `Plugin::input_hook`, before egui reads the input, so widgets see rewritten pointer and key events as if the window system had sent them. It runs once per pass, so a frame that egui runs twice calls it a second time with the events already taken. The hook must be `Send + 'static`, as egui plugins are. - **Dropped files.** Files dragged over or dropped on a native window come back in `DockOutput::window_files`, one `WindowFiles` per window that had any this frame: the window's id and viewport, the panel whose body is under the pointer (else the window's shown panel, since the window system may send no pointer moves during a file drag), the pointer's last position in the window, and the window's `hovered_files` and `dropped_files`. Files on the main window stay in its own `RawInput`. - **Drags.** Tabs, groups and whole windows drag between the app's OS windows, and the app's own drags in panel bodies reach the window under the pointer. - *Ownership.* The window where the button went down owns the drag: the window system sends it the pointer's moves and the release while the button is held, inside the window or not. So the pointer leaving a window (`PointerGone`) is not a release. A drag ends on release, Escape (pressed in any of the app's windows, since keys go to the one with keyboard focus), when none of the app's windows has focus, or when its window closes or its panel goes. - *Hit-testing.* The owner adds its desktop origin to the pointer: a native window's reported `inner_rect.min`, or while it moves by its bar, the place it was last put less the pointer's offset from the pressed point. The window under that desktop point is a floating native window in front of the main window first (palettes, then normal windows, most recently focused first), then the main window, then a normal window behind it. A window moving by its bar is never its own target. A point in no window is on the desktop. - *Targets and previews.* Each window draws its drop targets in its own coordinates, and the window under the pointer draws the drop preview (zone, result rect, ghost) in its own frame. The source window shows only the "Hold {key} to undock" hint. The release is resolved at the end of the main window's frame, after every native window has drawn. - *Drops.* Over a window, a tab or group docks or joins there with the usual targets: dock lines and frame zones in the main window, frame zones and tab rows in floating windows. Over the desktop, it floats into a new OS window placed so the grabbed tab stays under the pointer (the window's top-left is the pointer minus the grab offset, less the bar's height). A Ctrl/Cmd-drag floats there wherever it is released. - *Moving a window.* Dragging the bar, the only tab of a window, or the drag area of its only group moves the window, so the pressed point stays under the pointer. On macOS each frame puts the window at the cursor's desktop position (AppKit's `NSEvent::mouseLocation`) less the pressed point, and targets are hit at that position. AppKit reports a window's new place as soon as a move is commanded, but measures the pointer events it sends against where the window server had the window, which can be a move behind; placing the window from those events would overshoot and step back. Elsewhere each move is worked out from a pointer move of that frame and the window's reported place, which the pointer's position is relative to; a move commanded earlier may land late. A frame with no pointer move leaves the window. X11 sends no move whose position in the window repeats the last one, so while the pointer keeps exact pace with the window the window can trail it by one move until the next. Released over a target in another window, the whole window docks or joins there as its groups (`Action::MoveWindow`). The bar docks only with `DockStyle::title_bar_docks`; the only tab or group docks either way, since it is the way back in with that flag off. Targets: in the main window a dock line, a frame's tab row or edge zone, or the layout's outer edge; in a floating window a frame zone or tab row. A frame body's center takes a window moved by its only tab or group, as that tab or group drag would, but not one moved by its bar. Over the desktop, or with Ctrl/Cmd held, it stays where it was moved, and the layout takes its place once, at the release. Escape puts it back. An in-window floating window's title bar still splits only groups of other floating windows. - *Wayland.* With `DockArea::native_windows(true)` on Wayland, or wherever `outer_rect` is `None`, desktop positions are unknown, so drops across windows cannot be resolved. A drag works inside its own window, and a release outside it floats a new window that the compositor places. Moving a window hands the move to the compositor, which never docks it. - *App drags in panel bodies.* A drag the app starts in a panel body can reach the window under the pointer, so a drop site there works as it does inside one window. - *Which drags.* An egui drag of one of the app's widgets, pressed with the primary button in a panel body, that carries something: egui's `DragAndDrop` holds a payload (`dnd_set_drag_payload`), or the app calls `docking::route_app_drag(ctx, area_id)` each frame while the drag lasts, from the body or before the area shows. An app that keeps its payload in the context's data makes that call. Other drags (sliders, scrollbars, text selection, canvas pans) stay in their window and keep getting its pointer. A call counts for its frame and the next; once routing starts, it lasts until the drag ends. - *Events.* While the drag lasts, the owner's pointer moves over another of the app's windows (found as for tab drags, front window first) go to that window in its own coordinates: `PointerMoved` while the pointer is over it, `PointerGone` when it leaves, and the release as a primary `PointerButton` with `pressed: false`. That window sees `pointer_hover_pos` and `any_released` as if the window system had sent them. It sees no press, so `any_down` stays false there and nothing in it is clicked. The owner sees the pointer gone while it is over another window, so its panels under a palette see no hover and no drop. - *Input path.* Events go in through the area's egui input plugin, before any widget reads the input; the app calls nothing more. In a native window this runs before the app's `native_input_hook`. eframe runs the main window's `App::raw_input_hook` earlier, so that hook sees the main window's input without the routed events. - *Release timing.* A window drawn after the owner in the same pass gets the events in that pass (from the main window, every native window does). The main window, and a native window drawn before the owner, get them on the next pass, which is requested. When the release goes to another window, the owner gets its own release, and the pointer events that came after it, in the main window's next pass (a rerun of a discarded pass does not count), so its drag stops (`drag_stopped`) then. egui clears a `DragAndDrop` payload when the owner sees the release, so the target always reads its release while the payload is there. An app that keeps its own payload clears it no earlier than the owner's release. - *Limits.* Nothing is routed where desktop positions are unknown (Wayland, `native_windows(false)`, embedded viewports) or while input is blocked. Escape in any of the app's windows, a focus loss, `cancel_drag` and a replaced layout stop the routing: the window under the pointer sees it go and gets no release it has not read yet. The drag goes on in its own window until the button comes up, and the owner still gets its release. On the web and wherever egui embeds viewports, nothing changes: floating windows stay in the page at their in-window rect, `native` and the monitor fields are kept but unused, the input hook never runs, and `forwarded_events` and `window_files` stay empty. Without the feature, the fields exist and are never set by the renderer. ## Labels Every visible and accessibility label is a `*_label` field of `DockStyle`, with an English default: title case for menu items, sentence case for names only screen readers announce. `DockStyle::localized` sets them all from one keyed lookup: ```rust,ignore let style = DockStyle::from_ui(ui).localized(|key| app.strings.get(key).cloned()); ``` Keys are `dock.close`, `dock.float`, `dock.collapseToIcons` and so on; the rustdoc of `localized` lists them all. `DockContent::label` and `action_label` can shape panel and action text further; the logical label stays the accessibility name. ## Testing `DockArea::hit_rects(ctx, id)` lists every gesture source drawn last frame as a `Hit` with its rect: tabs, drag bars, borders, column bars, »/« buttons, title bars, close buttons, icons, icon grips, resize edges and dividers. It is always compiled, so an app can return it from a `ui.docking` control method next to the layout and the focused panel. `DockArea::hit_id(id, &hit)` is the egui widget id of a control, for tests and automation that focus it or read its response. `DockArea::floating_layer(id, &window)` is a floating window's egui layer: compare its place in `memory.layer_ids()` with another layer to tell whether the window covers it, and read its rect with `memory.area_rect(layer.id)`. A window the area does not draw (its panels hidden, or a frame maximized) keeps its last rect there, so check `memory.areas().is_visible(&layer)` first. The `testing` feature adds `docking::testing::DockDriver`. It runs a `DockArea` in a headless egui context with real pointer and key events, and applies the actions each frame emits. ```rust,ignore let mut driver = DockDriver::new(app_layout(), Panels::default()); let bar = driver.hit(&Hit::DragBar(PanelId::Layers)).unwrap(); driver.drag(bar.center(), egui::pos2(2.0, 300.0)); driver.settle(); assert!(driver.hit(&Hit::ColumnBar(PanelId::Layers)).is_some()); ``` It also has `press`, `release`, `click`, `hold`, `key`, `focus`, `hits`, and checks for painted previews (`filled`, `outlined`). With `native-windows`, `with_native_host(origin)` stands in for OS windows: the main window's content sits at `origin` on the desktop, and each native window runs its own frame with its own input and desktop rect (`host()`, `window_step`, `window_click`). `NativeHost` can report a monitor size (`monitor_size`), give windows a frame between their outer position and content (`frame`), land `OuterPosition` a frame late (`lag`), and report no positions (`no_position`, as on Wayland). `window_pointer` moves the pointer to a desktop point in a native window; the host can tell that point as the cursor's (`tells_cursor`, as AppKit does) and measure the window's pointer events against its place some frames back (`stale`, a pattern taken one entry per call). A `HostWindow` takes files dragged over it (`hovered_files`) or dropped on it (`dropped_files`), and `with_native_input_hook` passes a hook to `DockArea::native_input_hook` every frame. `crates/ui/examples/docking_native.rs` (`cargo run -p craft-ui --example docking_native --features native-windows`) shows a dock with two native floating windows and prints every action and window place, for checking moves on a real window system. craft-ui's own tests in `crates/ui/tests/docking_workflows.rs`: - Load every app's v1 layout fixture, dock groups into a new dock, a bottom band and a seam, collapse and expand the column, float it by command and drag it back, then check the layout reads back as written. - Render Layers, Properties and Brushes panels with real content, and merge, detach and redock Brushes by pointer at two widths, two scales and both themes. Set `CRAFT_UI_DOCK_VISUAL_DIR` to keep the captures: ```sh CRAFT_UI_DOCK_VISUAL_DIR=/absolute/output/path cargo test -p craft-ui --test docking_workflows --all-features ``` An adopting app still tests its own commands, contents, saved workspaces and themes. ## What stays in the app - The panel registry, panel contents and document state. - Named workspaces, Reset, and when and where layouts are saved. - Menus and key bindings outside the docking chrome. - Native window ownership on platforms without egui viewports.