Inter-widget Communication for UI

[alice-i-cecile]

Our UI widgets will need to communicate with each other in some way. My understanding is that we have two broad approaches here:

1. Function callbacks, where each widget gets its own function and calls other functions up and down the widget hierarchy. This is very incompatible with ECS due to both scheduling and lack of batch processing, so should be avoided if possible.
2. Message passing, where each widget sends and responds to messages from other widgets.

Assuming we move forward with message passing, there are three conceivable strategies for what these "messages" could be represented as:

Message Representation
Messages are expected to be one-to-many, to allow them to affect multiple entities with a single message produced. Messages must scoped in some way, possibly with entity groups (#1592).

1. Messages as events (including channelized events). These are the most natural representation, but only persist for two-ish frames, and require a fixed data format, which is painful if we need to modify these events extensively.
2. Messages as components. Set the component value on other widgets, and then they read in that state. This is probably the most idiomatic from a Bevy perspective, but you can't refer to the messages themselves as discrete object. These could be events, which gives us channels for free. Introduction of idea
3. Messages as entities. Lets you refer to messages as a discrete object, but is hard conceptual model. Requires many many hard sync points for events to be spawned.
4. Messages using state charts. Avoids reproducing all of the supporting infrastructure, but requires more convoluted generation and data representation.

Independently, we need to solve the problem of when do our widgets send and receive these messages. This is particularly important in contexts where we have complex trees of behavior, or loops.

Consider a control panel and an output. The text on the control buttons changes based on the current output (e.g. "turn off" / "turn on"), and the output changes based on the button configuration. Depending on the ordering of our systems and the number of times they run per frame, we could end up with either serious delays in processing these results, or rendering a messy and incorrect intermediate state before flashing to a new one.

Widget System Scheduling

1. One system per frame.
2. Multiple copies of each system per frame.
3. An indefinite number of times in a frame using looping run criteria. Continue processing work until there's no more work to do. This might or might not be done using the State abstraction. We can cut this short if we run out of time in our frame.

[alice-i-cecile]

Conclusions:

• We should be using message passing, not callbacks.
• We need looping run criteria to avoid bad frame delays, but should have a circuit breaker to avoid lag,
• Messages as components seems like the most promising approach for message representation, especially if we're using event components to create channels.

[alice-i-cecile]

Making the messages created immutable is generally considered a good idea, to reduce the difficulty of reasoning about them. This very much pushes us away from the messages-as-raw-components and messages-as-entities data models.

Messages as events stored in channels on a component in a dedicated channel entity should work just fine.

[alice-i-cecile]

Can we use #1527 via relationships to nicely differentiate our channels?

[alice-i-cecile]

Opinion: Layout should be handled in a single system or set of systems that runs after the communication has concluded. This separates concerns nicely and we don't care about computing or accessing layout for intermediate results.

[alice-i-cecile]

Layout events and UI events are fundamentally different, and should be separated by default. See discussion on Discord.