Replies: 5 comments 9 replies
-
|
First crack at these questions!
I support all of the requirements outlined above. I think they may be clearer if grouped though.
I think that UI scaling is another important accessibility tool that we should be careful to design around. I also think that #4090 belongs under the list of tools we might need.
A widget should be a collection of one or more entities (and their components), connected via relations (to start with, the Parent/Children components).
Widgets should be declared using a multi-entity variation of the Builder methods can be added to allow the generation of variants that share the same structure (entities and components) but have different configuration.
There should be three methods:
This is consistent with the existing paradigms for ECS, and allows us to use standard Rust tooling like builder methods.
Widgets should be nestable, via hierarchical entity composition. This can either be done ad-hoc, or by constructing a new prefab type, as outlined above.
Each widget should have at least one defining marker component, in addition to the default These marker components can be combined with Themes are stored in a central resource and are applied in a well-defined order on the basis of the marker components present on each entity.
Through event bubbling.
Through one-shot systems or event emission.
Via ordinary systems.
Defining selection strategies for widgets and widget sub-components based on non-local properties seems quite hard until we get very advanced relations features. For example on the web it's common to want to style all elements that are the child of an element that has a certain property. Users would be able to hand-write systems to search for this case and add/remove the appropriate marker components, but that will be tricky and we should start thinking about ways to improve this in both the short and long term. |
Beta Was this translation helpful? Give feedback.
-
Any recommendation to the grouping, or how that should look? |
Beta Was this translation helpful? Give feedback.
-
|
My take on it is here: https://hackmd.io/@1w5KSqtVQSqQ-xUpP2tRzw/S1hv9v66c/edit |
Beta Was this translation helpful? Give feedback.
-
|
Updated the post with your, more clear, definitions! |
Beta Was this translation helpful? Give feedback.
-
|
Added one-shot systems and kinded entities |
Beta Was this translation helpful? Give feedback.
-
|
A couple days ago I started my adventure in building my own Widgets using pure
Sure, but I don't think Bevy should have it's own common widgets, like stated on #1953. It could have some basic widgets, like buttons and maybe other 2 or 3, because UI is part of the game look'n'feel so users will have to make their own widgets anyways (unless it's a prototype or something like that), so Bevy should focus on ways of allowing to create new widgets as easier as possible so users may create hundreds of crates with custom themes and widgets (like RTS, MMORPG, FPS and so on).
Everything that is missing, is already address somewhere else, be it RFC, PR or another proto crate.
At runtime Widget is an Entity, so it's easier to Bevy to deal with. At project time it's a Scene (or a EntityTree or something like that) so it's easier to user deal with it.
Using scenes, be it editing a file, using editor or generating by code.
Using composable/nested scenes. Adding a button to an existing UI is just a matter to referencing an existing scene prefab.
Using scenes (yeah scenes are my silver bullet) as stated above.
There should be a resource used for global theming. Bevy should provide a default theme and users can also add it's own theme and also be able to change it on runtime. Also it should be possible to pass a custom theme for a custom Widget, when instanciating it (to Scenes on project time). When the Widget is created, it should first check if there is a custom widget, if not, it should look for the global theme settings.
We should have We should have For For both
Using components, events and commands. State that should be visible to user, should use public components. State that shouldn't be visible to user, must use some kind of meta components, which store it's internal state and allow for a great flexibility.
Using systems and querying other widgets public components, events or sending commands.
I think each Widget should have it's own Plugin which a set of systems/components, this make it easier to reason about what each widget does. Those plugins should careful expose components, events and commands to interact with other Widgets. I don't know if I was clear enought, but in short terms we should use Scenes to instanciate, configure and nest/group Widgets together and use Plugins to determine how those Widgets should behave. |
Beta Was this translation helpful? Give feedback.
-
|
An additional note: theming should be extensible. You should be able to modify new properties using themes, including user-defined ones. For example, suppose you wanted to add your own glow types, modelled as an enum component. All of the existing tools should support this gracefully. |
Beta Was this translation helpful? Give feedback.
-
|
Have we considered using Another reason to separate style from widget code is to allow artists to tweak styles without needing help from engineers. |
Beta Was this translation helpful? Give feedback.
-
|
First, I can't even begin to express how happy it makes me that this is finally getting attention.
Retained mode is obviously going to make layout easier and probably faster but there are some really good aspects to immediate mode, like events that don't require some form of callback mechanism. Perhaps there could be a hybrid approach? |
Beta Was this translation helpful? Give feedback.
-
|
Even egui has state for many of it's widgets but they attempt to hide it from you, which I think is a mistake. |
Beta Was this translation helpful? Give feedback.
-
Yup! I don't see anything particularly controversial in there and I suspect we will find consensus quickly on these high level requirements.
I think there are two paths here (which are compatible):
Open question worth exploring. We can probably use whatever ultimately fills the "Bevy Prefabs / Scenes" niche for this and that should be assumed to be our default approach (at least until we start exploring reactivity, which should happen later). We can assume that the Prefab / Scene niche will have:
By default, I think we should try to use whatever patterns we use elsewhere in Bevy for prefab / scene spawning (Commands or an interface on top of them)
Hierarchical nesting
Open question worth exploring. Setting fields on components which drive specific logic in the widget makes the most sense to me as a starting point. Aka "normal bevy entity configuration". Notably, this could pair with Reflect based property setting / patching. Consider the following "real" instance of an Entity hierarchy in a world with Node and Children components: This could be "themed" by applying a scene-like Reflect based property patch: Scenes will ultimately allow you to omit default fields and just define properties that have changed (important for both compressing scene sizes and seamlessly supporting new fields + picking up new defaults). That "scene field overloading logic" seems very similar to the logic outlined above. We might be able to reuse logic.
Very open question. Likely some combination of events and direct component value access (via systems). Note that for something "reactive" (again ... we should tackle this later) controlling information flow is critical. As much as possible, communication should only happen in a "top down" fashion by passing data from the parent into the child. ("pure" components in React terms). But yeah dataflow is the question for UI and not something we can resolve here. People should start thinking about this, developing detailed proposals, and making their case in new Discussions or RFCs.
Imo this is the same question as the "widget communication" problem, provided that we agree widgets are just entity / component hierarchies.
Imo this is the same question as the "widget communication" problem, provided that we agree widgets are just entity / component hierarchies.
I think we've already bitten off a lot of scope in this discussion and we shouldn't expand it much further. It looks like we've established relative consensus on the high level stuff. So it makes sense to break out into more scoped conversations for specific topics. Ex: we should have a discussion for event handling, a discussion for widget definition apis, etc. Imo people with strong opinions should start spec-ing out how these should look and behave in practice. One semi-important question is how we handle "collections / lists". If you want an "inventory widget", how do you keep that in sync with a list of items in the inventory? In some ways, this is just an extension of the dataflow problem, but it is one of the "hard" problems in UI framework design and worth addressing specifically when solving the dataflow problem. |
Beta Was this translation helpful? Give feedback.
-
|
Regarding point #2 about a react-like system. I've been toying with the idea of a reactive system as a generic logic layer on top of the ECS. Recently I played around with a 3d rendering engine built in react and it was kinda nice for organizing high-level logic. This could be an alternative to a scripting language as a way to write that kind of logic. The major downside of course is that you introduce a second way to write logic in Bevy that is less performant than plain ECS logic. Here's an example in the form of a react-like component: function Game() {
const [isPlaying, setIsPlaying] = useState(false)
const startGame = () => setIsPlaying(true)
return (
<>
{!isPlaying && <MainMenu onStartGame={startGame} />}
{isPlaying && (
<GameSession>
<Player />
<Level />
<Enemies />
</GameSession>
)}
</>
)
} |
Beta Was this translation helpful? Give feedback.
-
|
Another upside would be that such a system would make the UI more integrated into the rest of the engine. Instead of "this is how you write bevy code and this is how you write UI code." |
Beta Was this translation helpful? Give feedback.
-
|
@CooCooCaCha This is essentially what Kayak UI does. :) One thing to point out though is that you can't just create state out of thin air. In Kayak we create state by spawning an entity that is attached to a widget. To change state you just query the state data as &mut. Kayak creates reactivity by splitting widgets into two separate systems.
This does have some drawbacks:
Overall I'm pretty happy with the direction that Kayak is heading and I think it opens up some possible ideas for bevy_ui. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
In order to improve the native UI experience in Bevy and seriously begin tackling #254, we need to have a solid idea of where we are going and somewhat of an idea of how it needs to look like once we get there.
bevy_ui, in its current state, is excessively verbose and cumbersome to work with. We both need to improve the ergonomics of the lower level abstractions and develop higher level abstractions.In order to break ground on one of those higher level abstractions, I want to start a discussion on the targets and requirements for Widgets in Bevy.
Dictionary
bevy_uiis a retained-mode UI framework.Widget definition and requirements
bevy_uidoes.Here is a list of Widgets we would like to support eventually.
Note
These requirements are aspirational. It could be that some of these requirements turn out to be mutually exclusive or even impossible within our tech-stack, in which case we'll come back to this and re-evaluate.
We do however need a solid goal to aim for.
Prior Art & Relevant reading material
bevy_ui.bevy_eguiwidget::<MyCoolWidget>(world, ui, "unique name");ui4exploration: Details hereTools and ideas we might need to build this
User Stories and Experiences
Questions to answer
entities,components,systemsandevents?Beta Was this translation helpful? Give feedback.
All reactions