prometeu-studio/docs/studio/agendas/01.6. Studio UI Foundations - Naming, Events, and Custom Components Agenda.md

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.