155 lines
6.1 KiB
Markdown
155 lines
6.1 KiB
Markdown
# Studio Shell, Workspace Navigation, and Layout Agenda
|
|
|
|
## Status
|
|
|
|
Closed
|
|
|
|
## Purpose
|
|
|
|
Define the baseline Studio shell:
|
|
|
|
- main window layout,
|
|
- workspace navigation model,
|
|
- shell regions and panel hierarchy,
|
|
- default landing behavior,
|
|
- how future workspaces should fit into the frame.
|
|
|
|
## Domain Owner
|
|
|
|
`docs/studio`
|
|
|
|
## Current Code Context
|
|
|
|
Current `prometeu-studio` already provides:
|
|
|
|
- `MainView` as the root shell;
|
|
- `WorkspaceBar` as left-side workspace navigation;
|
|
- `EditorWorkspace` as the most concrete workspace;
|
|
- placeholder workspaces for `Assets` and `Device`;
|
|
- a `BuilderWorkspace` implementation artifact with logs and toolbar.
|
|
|
|
The shell exists, but it is still closer to a scaffold than a documented Studio UX contract.
|
|
|
|
This shell may be substantially remodeled in code as long as the resulting Studio preserves:
|
|
|
|
- theme support;
|
|
- i18n support;
|
|
- a clear path for custom Studio components instead of ad hoc UI fragments.
|
|
|
|
## Core Questions
|
|
|
|
1. What is the long-lived shell structure of the Studio?
|
|
2. Is left-side workspace switching the correct baseline navigation model?
|
|
3. Which shell regions are global and which belong to each workspace?
|
|
4. How should the Assets workspace coexist with Editor, Device, and future shipping flows?
|
|
5. What should the default landing workspace be?
|
|
|
|
## Options
|
|
|
|
### Option A
|
|
|
|
Keep the current shell mostly intact and grow workspaces within it.
|
|
|
|
### Option B
|
|
|
|
Evolve toward a multi-panel shell with global activity and contextual side panels.
|
|
|
|
### Option C
|
|
|
|
Adopt a dock-heavy IDE-style shell from the start.
|
|
|
|
## Tradeoffs
|
|
|
|
- Option A is fast and consistent with current code, but may constrain richer workflows later.
|
|
- Option B preserves the current shell while creating room for Studio-grade interaction design.
|
|
- Option C is powerful, but likely too heavy for the current code and service maturity.
|
|
|
|
Specific concern with adopting a fully docked shell too early:
|
|
|
|
- it forces panel lifecycle and layout-persistence decisions before the core workspace model is stable;
|
|
- it adds implementation weight around focus, restore, drag/drop, and window state without proving that the Studio already needs that flexibility;
|
|
- it increases UX complexity while the Assets workspace and background activity model are still being defined;
|
|
- it risks stabilizing the wrong shell topology too early.
|
|
|
|
## Recommendation
|
|
|
|
Prefer Option B.
|
|
|
|
Recommended direction:
|
|
|
|
- keep workspace switching in the shell,
|
|
- formalize a stable frame with top global menus, left workspace selectors, center workspace body, and right global utility panel,
|
|
- let each workspace own its internal panels, including logs and detailed operational output,
|
|
- avoid a fully dockable IDE model for the first Studio UI wave,
|
|
- revisit dockability only after the shell regions and workspace panel responsibilities are proven in use.
|
|
|
|
## Open Questions
|
|
|
|
1. Which shell regions are baseline and always present:
|
|
top global menus, left workspace navigation, right global utility panel, status/progress bar?
|
|
2. Which right-side tabs are baseline in v1, and which are future additions?
|
|
3. Should the Studio land directly in a workspace, restore the last workspace, or open through a project launcher/home surface first?
|
|
4. Does `BuilderWorkspace` remain a first-class shell workspace, or should future shipping/build flows move toward a different Studio surface?
|
|
5. Which parts of the shell must be fixed in v1, and which can remain future extension points without immediate docking support?
|
|
|
|
## Current Direction
|
|
|
|
The preferred direction for question 3 is to introduce a lightweight project launcher or home surface before the main workspace shell.
|
|
|
|
Target experience:
|
|
|
|
- closer to Unity or the IntelliJ family than to direct last-tab restore;
|
|
- show existing projects immediately;
|
|
- make `open project` and `create project` first-class actions;
|
|
- only enter the workspace shell after a concrete project is selected or created.
|
|
|
|
This keeps project entry intentional and gives the Studio a stable place for project lifecycle actions without overloading the main workspace shell.
|
|
|
|
The current preferred shell model is:
|
|
|
|
- top region with global Studio menus such as `File`, `Edit`, `View`, and similar shell-level actions;
|
|
- left-side fixed workspace selector, closer to IntelliJ-style workspace switching than to a free docking system;
|
|
- center region fully owned by the selected workspace;
|
|
- right-side global utility surface implemented as tabs;
|
|
- logs and detailed execution output owned by each workspace instead of a single global bottom console.
|
|
|
|
The right-side global utility surface is intended for concerns such as:
|
|
|
|
- general activity visibility;
|
|
- contextual inspector or summary views;
|
|
- global shortcuts and shell-level utility surfaces.
|
|
|
|
`Run` should not be modeled as a tab.
|
|
|
|
It should remain always visible at the top-right portion of the shell so that running the current project or relevant flow is always easy to reach.
|
|
|
|
This keeps run/build controls immediately accessible while allowing the right-side tab system to serve broader global concerns.
|
|
|
|
Current baseline answers:
|
|
|
|
- the initial right-side tab set contains only `Activity`;
|
|
- the right-side panel must remain easy to extend with additional tabs later;
|
|
- `BuilderWorkspace` may remain in the shell temporarily because it is still useful for tests, but it should be treated as a low-investment transitional surface on the path toward a future `Shipper`;
|
|
- the baseline fixed workspace set is:
|
|
- Code Editor
|
|
- Asset Management
|
|
- Debugger/Profiler
|
|
- Shipper, temporarily represented by the current `BuilderWorkspace`
|
|
|
|
The shell and workspaces should also evolve with explicit foundations for:
|
|
|
|
- clear naming conventions,
|
|
- a Studio event system,
|
|
- reusable custom components such as directory trees and related structured UI controls.
|
|
|
|
## Expected Follow-up
|
|
|
|
- a shell decision,
|
|
- a Studio shell spec,
|
|
- a PR/plan for `MainView`, `WorkspaceBar`, and workspace composition.
|
|
- a separate Studio foundations agenda for naming, events, and custom component architecture.
|
|
|
|
## Outcome
|
|
|
|
Closed in [`001-studio-shell-workspace-navigation-and-layout-decision.md`](../decisions/001-studio-shell-workspace-navigation-and-layout-decision.md).
|