105 lines
3.2 KiB
Markdown
105 lines
3.2 KiB
Markdown
# 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`.
|