Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Discussion: How to architecture UI code in multiple systems efficiently ? #266

Open
icanwalkonwater opened this issue Feb 27, 2024 · 0 comments

Comments

@icanwalkonwater
Copy link

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:

  • 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant