2.4 KiB
Studio Events and Components Mental Model
Two things are meant to stop the Studio from becoming messy as it grows:
- a typed event model;
- a single authoritative control layer.
These two rules solve different problems, but they reinforce each other.
Why a Studio-owned event system?
Without it, the shell, workspaces, and services begin to call each other directly.
That usually feels fine at first, because the UI is small. Then the application gains:
- global activity surfaces;
- background operations;
- multiple workspaces;
- status and progress reporting;
- cross-cutting actions such as run or diagnostics.
At that point, direct references become the path of least resistance and the UI starts coupling itself in ways that are hard to unwind.
The Studio event system exists to keep event publication explicit and typed.
Why both a global bus and workspace buses?
Because the Studio needs both segregation and shared visibility.
Workspaces should be able to keep their local activity scoped. The shell should still be able to observe what is happening globally.
The chosen rule is therefore:
- each workspace has its own bus;
- the Studio has a global bus;
- every workspace event is automatically republished to the global bus.
This means callers do not need to decide when to duplicate publication manually.
Why not rely on raw JavaFX controls directly?
Because raw JavaFX use spreads quickly and creates UI drift.
When each part of the app consumes JavaFX controls directly, the Studio gradually accumulates:
- inconsistent naming;
- inconsistent styling hooks;
- repeated local wrappers;
- uneven behavior between screens;
- more work each time theme or locale behavior needs to change.
That is why the Studio uses prometeu-studio-components as its visual control layer.
Does that mean reimplementing JavaFX?
No.
The goal is not to reproduce every JavaFX API. The goal is to expose the Studio-facing API the application actually needs.
That keeps the control layer:
- opinionated;
- smaller than JavaFX;
- aligned with the Studio's own UI dialect.
Practical reading rule
When adding UI code, ask two questions:
- Is this communication really an event?
- Is this control part of the Studio's visible dialect?
If the answer to the first question is yes, it should probably publish a typed Studio event.
If the answer to the second question is yes, it should probably come through prometeu-studio-components.