Skip to content

HubWindow Build & Layout

Canonical source: SmrtApps/CSApps/HubWindow/README.BuildAndLayout.md (mirrored below)


HubWindow — Build, Staging, and Window Layout (Canonical)

This document tracks HubWindow’s current build/staging workflow and the current window layout/dimensions. It is intentionally “current-state only” so future changes can be made by updating values and/or the referenced theme tokens.

Build & Staging

HubWindow is built and staged via the per-app script: - Script: SmrtApps/CSApps/HubWindow/Build-HubWindow.ps1 - Optional wrapper: SmrtApps/CSApps/HubWindow/Build-HubWindow.bat (runs the interactive menu by default) - Staging output: Apps/<Configuration>/win-x64/HubWindow/HubWindow.exe

Notes: - Use the repo scripts (not ad-hoc commands) so staging stays consistent with Supervisor/tooling expectations. - The staging directory may fail to delete if the staged HubWindow.exe is currently running.

Common script modes

The build script supports a -Mode parameter: - BuildStage — build + stage only - BuildRun — build + stage + run staged - BuildRunInitialsFallback — build + stage + run staged while blocking profile picture (DEBUG-only test hook) - BuildRunGlyphFallback — build + stage + run staged while blocking picture+initials+name (DEBUG-only test hook) - Menu — interactive menu (requires an interactive console; tasks/CI typically redirect input)

Staging semantics and output layout are governed by README.Files/System/Guides/SmrtHub.Runtime-Footprint.README.md.

Window Layout (Current Scaffold)

HubWindow currently renders a fixed-height “scaffold” that is used as the visual baseline before wiring collapse/expand behavior.

Row model

All scaffold rows are 48 DIPs high: - Title bar: 48 - App controls bar: 48 - Collapsible grid: 4 rows × 48

Total content height (current scaffold): 6 × 48 = 288 DIPs.

On first load, HubWindow applies a one-time resize so the window height matches this scaffold (accounting for non-client border height) to avoid large unused whitespace.

Collapsible grid (visual only)

The collapsible region is implemented as a left SplitView (CompactInline) containing: - Pane (Column A / A0–A3): compact 48 DIPs (icons-only) and expanded 180 DIPs (icons + labels) - Content (Columns B/C / B0–C3): column B flex (*), column C fixed 48 DIPs (reserved)

Current SplitView lengths: - CompactPaneLength = 48 - OpenPaneLength = 180

Rows 0–2 are now actively used as the HubWindow “Bars0–2” surface:

  • Row 0: Source name (B0)
  • Row 1: Source path (B1)
  • Row 2: Clipboard content (B2)

Appearance rules: - The ribbon backdrop uses SmrtHub.Surface.SubChrome.Background behind the SplitView content surface (columns B/C). - The left rail pane uses SmrtHub.Surface.SubChrome.Background (and the SplitView pane border is disabled so the transition is seamless). - Rows 0–2 render as three separate “card” surfaces in column B using SmrtHub.Surface.Card.Background with full rounding CornerRadius="8" so the ribbon effect is revealed “for free” by the dark backdrop.

Alignment rule: - Pane rows A0–A3 and content rows B0–B3 must remain aligned even when the clipboard row (B2) expands/contracts. - Because SplitView pane/content are separate layout trees, HubWindow explicitly synchronizes the pane row heights from the content row actual heights after layout.

Left-rail pane toggle and window resizing

When the left-rail pane toggles between compact (48 DIP) and expanded (180 DIP), HubWindow resizes the outer window by the rail delta so the main content region keeps a stable width: - Opening the pane: window widens by OpenPaneLength - CompactPaneLength = 132 DIP (scaled to pixels). - Closing the pane: window narrows by the same delta (or the actual applied delta if max width clamping prevented full expansion on open).

This prevents the content from reflowing when toggling the left rail. Additional stabilization: - Scaffold height resize work is suppressed during pane toggles to avoid transient layout measurements triggering height constraints. - Clipboard-driven auto-width calculations are pane-aware and do not shrink the window below the open-pane delta.

Window Width Constraints

HubWindow currently enforces a max width based on the current monitor work area: - Maximum width: 60% of the current monitor work-area width - Minimum width: max of: - 30% of the current monitor work-area width (baseline) - 520 DIPs (stable DIP floor) - a dynamic title-bar-fit minimum computed from the measured left controls + desired search box width + native caption-button inset (prevents the centered title-bar search box from being clipped) - then clamped to the current monitor work-area width on very narrow or portrait screens

Implementation notes: - The constraint is applied via WM_GETMINMAXINFO so user resizing/maximize respects it. - Maximize respects the configured caps by setting both track size and maximize target size in WM_GETMINMAXINFO. - During interactive move/size, HubWindow keeps the constraint work-area stable (using the start monitor) to avoid mid-drag resize/position jumps when crossing monitors. - The same clamp is also applied during the one-time scaffold sizing pass on first load and during programmatic resizes.