77 lines
2.4 KiB
Markdown
77 lines
2.4 KiB
Markdown
# 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:
|
|
|
|
1. Is this communication really an event?
|
|
2. 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`.
|