Dock And Shared Infrastructure

Every dev-tool plugs into the same runtime surface: one dock, one hotkey layer, one overlay layer, and one preference store. During early access, you do not get that surface until your accessDevtoolToken is accepted. You do not register the dock directly — it appears automatically the first time you register an enabled dev-tool.

This page describes the pieces every tool inherits, so the individual tool pages do not have to repeat them.

If you are new to StringTune dev-tools, the shortest path is:

1. Configure accessDevtoolToken.
2. Register one StringDev* module in dev.
3. Start StringTune.
4. Use the dock button or the tool hotkey to open that tool.

The dock

The dock is a floating control strip in the bottom-left of the viewport. Its contents update as dev-tools register themselves.

What the dock gives you:

• A toggle button per tool with the tool's icon. Clicking it flips the tool's active state.
• A hotkey label shown in the tooltip, for example "Inview (Shift+I)".
• Optional sub-controls attached to a tool (used by Layout for its global settings button).
• A collapse control — the leading logo button. Collapsing the dock keeps all tools running, only the UI hides.
• A live FPS readout rendered at the end of the strip, so you always see current performance cost.

Collapse and restore

The dock collapse state is remembered between sessions. You can collapse from:

• Clicking the main logo button at the top of the dock.
• Pressing Shift+S anywhere on the page (ignored while typing in a field).

Reopening restores the previous active/inactive state of each tool exactly as you left it.

Hotkeys

Every dev-tool may declare one hotkey. Hotkeys:

• Are captured globally for the whole page.
• Are ignored while you are typing in a text field, dropdown, or editable region.
• Match modifiers strictly — Shift, Ctrl, Alt, and Meta must all line up exactly with the declared combo.

The shared hotkeys today:

Overlay surfaces

Dev-tool overlays sit above your page content and do not affect your layout. In practice, this means the guides stay visually separate from your own components and remain usable even on pages with fixed UI.

You do not configure this. It simply means overlays always appear on top of your content in a predictable order.

Who attaches to what

Each dev-tool decides which elements it attaches to. Three patterns are used in practice:

• Global — the tool watches the entire page regardless of attributes. Used by Inview.
• Attribute-driven — the tool attaches only to elements that declare a specific activation attribute, e.g. string="layout" for the Layout HUD.
• Universal inspector opt-in — any element that declares string="dev-inspect" is picked up by every compatible tool. Useful for poking at a single element without enabling the full overlay.

Each tool page lists which pattern it uses.

Saved preferences

Dev-tools save user preferences in your browser. Examples of what gets saved:

• Dock collapse state and which tools are active.
• Guide lines and the currently selected ruler mode.
• Per-element grid configurations.
• Marker positions and which elements have their Inview markers hidden.

Clearing site data in your browser resets everything to defaults.

Icons

Every dev-tool draws its icons from a shared dev-tools icon set. You do not ship icons yourself — the dock picks the correct size and variant for each surface automatically.

Lifecycle of a tool

1. You set accessDevtoolToken through stringTune.setupSettings(...).
2. You register a dev-tool through stringTune.use(StringDevX).
3. The dock appears (if it is the first registered dev-tool and token access is granted) and gains a button for this tool.
4. The tool attaches to the elements it cares about. Overlays appear; hotkey is bound.
5. The tool measures and updates inside the same runtime/frame pipeline as the rest of StringTune.
6. Toggling the tool off disables its UI and overlay behavior; some tools also clear temporary interactive state.
7. Unloading the tool or destroying StringTune removes dock UI, hotkeys, overlay layers, and tool-specific DOM/event cleanup.

Where to go next

• Tool pages: Inview, Layout, Progress, Rulers.
• High-level overview: Developer Tools Overview.
• Why dev-tools feel free even when several are active: Performance & Batching.