Skip to content

Panels

Purpose

Owns Snap Studio Pro editor UI panels, panel composition, panel routing, and user-facing editor controls.

This territory contains the IMGUI-facing surfaces that allow users to configure preview, export, lighting, animation, background, prefab, shadow, and utility workflows.

Panels are allowed to orchestrate UI.

Owns

  • Editor panel UI
  • Foldout and section drawing
  • User input collection
  • Panel-specific UI state
  • Request object construction from UI choices
  • Routing user actions to services/controllers
  • Panel registration and layout composition
  • Shared panel UI helpers
  • Preview-facing UI surfaces

Does NOT Own

  • Low-level rendering implementation
  • Capture execution internals
  • Preview scene lifecycle ownership
  • Rendering pipeline implementation
  • Core feature-domain business logic
  • File encoding implementation
  • Thumbnail generation implementation

Allowed Dependencies

Panels may depend on:

  • Features
  • Preview facades
  • Models
  • Enums
  • Infrastructure services
  • Shared panel helpers
  • Rendering abstractions
  • Unity Editor IMGUI APIs

Panels should avoid depending directly on:

  • pipeline-specific implementation details where avoidable
  • low-level rendering internals
  • unrelated feature territories
  • window lifecycle internals unless required for navigation/repaint

Notes

Panels are UI territory.

It is acceptable for panels to: - contain UI orchestration - collect multiple settings - build workflow request objects - call feature controllers/services - coordinate foldouts and user-facing sections

It is not acceptable for panels to: - become rendering engines - own preview scene lifecycle - perform low-level export/capture implementation - mutate unrelated systems without routing through the owning feature/service

Some panels are intentionally coordination-heavy because editor UI naturally gathers state from multiple systems. That is not automatically a design smell.

The important boundary is that panels should coordinate user intent, not own production implementation.

RightPanel is intentionally the local composition root for the right-side editor UI. It creates panels, wires dependencies, owns tab collections, and routes drawing. This is clearer and safer than reflection, service locators, hidden registries, or runtime panel discovery.

Future Candidates

  • Keep panels focused on UI and user intent.
  • Continue moving reusable workflow logic into Features or Preview where appropriate.
  • Avoid over-abstracting simple panels.
  • Keep RightPanel explicit and readable rather than clever.
  • Use XML comments on coordination-heavy panels to explain orchestration boundaries.