UI Style reuse: composition + assets
- Dominant language
- Rust
- Stars
- 48.2k
- Forks
- 4.8k
- Avg merge
- 3d 16h
- Merged PRs (30d)
- 171
Description
## What problem does this solve or what need does it fill?
At the moment `Style` is incredibly verbose to use, just have a look at the [UI example](https://github.com/bevyengine/bevy/blob/main/examples/ui/ui.rs).
In order to improve ergonomics and reduce boilerplate when dealing with UI we need to do something about it and we should strive to achieve the level of UX that we see in other parts of the engine.
## What solution would you like?
In order to do so we are going to need two related but IMO orthogonal features:
1. Style composition: [bevyengine/rfcs#1](https://github.com/bevyengine/rfcs/pull/1)
2. Style as assets
I don't know exactly what these would look like in implementation, but I'm hoping some of you have good ideas for design-approaches that we then split out into separate issues or PRs.
**This issue should be about figuring out a scope and requirements for both of these features**
## What alternative(s) have you considered?
- Leave style as is and keep verbose + cumbersome UX
- Style inheritance
- Others?
## Additional context
We might find that we are blocked on other features like scenes or reflection on some of this but in that case it is good to know exactly where the blocker is so that we can push to unblock those 😄
Contributor guide
Research direction
Start with examples/ui/ui.rs to understand the current Style usage, then read bevyengine/rfcs#1 for the proposed composition direction. Define the scope and requirements for style composition and styles as assets, including any blockers such as scenes or reflection, and split the resulting work into separate issues or PRs.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- game-dev
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100