prometeu-studio/docs/studio/agendas/01.0. Studio Shell, Workspace Navigation, and Layout Agenda.md

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.