# Studio UI Foundations - Naming, Events, and Custom Components Agenda

## Status

Open

## Purpose

Define the shared UI foundations required before the Studio grows into a larger product surface.

This agenda exists to keep the Studio from becoming a pile of unrelated JavaFX screens with inconsistent naming, ad hoc event wiring, and one-off controls.

## Domain Owner

`docs/studio`

## Context

The current `prometeu-studio` shell is still small enough to be remodeled.

Today there is no real Studio-wide event system.

Current behavior is still largely based on direct wiring between UI elements, workspace hosts, and service calls.

That is the right moment to establish explicit foundations for:

- clear naming conventions;
- a Studio event system;
- reusable custom components;
- long-lived support for i18n and themes.

The immediate driver is the upcoming Assets workspace, but the same foundations will affect Editor, Debugger/Profiler, and the future Shipper surface.

## Core Questions

1. Which naming conventions should apply to Studio shell classes, workspaces, panels, services, and events?
2. What kind of Studio-wide event system should exist between shell, workspaces, and background services?
3. Which custom components should become first-class reusable Studio controls instead of one-off implementations?
4. How should i18n and theme support constrain custom component design from day 1?
5. Where is the boundary between generic infrastructure and domain-specific workspace UI?

## Initial Areas To Close

### Naming

Need clear and stable names for:

- shell surfaces;
- workspace types;
- right-side utility tabs;
- events and event payloads;
- reusable controls and component packages.

### Events

Need a Studio event model that can support:

- shell-level state changes;
- workspace-local interactions;
- background service notifications;
- progress and activity publication;
- future debugger/profiler integration.

Current direction:

- introduce a Studio-owned event system instead of continuing with ad hoc direct coupling;
- keep it small, local, and strongly typed;
- model it as a `StudioEventBus` or equivalent typed publish/subscribe surface;
- avoid stringly-typed event names and avoid overbuilding a large reactive framework too early.

Illustrative event categories include:

- project lifecycle events;
- workspace selection events;
- run/build intent events;
- activity publication events;
- diagnostics and asset-selection events.

### Custom Components

Likely candidates include:

- directory tree or project tree controls;
- activity feed views;
- diagnostics list views;
- inspector panels;
- staged action and preview surfaces.

## Recommendation

Close this agenda early, right after the shell decision.

Recommended direction:

- establish naming before adding many more UI classes;
- define a Studio-owned typed event system before workspaces start integrating services ad hoc;
- invest in reusable components only where the shell or multiple workspaces will truly benefit;
- require i18n and theme compliance for every Studio-specific control.

## Expected Follow-up

- one or more Studio foundation decisions,
- a foundational Studio spec,
- a PR/plan for shared UI infrastructure in `prometeu-studio`.