From 1f3704d685c332f229f72d67a2e93906259d3b7c Mon Sep 17 00:00:00 2001
From: Alice Cecile <alice.i.cecile@gmail.com>
Date: Thu, 15 Apr 2021 16:52:15 -0400
Subject: [PATCH 01/16] Initial outline

---
 rfcs/system-driven-ui.md | 129 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 129 insertions(+)
 create mode 100644 rfcs/system-driven-ui.md

diff --git a/rfcs/system-driven-ui.md b/rfcs/system-driven-ui.md
new file mode 100644
index 00000000..40fd8f3f
--- /dev/null
+++ b/rfcs/system-driven-ui.md
@@ -0,0 +1,129 @@
+# Feature Name: `system-driven-ui`
+
+## Summary
+
+UI widgets' behavior is defined entirely by the components they have, and the data within those components.
+The logic to execute the UI is handled by Bevy systems, operating in parallel over the relevant UI widgets.
+
+## Motivation
+
+In larger teams, UI is commonly built with visual tools, rather than from code, which enables non-programming team members like artists and UI designers to participate directly.
+As a result, an intermediate asset-like representation is needed, allowing large teams to organize assets cleanly rather than scattering them across the code base.
+
+Doing so pushes us towards a data-driven workflow that fits naturally with our ECS, and in particular, scenes.
+By controlling the behavior of our widgets with components and systems, we can support this use case while allowing for seamless integration of code-driven and asset-driven UI workflows while allowing for performant and easily extensible widget behavior.
+
+## Guide-level explanation
+
+Widgets, as previously discussed in [UI Building Blocks and Styles](https://github.com/bevyengine/rfcs/pull/1) are simply entities with various components on them.
+Rather than merely controlling the cosmetic style of our widgets, we can attach **functional components** to our widgets as well.
+
+Just like when we're using the ECS to control our game's logic, these components both store data and control behavior, by determining which systems apply to each particular `Widget` entity.
+Suppose we want to create a radio-button widget.
+Rather than trying to create an object with a `RadioButtonWidget` type, like we might in an object-oriented UI framework,
+we create an entity with all of the components required to accomplish the desired behavior.
+Think of components as behaving in an analogous fashion to traits, with the radio button behavior having trait bounds for each of the required components.
+
+Breaking it down into the constituents, we want our radio button to BEHAVIORS.
+
+Turning this into code, we get a `RadioButton` component and a couple of supporting systems.
+
+```rust
+struct RadioButton {
+  // These can't be pub fields, and instead must rely on accessor methods 
+  // to ensure internal invariants hold
+  options: Vec<Label> // TODO: do we need to define what exactly a label would look like here?
+  state: Label,
+}
+
+// TODO: complete me
+fn render_radio_buttons(){
+
+}
+
+// TODO: complete me
+fn handle_radio_button_input(){
+
+}
+```
+
+### Widget wiring
+
+Widgets can be wired to each other and the game state in two common ways:
+
+1. Directly reading the state of our widget's components.
+2. Using the **components-as-event-channel** pattern to listen to events emitted by specific widget components.
+By storing `Events` in our components, we can mimic the idea of "event channels",
+allowing users to quickly differentiate between various events of the same type based on where they came from.
+
+Read the component's state when you care about its current state, use event channels when you want to detect events being fired off.
+This is clearer with an example:
+
+```rust
+// TODO: complete me
+```
+
+### System resolution
+
+When attempting to control UI behavior through our ECS, we are forced to confront the challenge of **system resolution** head-on.
+This, in a nutshell, is the notion that we want our relevant collection of systems to be "at rest" before advancing on to the next part of our data pipeline.
+
+While this problem is not *unique* to UI (complex event-based gameplay logic can encounter it too),
+it is particularly prevalent in UI due to the large number of heterogenous parts communicating in unpredictable ways.
+
+At first, one may be determined to resolve this through careful system ordering.
+Simply trace out the pathways your data could flow, and make sure those systems resolve before their dependencies.
+While this may get unwieldy in complex UIs, you can solve the problem without any complex data structures.
+
+But cyclic dependencies, which are reasonably common in any complex enough system, foil our plans.
+Suppose we have one widget which when interacted with talks to a second widget.
+The second widget then (perhaps through some complex chain of events) modifies the first widget again before eventually the chain terminates.
+No matter the order of our systems, we cannot fully resolve this in a single pass of each system.
+
+TODO: why not just render things in motion?
+
+TODO: present solution.
+
+## Reference-level explanation
+
+TODO: complete me.
+
+This is the technical portion of the RFC. Explain the design in sufficient detail that:
+
+- Its interaction with other features is clear.
+- It is reasonably clear how the feature would be implemented.
+- Corner cases are dissected by example.
+
+The section should return to the examples given in the previous section, and explain more fully how the detailed proposal makes those examples work.
+
+## Drawbacks
+
+1. An ECS-first UI is unexplored territory; we may encounter serious unknown-unknowns.
+2. Debugging inter-widget communication may be complex. This is true in virtually all cases though.
+3. Solving the "event propagation" problem within the ECS will force us to build out new abstractions or improve existing ones.
+4. This pattern creates many, many systems, most of which will do nothing in most passes. This constraints
+5. A good implementation of the signal-connection relies on relations.
+
+## Rationale and alternatives
+
+### Why ECS-powered UI?
+
+TODO: complete me.
+
+### Widget wiring
+
+TODO: complete me.
+
+### Widget behavior
+
+TODO: complete me.
+
+## Unresolved questions
+
+1. What does input handling look like? How do we ensure it's robust to multiple input paradigms?
+2. How do we ensure that signals are fully propagated before advancing?
+
+## Future possibilities
+
+1. Archetype invariants #5 will be very useful to reduce bugs while building functional widgets, to ensure that all of the required systems will run correctly on them.
+2. The widget wiring solution is much better handled with relations.

From 7a73dcc01be6d6a620b267a5568f5d590c0edb07 Mon Sep 17 00:00:00 2001
From: Alice Cecile <alice.i.cecile@gmail.com>
Date: Thu, 15 Apr 2021 18:08:38 -0400
Subject: [PATCH 02/16] More discussion of the system resolution problem

---
 rfcs/system-driven-ui.md | 50 ++++++++++++++++++++++++++--------------
 1 file changed, 33 insertions(+), 17 deletions(-)

diff --git a/rfcs/system-driven-ui.md b/rfcs/system-driven-ui.md
index 40fd8f3f..e1feb16c 100644
--- a/rfcs/system-driven-ui.md
+++ b/rfcs/system-driven-ui.md
@@ -63,26 +63,14 @@ This is clearer with an example:
 // TODO: complete me
 ```
 
-### System resolution
-
-When attempting to control UI behavior through our ECS, we are forced to confront the challenge of **system resolution** head-on.
-This, in a nutshell, is the notion that we want our relevant collection of systems to be "at rest" before advancing on to the next part of our data pipeline.
-
-While this problem is not *unique* to UI (complex event-based gameplay logic can encounter it too),
-it is particularly prevalent in UI due to the large number of heterogenous parts communicating in unpredictable ways.
-
-At first, one may be determined to resolve this through careful system ordering.
-Simply trace out the pathways your data could flow, and make sure those systems resolve before their dependencies.
-While this may get unwieldy in complex UIs, you can solve the problem without any complex data structures.
+### Strategies for system resolution
 
-But cyclic dependencies, which are reasonably common in any complex enough system, foil our plans.
-Suppose we have one widget which when interacted with talks to a second widget.
-The second widget then (perhaps through some complex chain of events) modifies the first widget again before eventually the chain terminates.
-No matter the order of our systems, we cannot fully resolve this in a single pass of each system.
+When implementing your own systems that control the UI, you need to be mindful that all UI logic is concluded (**at rest**, in contrast to **in motion**)
+before advancing to other parts of the game logic or rendering.
 
-TODO: why not just render things in motion?
+Failing to do so can result in strange bugs, unpleasant input delays and flickering UIs (see the corresponding section on system resolution below).
 
-TODO: present solution.
+TODO: describe solution.
 
 ## Reference-level explanation
 
@@ -118,6 +106,34 @@ TODO: complete me.
 
 TODO: complete me.
 
+### System resolution
+
+When attempting to control UI behavior through our ECS, we are forced to confront the challenge of **system resolution** head-on.
+This, in a nutshell, is the notion that we want our relevant collection of systems to be "at rest" before advancing on to the next part of our data pipeline.
+
+While this problem is not *unique* to UI (complex event-based gameplay logic can encounter it too),
+it is particularly prevalent in UI due to the large number of heterogenous parts communicating in unpredictable ways.
+
+At first, one may be determined to resolve this through careful system ordering.
+Simply trace out the pathways your data could flow, and make sure those systems resolve before their dependencies.
+While this may get unwieldy in complex UIs, you can solve the problem without any complex data structures.
+
+But cyclic dependencies, which are reasonably common in any complex enough system, foil our plans.
+Suppose we have one widget which when interacted with talks to a second widget.
+The second widget then (perhaps through some complex chain of events) modifies the first widget again before eventually the chain terminates.
+No matter the order of our systems, we cannot fully resolve this in a single pass of each system.
+
+Presented with such a conundrum, we might throw up our hands and ask "Why not just move on, and render things in motion? What's the worst that could happen?"
+Unfortunately, a wide range of unpleasant things:
+
+1. Invalid state. TODO: expand.
+2. Responsiveness issues. TODO: expand.
+3. Flickering graphical representations. TODO: expand.
+
+Accepting that these are dire enough that we should avoid them, what does a good solution look like, and what are our options to get there?
+
+TODO: discuss potential solutions
+
 ## Unresolved questions
 
 1. What does input handling look like? How do we ensure it's robust to multiple input paradigms?

From 268ba5054ee6bb84dad81e1689f90954a3ef165a Mon Sep 17 00:00:00 2001
From: Alice Cecile <alice.i.cecile@gmail.com>
Date: Thu, 15 Apr 2021 18:28:08 -0400
Subject: [PATCH 03/16] Why should we use systems to control behavior?

---
 rfcs/system-driven-ui.md | 18 +++++++++++-------
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/rfcs/system-driven-ui.md b/rfcs/system-driven-ui.md
index e1feb16c..0bf8dfab 100644
--- a/rfcs/system-driven-ui.md
+++ b/rfcs/system-driven-ui.md
@@ -94,15 +94,18 @@ The section should return to the examples given in the previous section, and exp
 
 ## Rationale and alternatives
 
-### Why ECS-powered UI?
+### Why do we want to be able to control UI behavior with systems?
 
-TODO: complete me.
+UI widgets should be entities with various components (see #1 and **Motivation**).
+With that established, we need to be able to easily extract data from the ECS, and operate on it in complex, user-extensible ways.
+In Bevy, this implies the use of systems.
 
-### Widget wiring
+When implementing UI behavior in the ECS, the system resolution and widget wiring problems are far and away the most complex challenges to be solved.
+Unfortunately, they are from unique to the UI problem domain, even if they rarely appear in trivial demo games.
+We need good, ergonomic solutions to them (whether these are features or design patterns) in any case.
+UI is a great proving ground for these solutions due to its high complexity, tight constraints and shared requirements across many projects.
 
-TODO: complete me.
-
-### Widget behavior
+### Widget wiring
 
 TODO: complete me.
 
@@ -137,7 +140,8 @@ TODO: discuss potential solutions
 ## Unresolved questions
 
 1. What does input handling look like? How do we ensure it's robust to multiple input paradigms?
-2. How do we ensure that signals are fully propagated before advancing?
+2. What exact API and semantics do we want for the components-as-event-channels pattern?
+3. How do we solve the system resolution problem?
 
 ## Future possibilities
 

From e8e333a033655dbbb09ac70c36298021ef061186 Mon Sep 17 00:00:00 2001
From: Alice Cecile <alice.i.cecile@gmail.com>
Date: Thu, 15 Apr 2021 20:38:24 -0400
Subject: [PATCH 04/16] Removed system resolution section

Could not find compelling examples that justify the extreme complexity
---
 rfcs/system-driven-ui.md | 41 +---------------------------------------
 1 file changed, 1 insertion(+), 40 deletions(-)

diff --git a/rfcs/system-driven-ui.md b/rfcs/system-driven-ui.md
index 0bf8dfab..581bbdfc 100644
--- a/rfcs/system-driven-ui.md
+++ b/rfcs/system-driven-ui.md
@@ -47,8 +47,6 @@ fn handle_radio_button_input(){
 }
 ```
 
-### Widget wiring
-
 Widgets can be wired to each other and the game state in two common ways:
 
 1. Directly reading the state of our widget's components.
@@ -63,15 +61,6 @@ This is clearer with an example:
 // TODO: complete me
 ```
 
-### Strategies for system resolution
-
-When implementing your own systems that control the UI, you need to be mindful that all UI logic is concluded (**at rest**, in contrast to **in motion**)
-before advancing to other parts of the game logic or rendering.
-
-Failing to do so can result in strange bugs, unpleasant input delays and flickering UIs (see the corresponding section on system resolution below).
-
-TODO: describe solution.
-
 ## Reference-level explanation
 
 TODO: complete me.
@@ -109,39 +98,11 @@ UI is a great proving ground for these solutions due to its high complexity, tig
 
 TODO: complete me.
 
-### System resolution
-
-When attempting to control UI behavior through our ECS, we are forced to confront the challenge of **system resolution** head-on.
-This, in a nutshell, is the notion that we want our relevant collection of systems to be "at rest" before advancing on to the next part of our data pipeline.
-
-While this problem is not *unique* to UI (complex event-based gameplay logic can encounter it too),
-it is particularly prevalent in UI due to the large number of heterogenous parts communicating in unpredictable ways.
-
-At first, one may be determined to resolve this through careful system ordering.
-Simply trace out the pathways your data could flow, and make sure those systems resolve before their dependencies.
-While this may get unwieldy in complex UIs, you can solve the problem without any complex data structures.
-
-But cyclic dependencies, which are reasonably common in any complex enough system, foil our plans.
-Suppose we have one widget which when interacted with talks to a second widget.
-The second widget then (perhaps through some complex chain of events) modifies the first widget again before eventually the chain terminates.
-No matter the order of our systems, we cannot fully resolve this in a single pass of each system.
-
-Presented with such a conundrum, we might throw up our hands and ask "Why not just move on, and render things in motion? What's the worst that could happen?"
-Unfortunately, a wide range of unpleasant things:
-
-1. Invalid state. TODO: expand.
-2. Responsiveness issues. TODO: expand.
-3. Flickering graphical representations. TODO: expand.
-
-Accepting that these are dire enough that we should avoid them, what does a good solution look like, and what are our options to get there?
-
-TODO: discuss potential solutions
-
 ## Unresolved questions
 
 1. What does input handling look like? How do we ensure it's robust to multiple input paradigms?
 2. What exact API and semantics do we want for the components-as-event-channels pattern?
-3. How do we solve the system resolution problem?
+3. Do circular system dependencies actually exist in real UI use-cases?
 
 ## Future possibilities
 

From 45c13ecb50c8d134f7e73dcc48309ba3eaef6ca8 Mon Sep 17 00:00:00 2001
From: Alice Cecile <alice.i.cecile@gmail.com>
Date: Thu, 15 Apr 2021 20:39:52 -0400
Subject: [PATCH 05/16] Add advice on how to combine UI events in a chain

---
 rfcs/system-driven-ui.md | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/rfcs/system-driven-ui.md b/rfcs/system-driven-ui.md
index 581bbdfc..cdcca9a6 100644
--- a/rfcs/system-driven-ui.md
+++ b/rfcs/system-driven-ui.md
@@ -61,6 +61,10 @@ This is clearer with an example:
 // TODO: complete me
 ```
 
+When building UI logic that requires chains of events triggering one after another, you should be careful to ensure that upstream systems are processed earlier in the game-loop than their downstream systems.
+Failing to do so properly may result in invalid state, input lag or visual flickering.
+Standard system ordering tools (e.g. `.before()` and `.after()`) work well for this.
+
 ## Reference-level explanation
 
 TODO: complete me.

From 6981b6fb43fdc94d5c0ac50b523791209d9839e4 Mon Sep 17 00:00:00 2001
From: Alice <alice.i.cecile@gmail.com>
Date: Fri, 16 Apr 2021 13:27:32 -0400
Subject: [PATCH 06/16] Added examples, removed event-channels pattern

---
 rfcs/system-driven-ui.md | 66 ++++++++++++++++++++++++++++++++++++----
 1 file changed, 60 insertions(+), 6 deletions(-)

diff --git a/rfcs/system-driven-ui.md b/rfcs/system-driven-ui.md
index cdcca9a6..a16879c6 100644
--- a/rfcs/system-driven-ui.md
+++ b/rfcs/system-driven-ui.md
@@ -50,15 +50,69 @@ fn handle_radio_button_input(){
 Widgets can be wired to each other and the game state in two common ways:
 
 1. Directly reading the state of our widget's components.
-2. Using the **components-as-event-channel** pattern to listen to events emitted by specific widget components.
-By storing `Events` in our components, we can mimic the idea of "event channels",
-allowing users to quickly differentiate between various events of the same type based on where they came from.
+2. Using events emitted by interacting with the widgets. 
 
 Read the component's state when you care about its current state, use event channels when you want to detect events being fired off.
-This is clearer with an example:
+
+As you move beyond trivial UIs, you may need to disambiguate between multiple widgets of the same type.
+To do so, isolate the correct widget's state using marker components.
+
+As your widgets grow further, you may want to scale this pattern dynamically, rather than relying on specific marker components.
+To do so, your consuming systems should point to other widgets directly, by storing references to their `Entity` identifier.
+
+Let's take a look at each of these patterns with some examples:
 
 ```rust
-// TODO: complete me
+// In this example, we're wiring up our logic directly to the state of our singleton widget
+fn set_background_color(color_selector_query: Query<&ColorSelector>, bg_color: ResMut<ClearColor>){
+  let color = color_selector_query.single().unwrap();
+  *bg_color = color;
+}
+
+// This is a trivial example of how you might listen to an event emitted by a widget's interactions
+fn hello_button(button_events: EventReader<ButtonEvent>){
+  for _ in button_events.iter(){
+    info!("Hello!");
+  }
+}
+
+// Sometimes, the correct behavior may be to simply mirror UI state into a resource
+// Then access that for downstream systems
+fn dark_mode_toggle(query: Query<&Toggle, With<LighDarkWidget>>, mut state: ResMut<State<LightDarkMode>>){
+  // This example extends the light-dark mode example in PR #1: UI styling
+  let toggle = query.single().unwrap();
+
+  state.active() = match toggle{
+    true => LightDarkMode::Dark,
+    false => LightDarkMode::Light
+  }
+}
+
+// Here, we're disambiguating between multiple widgets with a Selector by using a marker component
+fn build_unit(
+  mut commands: Commands,
+  build_events: EventRader<BuildEvent>, 
+  selector_query: Query<&Selector, With<BuildSelector>>){
+    
+    let unit_type = selector_query.single().unwrap().unit_type;
+    for event in build_events.iter(){
+      commands.spawn()
+        .insert_bundle(UnitBundle::new(unit_type))
+        .insert(Transform{event.transform});
+    }
+}
+
+// In this example, we have many similar UI elements
+// and we're looking to control the state of the corresponding UI entity
+// Note that we're using a game data -> UI data flow here
+fn update_healthbars(unit_query: Query<(&CurrentHealth, &MaxHealth, &Transform, &HealthBarEntity), Without<Widget>>, 
+  mut healthbar_query: Query<(&mut FillingBar, &mut Transform), With<Widget>>){
+    for (current, max, transform, hb_entity) in unit_query.iter(){
+      let mut (hb_bar, hb_transform) = healthbar_query.get(hb_entity).unwrap();
+      *hb_bar = health_to_bar(current, max);
+      *hb_transform = offset_health_bar(transform);
+    }
+}
 ```
 
 When building UI logic that requires chains of events triggering one after another, you should be careful to ensure that upstream systems are processed earlier in the game-loop than their downstream systems.
@@ -105,7 +159,7 @@ TODO: complete me.
 ## Unresolved questions
 
 1. What does input handling look like? How do we ensure it's robust to multiple input paradigms?
-2. What exact API and semantics do we want for the components-as-event-channels pattern?
+2. Are there compelling use cases for the components-as-event-channels pattern?
 3. Do circular system dependencies actually exist in real UI use-cases?
 
 ## Future possibilities

From b7a39ceba926584a5e52793ffc12d70ac2717e9b Mon Sep 17 00:00:00 2001
From: TheRawMeatball <therawmeatball@gmail.com>
Date: Sat, 17 Apr 2021 19:28:42 +0300
Subject: [PATCH 07/16] Run the code through rustfmt

---
 rfcs/system-driven-ui.md | 80 ++++++++++++++++++++--------------------
 1 file changed, 41 insertions(+), 39 deletions(-)

diff --git a/rfcs/system-driven-ui.md b/rfcs/system-driven-ui.md
index a16879c6..b466fa4a 100644
--- a/rfcs/system-driven-ui.md
+++ b/rfcs/system-driven-ui.md
@@ -30,21 +30,17 @@ Turning this into code, we get a `RadioButton` component and a couple of support
 
 ```rust
 struct RadioButton {
-  // These can't be pub fields, and instead must rely on accessor methods 
-  // to ensure internal invariants hold
-  options: Vec<Label> // TODO: do we need to define what exactly a label would look like here?
-  state: Label,
+    // These can't be pub fields, and instead must rely on accessor methods
+    // to ensure internal invariants hold
+    options: Vec<Label>, // TODO: do we need to define what exactly a label would look like here?
+    state: Label,
 }
 
 // TODO: complete me
-fn render_radio_buttons(){
-
-}
+fn render_radio_buttons() {}
 
 // TODO: complete me
-fn handle_radio_button_input(){
-
-}
+fn handle_radio_button_input() {}
 ```
 
 Widgets can be wired to each other and the game state in two common ways:
@@ -64,53 +60,59 @@ Let's take a look at each of these patterns with some examples:
 
 ```rust
 // In this example, we're wiring up our logic directly to the state of our singleton widget
-fn set_background_color(color_selector_query: Query<&ColorSelector>, bg_color: ResMut<ClearColor>){
-  let color = color_selector_query.single().unwrap();
-  *bg_color = color;
+fn set_background_color(color_selector_query: Query<&ColorSelector>, bg_color: ResMut<ClearColor>) {
+    let color = color_selector_query.single().unwrap();
+    *bg_color = color;
 }
 
 // This is a trivial example of how you might listen to an event emitted by a widget's interactions
-fn hello_button(button_events: EventReader<ButtonEvent>){
-  for _ in button_events.iter(){
-    info!("Hello!");
-  }
+fn hello_button(button_events: EventReader<ButtonEvent>) {
+    for _ in button_events.iter() {
+        info!("Hello!");
+    }
 }
 
 // Sometimes, the correct behavior may be to simply mirror UI state into a resource
 // Then access that for downstream systems
-fn dark_mode_toggle(query: Query<&Toggle, With<LighDarkWidget>>, mut state: ResMut<State<LightDarkMode>>){
-  // This example extends the light-dark mode example in PR #1: UI styling
-  let toggle = query.single().unwrap();
-
-  state.active() = match toggle{
-    true => LightDarkMode::Dark,
-    false => LightDarkMode::Light
-  }
+fn dark_mode_toggle(
+    query: Query<&Toggle, With<LighDarkWidget>>,
+    mut state: ResMut<State<LightDarkMode>>,
+) {
+    // This example extends the light-dark mode example in PR #1: UI styling
+    let toggle = query.single().unwrap();
+
+    state.active() = match toggle {
+        true => LightDarkMode::Dark,
+        false => LightDarkMode::Light,
+    }
 }
 
 // Here, we're disambiguating between multiple widgets with a Selector by using a marker component
 fn build_unit(
-  mut commands: Commands,
-  build_events: EventRader<BuildEvent>, 
-  selector_query: Query<&Selector, With<BuildSelector>>){
-    
+    mut commands: Commands,
+    build_events: EventRader<BuildEvent>,
+    selector_query: Query<&Selector, With<BuildSelector>>,
+) {
     let unit_type = selector_query.single().unwrap().unit_type;
-    for event in build_events.iter(){
-      commands.spawn()
-        .insert_bundle(UnitBundle::new(unit_type))
-        .insert(Transform{event.transform});
+    for event in build_events.iter() {
+        commands
+            .spawn()
+            .insert_bundle(UnitBundle::new(unit_type))
+            .insert(event.transform.clone());
     }
 }
 
 // In this example, we have many similar UI elements
 // and we're looking to control the state of the corresponding UI entity
 // Note that we're using a game data -> UI data flow here
-fn update_healthbars(unit_query: Query<(&CurrentHealth, &MaxHealth, &Transform, &HealthBarEntity), Without<Widget>>, 
-  mut healthbar_query: Query<(&mut FillingBar, &mut Transform), With<Widget>>){
-    for (current, max, transform, hb_entity) in unit_query.iter(){
-      let mut (hb_bar, hb_transform) = healthbar_query.get(hb_entity).unwrap();
-      *hb_bar = health_to_bar(current, max);
-      *hb_transform = offset_health_bar(transform);
+fn update_healthbars(
+    unit_query: Query<(&CurrentHealth, &MaxHealth, &Transform, &HealthBarEntity), Without<Widget>>,
+    mut healthbar_query: Query<(&mut FillingBar, &mut Transform), With<Widget>>,
+) {
+    for (current, max, transform, hb_entity) in unit_query.iter() {
+        let (mut hb_bar, mut hb_transform) = healthbar_query.get(hb_entity).unwrap();
+        *hb_bar = health_to_bar(current, max);
+        *hb_transform = offset_health_bar(transform);
     }
 }
 ```

From 4cfa1219649b3236e8887ba9671466ad66b4c953 Mon Sep 17 00:00:00 2001
From: Alice Cecile <alice.i.cecile@gmail.com>
Date: Tue, 20 Apr 2021 18:30:45 -0400
Subject: [PATCH 08/16] Discussed polling vs. event-driven UI in drawbacks

---
 rfcs/system-driven-ui.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/rfcs/system-driven-ui.md b/rfcs/system-driven-ui.md
index b466fa4a..9fde027b 100644
--- a/rfcs/system-driven-ui.md
+++ b/rfcs/system-driven-ui.md
@@ -136,9 +136,9 @@ The section should return to the examples given in the previous section, and exp
 ## Drawbacks
 
 1. An ECS-first UI is unexplored territory; we may encounter serious unknown-unknowns.
-2. Debugging inter-widget communication may be complex. This is true in virtually all cases though.
+2. Debugging inter-widget communication may be complex. This is true regardless of paradigm though.
 3. Solving the "event propagation" problem within the ECS will force us to build out new abstractions or improve existing ones.
-4. This pattern creates many, many systems, most of which will do nothing in most passes. This constraints
+4. While change detection + query caching severely reduces the performance cost of our classical "polling" (as opposed to "event-driven") UI approach, we create many, many systems, most of which will do nothing in most passes. We must be careful not to heavily regress the base cost of running systems as a result.
 5. A good implementation of the signal-connection relies on relations.
 
 ## Rationale and alternatives

From 3f413a3b05954802dbc0119aa0c913f39d4a655b Mon Sep 17 00:00:00 2001
From: Alice Cecile <alice.i.cecile@gmail.com>
Date: Tue, 20 Apr 2021 18:32:31 -0400
Subject: [PATCH 09/16] Discussed pausing problem with events

---
 rfcs/system-driven-ui.md | 1 +
 1 file changed, 1 insertion(+)

diff --git a/rfcs/system-driven-ui.md b/rfcs/system-driven-ui.md
index 9fde027b..05da2fa8 100644
--- a/rfcs/system-driven-ui.md
+++ b/rfcs/system-driven-ui.md
@@ -140,6 +140,7 @@ The section should return to the examples given in the previous section, and exp
 3. Solving the "event propagation" problem within the ECS will force us to build out new abstractions or improve existing ones.
 4. While change detection + query caching severely reduces the performance cost of our classical "polling" (as opposed to "event-driven") UI approach, we create many, many systems, most of which will do nothing in most passes. We must be careful not to heavily regress the base cost of running systems as a result.
 5. A good implementation of the signal-connection relies on relations.
+6. Using Bevy-events as part of this pattern will interact poorly with pausing due to lost events until https://github.com/bevyengine/bevy/pull/1776 or a similar approach is merged.
 
 ## Rationale and alternatives
 

From 28765eb8b7c6ce12624d57a8593f8f20753b6d65 Mon Sep 17 00:00:00 2001
From: Alice Cecile <alice.i.cecile@gmail.com>
Date: Wed, 21 Apr 2021 17:46:41 -0400
Subject: [PATCH 10/16] Improved rationale and alternatives

---
 rfcs/system-driven-ui.md | 26 ++++++++++++++++++++------
 1 file changed, 20 insertions(+), 6 deletions(-)

diff --git a/rfcs/system-driven-ui.md b/rfcs/system-driven-ui.md
index 05da2fa8..0c2759da 100644
--- a/rfcs/system-driven-ui.md
+++ b/rfcs/system-driven-ui.md
@@ -150,14 +150,28 @@ UI widgets should be entities with various components (see #1 and **Motivation**
 With that established, we need to be able to easily extract data from the ECS, and operate on it in complex, user-extensible ways.
 In Bevy, this implies the use of systems.
 
-When implementing UI behavior in the ECS, the system resolution and widget wiring problems are far and away the most complex challenges to be solved.
-Unfortunately, they are from unique to the UI problem domain, even if they rarely appear in trivial demo games.
-We need good, ergonomic solutions to them (whether these are features or design patterns) in any case.
-UI is a great proving ground for these solutions due to its high complexity, tight constraints and shared requirements across many projects.
+By automatically handling widget-logic in modular systems, we:
 
-### Widget wiring
+1. Make sure it's easy to extend and customize widgets without losing functionality.
+2. Enable a data-driven workflow: adding the correct components to your widgets will cause it to automatically work.
+3. Have great performance when operating over large numbers of similar widgets at once.
+4. Avoid complex widget hierarchies by using composition over inheritance.
 
-TODO: complete me.
+### Why is using a polling model okay?
+
+TODO: flesh out.
+
+Less indirection.
+
+Low overhead.
+
+Automatic parallelization.
+
+Change detection.
+
+### Why not use callbacks?
+
+TODO: write.
 
 ## Unresolved questions
 

From 7529cff160d6ddcae081529f99b650cbe4e85ae9 Mon Sep 17 00:00:00 2001
From: Alice Cecile <alice.i.cecile@gmail.com>
Date: Wed, 21 Apr 2021 19:22:48 -0400
Subject: [PATCH 11/16] Briefly mentioned OrbTk as prior art

---
 rfcs/system-driven-ui.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/rfcs/system-driven-ui.md b/rfcs/system-driven-ui.md
index 0c2759da..913ae46e 100644
--- a/rfcs/system-driven-ui.md
+++ b/rfcs/system-driven-ui.md
@@ -135,7 +135,7 @@ The section should return to the examples given in the previous section, and exp
 
 ## Drawbacks
 
-1. An ECS-first UI is unexplored territory; we may encounter serious unknown-unknowns.
+1. An ECS-first UI is largely unexplored territory (but see [OrbTk](https://github.com/redox-os/orbtk)); we may encounter serious unknown-unknowns.
 2. Debugging inter-widget communication may be complex. This is true regardless of paradigm though.
 3. Solving the "event propagation" problem within the ECS will force us to build out new abstractions or improve existing ones.
 4. While change detection + query caching severely reduces the performance cost of our classical "polling" (as opposed to "event-driven") UI approach, we create many, many systems, most of which will do nothing in most passes. We must be careful not to heavily regress the base cost of running systems as a result.

From 1a3fdeda081fdce425351439231265415c96b3b3 Mon Sep 17 00:00:00 2001
From: Alice Cecile <alice.i.cecile@gmail.com>
Date: Wed, 21 Apr 2021 19:52:51 -0400
Subject: [PATCH 12/16] Restructured draft around UI data flow

---
 rfcs/system-driven-ui.md | 143 +++++++++++++++++++++++++++++++++------
 1 file changed, 123 insertions(+), 20 deletions(-)

diff --git a/rfcs/system-driven-ui.md b/rfcs/system-driven-ui.md
index 913ae46e..2e7a2b2d 100644
--- a/rfcs/system-driven-ui.md
+++ b/rfcs/system-driven-ui.md
@@ -15,8 +15,33 @@ By controlling the behavior of our widgets with components and systems, we can s
 
 ## Guide-level explanation
 
+The **UI data flow** in Bevy has four conceptual stages:
+
+1. Dispatching raw input events to specific widgets.
+2. Handling raw input events by converting into widget-specific events.
+3. Responding to widget-specific events with widget logic.
+4. Reading UI state.
+
 Widgets, as previously discussed in [UI Building Blocks and Styles](https://github.com/bevyengine/rfcs/pull/1) are simply entities with various components on them.
-Rather than merely controlling the cosmetic style of our widgets, we can attach **functional components** to our widgets as well.
+As discussed there, Bevy does not draw a hard-line between "UI" and "not UI"; these concepts and patterns are also useful for handling input to game entities.
+
+### Dispatching input to widgets
+
+TODO: expand.
+
+Every widget that you can interact with has the `Interactable` marker component,
+which allows for input events (such as mouse, keyboard, joystick or touch events) to be dispatched to the right widget in order to trigger behavior.
+When a widget is selected, it has the `Selected` marker component.
+You can control the order in which widgets are selected (e.g. by tabbing through the options) by modifying the `SelectionOrder` resource.
+Modify the `SelectionGrouping` resource in order to control which widgets can be selected together.
+
+### Handling inputs
+
+TODO: write.
+
+### Widget logic
+
+TODO: complete.
 
 Just like when we're using the ECS to control our game's logic, these components both store data and control behavior, by determining which systems apply to each particular `Widget` entity.
 Suppose we want to create a radio-button widget.
@@ -24,29 +49,41 @@ Rather than trying to create an object with a `RadioButtonWidget` type, like we
 we create an entity with all of the components required to accomplish the desired behavior.
 Think of components as behaving in an analogous fashion to traits, with the radio button behavior having trait bounds for each of the required components.
 
-Breaking it down into the constituents, we want our radio button to BEHAVIORS.
+Breaking it down into the constituents, we want our radio button to:
+
+1. Store internal state in an accessible way.
+2. Respond to input.
+3. Be rendered into several radio buttons.
 
-Turning this into code, we get a `RadioButton` component and a couple of supporting systems.
+Turning this into code, we get a `RadioButtons` component and a couple of supporting systems.
 
 ```rust
-struct RadioButton {
+struct RadioButtons {
     // These can't be pub fields, and instead must rely on accessor methods
-    // to ensure internal invariants hold
-    options: Vec<Label>, // TODO: do we need to define what exactly a label would look like here?
-    state: Label,
+    // to ensure internal invariants (like only state is one of options) hold
+    options: Vec<Text>,
+    state: Text,
 }
 
 // TODO: complete me
-fn render_radio_buttons() {}
+fn handle_radio_button_input(radio_queries: ) {}
+
 
 // TODO: complete me
-fn handle_radio_button_input() {}
+fn render_radio_buttons(query: Query<&RadioButton, &mut Sprite, >) {
+
+}
+
 ```
 
+### Reading UI state
+
+TODO: refresh.
+
 Widgets can be wired to each other and the game state in two common ways:
 
 1. Directly reading the state of our widget's components.
-2. Using events emitted by interacting with the widgets. 
+2. Using events emitted by interacting with the widgets.
 
 Read the component's state when you care about its current state, use event channels when you want to detect events being fired off.
 
@@ -123,15 +160,81 @@ Standard system ordering tools (e.g. `.before()` and `.after()`) work well for t
 
 ## Reference-level explanation
 
-TODO: complete me.
+### Dispatching input to widgets
+
+TODO: complete and clean up. Needs architecture help still :/
+
+In order to unify various input methods, handle overlapping widgets, and avoid duplicating work, we need a central approach to UI dispatching.
+UI events have two core fields:
+
+1. What is being interacted with?
+   1. Screen-space coordinates.
+    Used for mouse, touch and joystick selectors.
+    Note that world-space UI elements may be dispatched to in this way as well, requiring recomputation whenever they move or the camera changes.
+   2. Selected UI elements.
+    Commonly used for keyboard control.
+2. What signal is being sent?
+
+During dispatching, we must unify these signals across the various input streams, and convert them into logic that our widgets can understand,
+stored as events on a component of the widget itself.
+Finally, our widgets can take their new unified event stream and process it independently in their own systems.
 
-This is the technical portion of the RFC. Explain the design in sufficient detail that:
+```rust
+pub struct InteractableMap {
+    // Contains some data structure that allows us to efficiently map screen space coordinates to a UI widget
+    // This is probably done with a pixel-resolution array
+}
+
+impl InteractableMap(){
+    pub fn get_from_coordinates(&self, position: &GlobalTransform) -> Entity {
+        // Uses this data structure to map between screen space to a UI widget
+    }
+
+    // Analagous function for keyboard / gamepad buttons
+
+    // 
+}
+
+// The Bounds component doesn't exist yet; it should be a tight polygon around the object in a 2D plane, using screen-space coordinates
+// Screen-space bounds would be constant; world-space bounds need to be updated when the UI changes
+fn build_interactable_map(
+    // PERF: this should be done using change detection and iterative rebuilding from Bounds instead
+    world_space_query: Query<(&Bounds), (Without<ScreenSpace>, With<Interactable>)>,
+    screen_space_query: Query<(&Bounds), (With<ScreenSpace>, With<Interactable>)>, map: ResMut<InteractableMap>){
+    
+    // Sort bounds by distance to camera, with further bounds being applied first
+    // New bounds overwrite old bounds because they're "on top"
+
+    // Apply the world-space bounds first
+
+    // Screen-space bounds overwrite any world-space bounds
+}
+
+// We need one of these systems for each input event type we want to support
+// This uses NYI trait queries; other more elegant designs are welcome
+fn handle_coordinate_input<E>(query: Query<(&mut impl EventHandler<E>, impl WidgetEvents) With<Interactable>>, input_events: EventReader<E>,
+    map: Res<InteractableMap>){
+
+    for input_event in input_events.iter(){
+
+    }
+
+    for event_handler, mut widget_input_events in query.iter_mut(){
+        // This method is customized to each widget / widget type and converts input events into a common widget-logic format
+        let new_events = event_handler.handle();
+
+        // These events are later processed in widget-specific systems
+        widget_input_events.push(new_events);
+    }
+}
+
+```
 
-- Its interaction with other features is clear.
-- It is reasonably clear how the feature would be implemented.
-- Corner cases are dissected by example.
+### Customizing interaction behavior
 
-The section should return to the examples given in the previous section, and explain more fully how the detailed proposal makes those examples work.
+Control iteration order.
+Binding to hotkeys.
+Multi-select.
 
 ## Drawbacks
 
@@ -140,7 +243,7 @@ The section should return to the examples given in the previous section, and exp
 3. Solving the "event propagation" problem within the ECS will force us to build out new abstractions or improve existing ones.
 4. While change detection + query caching severely reduces the performance cost of our classical "polling" (as opposed to "event-driven") UI approach, we create many, many systems, most of which will do nothing in most passes. We must be careful not to heavily regress the base cost of running systems as a result.
 5. A good implementation of the signal-connection relies on relations.
-6. Using Bevy-events as part of this pattern will interact poorly with pausing due to lost events until https://github.com/bevyengine/bevy/pull/1776 or a similar approach is merged.
+6. Using Bevy-events as part of this pattern will interact poorly with pausing due to lost events until [bevy #1776](https://github.com/bevyengine/bevy/pull/1776) or a similar approach is merged.
 
 ## Rationale and alternatives
 
@@ -175,11 +278,11 @@ TODO: write.
 
 ## Unresolved questions
 
-1. What does input handling look like? How do we ensure it's robust to multiple input paradigms?
-2. Are there compelling use cases for the components-as-event-channels pattern?
+1. What are the details for input dispatching?
+2. Can we unify our input event streams more elegantly?
 3. Do circular system dependencies actually exist in real UI use-cases?
 
 ## Future possibilities
 
 1. Archetype invariants #5 will be very useful to reduce bugs while building functional widgets, to ensure that all of the required systems will run correctly on them.
-2. The widget wiring solution is much better handled with relations.
+2. Relations will significantly improve the ergonomics of many of these patterns where we point to / store specific widget entities.

From 0b25784205361022edd80110105cf5e74d2a5b12 Mon Sep 17 00:00:00 2001
From: Alice Cecile <alice.i.cecile@gmail.com>
Date: Wed, 21 Apr 2021 22:40:51 -0400
Subject: [PATCH 13/16] Motivation for central input dispatch

---
 rfcs/system-driven-ui.md | 44 +++++++++++++++++++++++++++++++---------
 1 file changed, 34 insertions(+), 10 deletions(-)

diff --git a/rfcs/system-driven-ui.md b/rfcs/system-driven-ui.md
index 2e7a2b2d..80985e7e 100644
--- a/rfcs/system-driven-ui.md
+++ b/rfcs/system-driven-ui.md
@@ -17,28 +17,52 @@ By controlling the behavior of our widgets with components and systems, we can s
 
 The **UI data flow** in Bevy has four conceptual stages:
 
-1. Dispatching raw input events to specific widgets.
-2. Handling raw input events by converting into widget-specific events.
-3. Responding to widget-specific events with widget logic.
-4. Reading UI state.
+1. **Dispatching** raw input events to specific widgets.
+2. **Handling** raw input events by converting into widget-specific events.
+3. **Responding** to widget-specific events with widget logic.
+4. **Reading** UI state.
 
 Widgets, as previously discussed in [UI Building Blocks and Styles](https://github.com/bevyengine/rfcs/pull/1) are simply entities with various components on them.
 As discussed there, Bevy does not draw a hard-line between "UI" and "not UI"; these concepts and patterns are also useful for handling input to game entities.
 
 ### Dispatching input to widgets
 
-TODO: expand.
+Pretty as they may be, user interfaces are ultimately designed to, well, interface with users.
+In Bevy, that means they must listen for **input events**, created by your mouse, keyboard, joystick, touch or hand-rolled hum-to-move input pipeline.
+But once we receive an input event, what are we to make of it?
 
-Every widget that you can interact with has the `Interactable` marker component,
-which allows for input events (such as mouse, keyboard, joystick or touch events) to be dispatched to the right widget in order to trigger behavior.
-When a widget is selected, it has the `Selected` marker component.
-You can control the order in which widgets are selected (e.g. by tabbing through the options) by modifying the `SelectionOrder` resource.
-Modify the `SelectionGrouping` resource in order to control which widgets can be selected together.
+For simple prototypes, it makes sense to take a simple approach: just listen to the event stream you care about directly.
+
+```rust
+fn jump(query: Query<&mut Velocity, With<Player>>, keyboard_input: Res<Input<KeyCode>>) {
+    if keyboard_input.just_pressed(KeyCode::Space) {
+        let mut vel = query.single_mut().unwrap();
+        vel += Velocity::new(0.0, 1.0);
+    }
+}
+```
+
+This feels natural when building out simple gameplay systems, but if you were so inclined, you could extend this out to classical "widget UI", read the mouse's position and then fire off a button event if the mouse was over a button at the time it was clicked.
+
+While refreshingly simple and perfectly modular, this approach runs into some challenges as you attempt to scale it out to more complex games:
+
+1. Your input logic is scattered across your code-base, making writing a rebinding interface very hard.
+2. Supporting multiple input methods (e.g. mouse and hotkeys or gamepad and keyboard) becomes very complex. Do you duplicate these systems? Do you read in two input streams?
+3. Handling input events that rely on information from other entities and systems is very frustrating.
+   1. Consider overlapping clickable UI widgets; you can't rely on a button's position alone to tell you whether it's correct to execute as that section may be covered.
+   2. In game play systems, actors can typically only do one thing at once, or combinations result in different non-additive behavior.
+4. Each system listens to the whole input stream of events. When you have 100 different systems, and they each discard 99% of all candidate input events, this creates unnecessary performance drag.
+
+This is where Bevy's **central input dispatch** comes in.
+
+TODO: explain.
 
 ### Handling inputs
 
 TODO: write.
 
+
+
 ### Widget logic
 
 TODO: complete.

From eaeb16081adf34713d290a705463bca058d473eb Mon Sep 17 00:00:00 2001
From: Alice Cecile <alice.i.cecile@gmail.com>
Date: Wed, 21 Apr 2021 23:33:34 -0400
Subject: [PATCH 14/16] Overview of central input dispatch

---
 rfcs/system-driven-ui.md | 28 +++++++++++++++++-----------
 1 file changed, 17 insertions(+), 11 deletions(-)

diff --git a/rfcs/system-driven-ui.md b/rfcs/system-driven-ui.md
index 80985e7e..2c52751c 100644
--- a/rfcs/system-driven-ui.md
+++ b/rfcs/system-driven-ui.md
@@ -15,18 +15,15 @@ By controlling the behavior of our widgets with components and systems, we can s
 
 ## Guide-level explanation
 
-The **UI data flow** in Bevy has four conceptual stages:
+The **UI data flow** in Bevy has three conceptual stages:
 
-1. **Dispatching** raw input events to specific widgets.
-2. **Handling** raw input events by converting into widget-specific events.
-3. **Responding** to widget-specific events with widget logic.
-4. **Reading** UI state.
+1. **Dispatching** raw input events into entity-specific events stored on each widget.
+2. **Responding** to entity-specific events to perform widget logic.
+3. **Reading** UI state once it has been changed.
 
-Widgets, as previously discussed in [UI Building Blocks and Styles](https://github.com/bevyengine/rfcs/pull/1) are simply entities with various components on them.
+As previously discussed in [UI Building Blocks and Styles](https://github.com/bevyengine/rfcs/pull/1) widgets are simply entities with various components on them.
 As discussed there, Bevy does not draw a hard-line between "UI" and "not UI"; these concepts and patterns are also useful for handling input to game entities.
 
-### Dispatching input to widgets
-
 Pretty as they may be, user interfaces are ultimately designed to, well, interface with users.
 In Bevy, that means they must listen for **input events**, created by your mouse, keyboard, joystick, touch or hand-rolled hum-to-move input pipeline.
 But once we receive an input event, what are we to make of it?
@@ -54,14 +51,23 @@ While refreshingly simple and perfectly modular, this approach runs into some ch
 4. Each system listens to the whole input stream of events. When you have 100 different systems, and they each discard 99% of all candidate input events, this creates unnecessary performance drag.
 
 This is where Bevy's **central input dispatch** comes in.
+Here's the high-level overview:
 
-TODO: explain.
+1. Every entity that responds to input through the central input dispatch has the `Interactable` component.
+These may be classic UI widgets, pure gameplay objects, or something in between.
+2. Each `Interactable` entity also has some number of `InputHandler<E>` components which map from some raw input events to **entity-specific events** (`E`) that they store in that component.
+3. Because we can map from several input streams to a single unified entity-specific event, we can unify multiple input methods without code duplication.
+4. By changing the fields of the `InputHandler` components, we can quickly rebind our user interfaces or design them in a data-driven fashion.
+5. A central `dispatch_input` system collects all of our input streams, parses the events according to the rules of our input handlers, then stores the transformed events in the appropriate entity-specific event components.
+6. These entity-specific events are then handled as usual on a per-entity basis in later systems, where their actual effects occur.
 
-### Handling inputs
+### Listening for inputs with InputHandler components
 
-TODO: write.
+TODO: explain details.
 
+### Responding to entity-specific events
 
+TODO: write.
 
 ### Widget logic
 

From efdc808d95b0a075d65092305e066ad5d4319ef0 Mon Sep 17 00:00:00 2001
From: Alice Cecile <alice.i.cecile@gmail.com>
Date: Thu, 22 Apr 2021 00:11:08 -0400
Subject: [PATCH 15/16] Made Reference-level explanation sections more specific

---
 rfcs/system-driven-ui.md | 76 ++++++----------------------------------
 1 file changed, 11 insertions(+), 65 deletions(-)

diff --git a/rfcs/system-driven-ui.md b/rfcs/system-driven-ui.md
index 2c52751c..bb5d6777 100644
--- a/rfcs/system-driven-ui.md
+++ b/rfcs/system-driven-ui.md
@@ -190,81 +190,27 @@ Standard system ordering tools (e.g. `.before()` and `.after()`) work well for t
 
 ## Reference-level explanation
 
-### Dispatching input to widgets
+### InputHandler semantics
 
-TODO: complete and clean up. Needs architecture help still :/
+TODO: work out quirks
 
-In order to unify various input methods, handle overlapping widgets, and avoid duplicating work, we need a central approach to UI dispatching.
-UI events have two core fields:
+### Z-order event dispatch
 
-1. What is being interacted with?
-   1. Screen-space coordinates.
-    Used for mouse, touch and joystick selectors.
-    Note that world-space UI elements may be dispatched to in this way as well, requiring recomputation whenever they move or the camera changes.
-   2. Selected UI elements.
-    Commonly used for keyboard control.
-2. What signal is being sent?
+TODO: critique existing solution and explain what needs to change.
 
-During dispatching, we must unify these signals across the various input streams, and convert them into logic that our widgets can understand,
-stored as events on a component of the widget itself.
-Finally, our widgets can take their new unified event stream and process it independently in their own systems.
+We already have a partial solution for this in our [`ui_focus_system`](https://github.com/bevyengine/bevy/blob/cf221f9659127427c99d621b76c8085c4860e2ef/crates/bevy_ui/src/focus.rs).
 
-```rust
-pub struct InteractableMap {
-    // Contains some data structure that allows us to efficiently map screen space coordinates to a UI widget
-    // This is probably done with a pixel-resolution array
-}
-
-impl InteractableMap(){
-    pub fn get_from_coordinates(&self, position: &GlobalTransform) -> Entity {
-        // Uses this data structure to map between screen space to a UI widget
-    }
-
-    // Analagous function for keyboard / gamepad buttons
-
-    // 
-}
-
-// The Bounds component doesn't exist yet; it should be a tight polygon around the object in a 2D plane, using screen-space coordinates
-// Screen-space bounds would be constant; world-space bounds need to be updated when the UI changes
-fn build_interactable_map(
-    // PERF: this should be done using change detection and iterative rebuilding from Bounds instead
-    world_space_query: Query<(&Bounds), (Without<ScreenSpace>, With<Interactable>)>,
-    screen_space_query: Query<(&Bounds), (With<ScreenSpace>, With<Interactable>)>, map: ResMut<InteractableMap>){
-    
-    // Sort bounds by distance to camera, with further bounds being applied first
-    // New bounds overwrite old bounds because they're "on top"
-
-    // Apply the world-space bounds first
+### Widget selection
 
-    // Screen-space bounds overwrite any world-space bounds
-}
-
-// We need one of these systems for each input event type we want to support
-// This uses NYI trait queries; other more elegant designs are welcome
-fn handle_coordinate_input<E>(query: Query<(&mut impl EventHandler<E>, impl WidgetEvents) With<Interactable>>, input_events: EventReader<E>,
-    map: Res<InteractableMap>){
-
-    for input_event in input_events.iter(){
-
-    }
+TODO: examine prior art and write.
 
-    for event_handler, mut widget_input_events in query.iter_mut(){
-        // This method is customized to each widget / widget type and converts input events into a common widget-logic format
-        let new_events = event_handler.handle();
+Tab selection.
 
-        // These events are later processed in widget-specific systems
-        widget_input_events.push(new_events);
-    }
-}
-
-```
+Joypad selection.
 
-### Customizing interaction behavior
+Widget hierarchies.
 
-Control iteration order.
-Binding to hotkeys.
-Multi-select.
+Multiple selected widgets.
 
 ## Drawbacks
 

From ed495b1cbc0b43e1fb765ef869b66e6fbe65d711 Mon Sep 17 00:00:00 2001
From: Alice Cecile <alice.i.cecile@gmail.com>
Date: Mon, 3 May 2021 16:50:06 -0400
Subject: [PATCH 16/16] Add edge and level triggered terms

---
 rfcs/system-driven-ui.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/rfcs/system-driven-ui.md b/rfcs/system-driven-ui.md
index bb5d6777..a412d572 100644
--- a/rfcs/system-driven-ui.md
+++ b/rfcs/system-driven-ui.md
@@ -112,8 +112,8 @@ TODO: refresh.
 
 Widgets can be wired to each other and the game state in two common ways:
 
-1. Directly reading the state of our widget's components.
-2. Using events emitted by interacting with the widgets.
+1. **Level-triggered:** directly reading the state of our widget's components.
+2. **Edge-triggered:** using events emitted by interacting with the widgets.
 
 Read the component's state when you care about its current state, use event channels when you want to detect events being fired off.