You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the app I am currently building, my UI systems are growing out of control and exceeding 13 levels of indentations, thus becoming more and more hard to manage.
I want to split my systems into more manageable pieces, closer to the one system = one feature, but I struggle to find a satisfying way to do this.
Thus far I can think of these options:
Each panel can be created from just the EguiContext in seperate systems, this is what I am already doing, doesn't scale well because the overwhelming majority of my content is in the CentralPanel.
Having a "layout" system that produces lots of Uis using Ui::child_ui that can be later queried in other systems to draw just their data, but at the cost of a lot of Arc::clone each frame. Plus it is only possible for parts of the UI with known sizes, so no lists.
Having a lot of ui_XXX free functions (not systems) that take &mut World or similar. This works in principle but becomes an aliasing nightmare when you want to call them in a for loop borrowing from &mut World.
Creating lots of custom egui::Widget and/or fn show(self, ui: &mut Ui). Same drawbacks as previous point.
Note that I am not doing this for parallelism but purely for better looking code.
I am leaning towards the Ui::child_ui option because it just looks like a more flexible panel API, but would like to know how other people architecture their UI code with bevy_egui.
The text was updated successfully, but these errors were encountered:
Hi,
In the app I am currently building, my UI systems are growing out of control and exceeding 13 levels of indentations, thus becoming more and more hard to manage.
I want to split my systems into more manageable pieces, closer to the one system = one feature, but I struggle to find a satisfying way to do this.
Thus far I can think of these options:
EguiContext
in seperate systems, this is what I am already doing, doesn't scale well because the overwhelming majority of my content is in theCentralPanel
.Ui
s usingUi::child_ui
that can be later queried in other systems to draw just their data, but at the cost of a lot ofArc::clone
each frame. Plus it is only possible for parts of the UI with known sizes, so no lists.ui_XXX
free functions (not systems) that take&mut World
or similar. This works in principle but becomes an aliasing nightmare when you want to call them in afor
loop borrowing from&mut World
.egui::Widget
and/orfn show(self, ui: &mut Ui)
. Same drawbacks as previous point.Note that I am not doing this for parallelism but purely for better looking code.
I am leaning towards the
Ui::child_ui
option because it just looks like a more flexible panel API, but would like to know how other people architecture their UI code withbevy_egui
.The text was updated successfully, but these errors were encountered: