Studio: create Settings panel with category-driven UI

Studio: unified Settings editor

Goal

Implement a dedicated Settings editor accessible from Studio → Settings that provides a centralized, searchable interface for all Studio configuration.

The Settings editor should behave like any other editor asset in Turian: it opens in its own editor tab, participates in the tab lifecycle, tracks unsaved changes, and prompts the user before closing if modifications have not been saved.

This implementation should maximize reuse of the existing Inspector + Reflection system, avoiding duplicate property editors. The goal is to make the Settings editor largely another consumer of the reflection/property framework rather than introducing a parallel UI implementation.

Context / integration points

  • Settings are currently scattered:
    • some are hardcoded,
    • some are stored in studio/settings.json,
    • some are exposed by individual panels.
  • The existing Inspector already solves most of the difficult problems:
    • property rendering,
    • reflection,
    • metadata,
    • type-specific widgets,
    • validation,
    • enums,
    • ranges,
    • tooltips,
    • change tracking.
  • Instead of implementing another property editor, the Inspector infrastructure should be generalized so it can edit arbitrary reflected objects, not only scene assets.
  • Like other editor resources, Settings should open in an editor tab instead of a floating dialog.
  • Unlike Scene editing, Settings has no viewport; therefore the Settings editor may temporarily occupy both the Scene Hierarchy and Scene View areas with its own dedicated layout.

Design

Inspector reuse

The implementation should reuse as much of the Inspector codebase as possible.

If necessary, refactor the Inspector into reusable layers such as:

  • Reflection/property enumeration
  • Property widget generation
  • Metadata interpretation
  • Validation
  • Undo/change tracking
  • Property groups/categories

The Inspector panel itself should become a thin UI wrapper over this reusable framework.

The Settings editor should simply provide a reflected Settings object to the framework.

Settings metadata

Expand the Settings API so every setting declares metadata such as:

  • identifier
  • title
  • description
  • category
  • type
  • default value
  • optional constraints
    • min/max
    • enum choices
    • validation callback

Future systems (plugins, project settings, preferences) should reuse the same API.

Editor UI

The editor consists of:

  • Left sidebar
    • hierarchical category tree
  • Main panel
    • reflected property editor
  • Search field
    • filters by title
    • description
    • category
  • "Open JSON" button
    • opens studio/settings.json through the Asset API using the configured external editor

The layout should resemble editors such as VSCode or Zed while remaining consistent with the rest of Studio.

Tab behavior

Settings is opened as a regular editor tab.

The tab should support the standard editor lifecycle:

  • dirty state
  • modified indicator (*)
  • Save
  • Save As (optional)
  • Close
  • Close confirmation if modified

The dirty indicator should behave identically to scenes, materials, scripts, and other editable assets.

Persistence

Changes may either:

  • save immediately, or
  • accumulate until Save

The behavior should be consistent with the rest of Studio's editor model.

If explicit saving is adopted, modifications must remain in memory until committed.

Tasks

  • Audit existing settings and organize them into logical categories
  • Refactor Inspector into reusable reflection/property editing modules
  • Expand the Settings API with metadata support
  • Migrate builtin settings to the new metadata system
  • Implement studio/SettingsEditor.zig
  • Implement category sidebar
  • Implement search/filter
  • Reuse Inspector property widgets instead of creating new ones
  • Implement dirty state tracking
  • Display * in the tab title when modified
  • Prompt before closing unsaved changes
  • Implement Save / Reload workflow
  • Add Studio → Settings menu entry
  • Implement "Open JSON" action
  • Verify persistence across editor restarts

Acceptance criteria

  • Settings open in a dedicated editor tab.
  • The editor reuses the Inspector reflection/property system.
  • Existing property widgets are shared between Inspector and Settings.
  • Settings are organized into categories.
  • Search finds settings by title, description, and category.
  • Modified settings mark the tab as dirty (*).
  • Closing a dirty Settings tab asks whether to save.
  • Saving updates studio/settings.json.
  • Opening the JSON file launches the configured external editor.

Dependencies

Independent.

May require refactoring the Inspector implementation into reusable components before this issue can be completed.

Out of scope

  • Per-project settings.
  • Cloud synchronization.
  • Settings profiles.
  • Reset-to-default UI.
  • Plugin-defined settings pages (future extension, though the metadata API should be designed with this in mind).
Edited by Bruno Massa