Context
The UI editor was originally scoped as part of the technical Scene
project. It belongs in Studio — but only the editing
interaction does; the actual rendering must not be a separate
implementation from what Stage ships, or Studio stops being a reliable
WYSIWYG surface.
Proposal
Split Studio's editor into two halves with different dependencies:
- Preview surface — what the canvas actually renders while composing
a screen. Consumes Scene.Engine + Scene.React (or the renderer
matching the active ui profile) directly and unmodified. This is
the WYSIWYG guarantee: Studio isn't approximating what Stage runs, it's
running the identical engine in design mode.
- Editing chrome — drag/drop composition, property inspector, tree
view, undo/redo. This is Studio-specific interaction logic, not a Scene
concern, and should live in Studio proper (or a distinct
Studio.Editor layer sitting on top of Scene's object model, not
inside Scene).
Open questions
- Design-mode-only affordances (selection outlines, drag handles, slot
placeholders when empty) — do these get injected by the editing chrome
around the untouched preview render, or does Scene.React need a
documented "design mode" flag it renders differently under? Leaning
toward the former to keep the preview surface genuinely unmodified.
Dependencies
Depends on
Blocks — every Studio designer below previews through this surface
Gates other work: the design-mode-affordances question (injected by the chrome vs. a "design mode" flag in Scene.React) decides whether Cratis/Scene#1's renderer contract needs a design-time concern in it at all.
Part of the screen work — build order and full dependency map: Cratis/Scene#7
Context
The UI editor was originally scoped as part of the technical Scene
project. It belongs in Studio — but only the editing
interaction does; the actual rendering must not be a separate
implementation from what Stage ships, or Studio stops being a reliable
WYSIWYG surface.
Proposal
Split Studio's editor into two halves with different dependencies:
a screen. Consumes
Scene.Engine+Scene.React(or the renderermatching the active
ui profile) directly and unmodified. This isthe WYSIWYG guarantee: Studio isn't approximating what Stage runs, it's
running the identical engine in design mode.
view, undo/redo. This is Studio-specific interaction logic, not a Scene
concern, and should live in Studio proper (or a distinct
Studio.Editorlayer sitting on top of Scene's object model, notinside Scene).
Open questions
placeholders when empty) — do these get injected by the editing chrome
around the untouched preview render, or does
Scene.Reactneed adocumented "design mode" flag it renders differently under? Leaning
toward the former to keep the preview surface genuinely unmodified.
Dependencies
Depends on
Scene.Modelfor the editing chrome,Scene.Engine+Scene.Reactconsumed unmodified for the preview surfaceBlocks — every Studio designer below previews through this surface
ui profileand theme configuration UI #160 —ui profileand theme configurationGates other work: the design-mode-affordances question (injected by the chrome vs. a "design mode" flag in
Scene.React) decides whether Cratis/Scene#1's renderer contract needs a design-time concern in it at all.Part of the screen work — build order and full dependency map: Cratis/Scene#7