System-driven UI: UI behavior, wiring and system resolution

[alice-i-cecile]

RENDERED

Relies on #1, although it is agnostic to the details of how styling works.

Made dramatically more useful with a proper input dispatching solution, as seen in this pre-draft RFC.

A proposal for an ECS-first approach to handling UI behavior and communication using systems.

[colepoirier]

@geom3trik from discord (https://discord.com/channels/691052431525675048/743663673393938453/834946666984767509) “You could have a component that describes a custom hitbox (for things like circles) and default to bounding box if not there.”

[alice-i-cecile]

Notes from Discord.

So, the first idea is that we can break this into two chunks: how do we trigger logic, and how do we pass signals around
[7:27 PM] alice 🌹: For logic triggering, there are two basic paradigms: scheduled and responsive. Scheduled is that standard "systems" way to handle things, you run a system that listens to some events once per frame and executes fixed logic
[7:28 PM] alice 🌹: Responsive is only triggering custom logic based on the specific inputs received. Cart's reactivity idea falls into this category, as do hooks and my one-shot systems idea
[7:29 PM] alice 🌹: In Bevy, you're ultimately going to be need to be backed by some sort of scheduled logic to read inputs, but this can then trigger cascades of responsive logic once it's started
[7:30 PM] alice 🌹: We need our UI logic to "loop" within each frame until it's come "to rest", or we have to think about input delays and design around weird intermediate states
[7:32 PM] alice 🌹: The signal-passing stuff is about "once we've triggered some bit of logic, what data does it manipulate and how do other bits of our game and UI hear about that"
[7:34 PM] alice 🌹: There are two paradigms within that: level-triggered signals, which cause variations based on the current state of something, and edge-triggered signals, which are caused by a change in state. This is the distinction between pressed and just_pressed for example
[7:35 PM] alice 🌹: You can store your data in: components on the entity itself, a global resource, or components on a linked entity. You can access data using either something relations-like, or through queries
[7:37 PM] alice 🌹: Edge-triggered events are all about what do you emit. There are a few good options for this: global events, events stored as a component on a single entity and entities-as-events. In simple cases, you can use change detection to convert level-triggered signals into edge-triggered signals in a simple and ergonomic way rather than worrying about a new event type
[7:37 PM] alice 🌹: /fin

[alice-i-cecile]

Closing this out in favor of a new RFC on the same topic. The callback pattern is extremely compelling, but requires basically a complete rewrite of this.