bevyengine
UI Central Dogma and A High-Level Compositional Design
This meta-RFC lays out a vision for work to be done to achieve a complete solution for bevy_ui. By breaking the problem down into a central dataflow and many competing UI-like behaviors, we can create a modular design that can be designed, implemented and replaced in smaller chunks and reused in flexible ways for designs that straddle gameplay and "classical UI".
This is intended to be an extremely collaborative process: please comment and make pull requests aggressively.
This RFC contains several benchmark paper prototypes, intended to be designed and completed by community members to share their visions of what an ideal UI looks like. Feel free to submit yours in the appropriate section (in a collapsible section) regardless of how many you've completed or the status of your prototypes / RFCs.
P.S. This RFC uses the proposed lightly tweaked template from #21 to improve clarity <3
Here's a little sketch of something redux/FRP like implemented with traits: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=c68897abd01df00dc38a6c9153052adb
To expand on "external tools":
Data-driven ... How do we interface with external tools, if at all?
A few developer tools to consider:
- An inspection tool, like a browser's dev tools or the React devtools, can help for inspecting the current state
- A changelog, like the Redux devtools, can help for inspecting app state and action history
- A "headless" mode can help for testing without rendering
It's worth considering these kinds of tools when designing the API. For instance, these kinds of tools usually benefit from serializable state.
Two more examples I'd like to add:
- A sudoku grid: lots of subtle complexity there. Was completely infeasible under the current UI; see: https://github.com/bevyengine/bevy/discussions/2235.
- A dynamically generated flow-chart. Very very useful for our editor.