Bevy in production: making reusable widgets with bevy and egui

[aevyrie]

At Foresight we're using bevy and egui to build 3D CAD desktop applications. I'd like to share a solution we've developed to solve some of the growing pains we've experienced. This solution gives us UI widgets that are easy to compose, can directly query the ECS, yet have a uniform function signature.

While bevy is not going to use egui for its first party UI solution, the purpose of this post is to provide some ideas for the future of bevy_ui. Speaking for myself, I'd love to switch over to bevy_ui from egui if we can build a UI library that better integrates with the ECS, fills current accessibility gaps, and improves iteration times.

Foreword

I'd like to credit @Ratysz and @TheRawMeatball for their help in pointing out bugs and shoring up my implementation with their in-depth knowledge of bevy's ECS, as well as @alice-i-cecile for her work on one-shot systems and pointing me in the right direction.

What do those fancy words mean?

There's a bit of jargon-y text in the intro. Here's what I mean:

• "Composable": widgets can be arbitrarily nested or reused in many places without boilerplate
• "Can query the ECS": widgets can natively query the ECS, instead of relying on values passed in via function parameters
• "Uniform function signature": widgets all have the same function signature, regardless of what data they query the ECS with

Skip to the fun part, what does this look like?

In general, adding a MyCoolWidget widget looks like this:

widget::<MyCoolWidget>(world, ui, "unique name");

For a practical example showing an actual use case, let's start by looking at a window that has a few different modes. The user can be in one of these modes depending on whether they are viewing a list of entries, editing, or creating a new entry:

// Show a different screen depending on what mode/view we are in:
ui.vertical(|ui| match world.resource::<MainViewMode>() {
    MainViewMode::List => widget::<ListView>(world, ui, id.with("list")),
    MainViewMode::Edit => widget::<EditView>(world, ui, id.with("edit")),
    MainViewMode::New => widget::<NewView>(world, ui, id.with("new")),
});

Note that all these widgets have the same signature, widget::<MyWidget>(world, ui, ""). Because this is a generic function, we have the same three parameters provided for any widget: the World, the egui Ui context, and a unique ID for that instance of the widget. The id.with() helper function simply concatenates the parent widget's id with this instance's id, resulting in a unique namespaced id.

Widgets can be added inside other widgets; inside ListView we use common button widgets that are also used in other views:

// Inside the ListView widget:
impl<'w, 's> WidgetSystem for ListView<'w, 's> {
    fn system(world: &mut World, state: &mut SystemState<Self>, ui: &mut Ui, id: WidgetId)

        // ...draw stuff for the list view widget here...

        // We can just drop in some reusable button widgets also used in other views:
        ui.with_layout(Layout::right_to_left(), |ui| {
            widget::<buttons::OpenEditView>(world, ui, id.with("edit"));
            widget::<buttons::OpenNewView>(world, ui, id.with("new"));
            widget::<buttons::Delete>(world, ui, id.with("delete"));
            widget::<buttons::Import>(world, ui, id.with("import"));
            widget::<buttons::Export>(world, ui, id.with("export"));
        });
    }
}

Background

egui is an immediate mode UI library. This means that the state of the UI is built from scratch every frame, but it also means the state is entirely transparent, without the need for propagating state through a retained tree. In bevy, using bevy_egui, this state is accessed through the EguiContext resource - a single struct that contains the entire UI state. When you have mutable access to the EguiContext, you can add widgets, updating the state.

Problem

Before using this widget solution, the most natural way to write an egui app in bevy is to use systems and functions:

fn ui_system(
    ctx: ResMut<EguiContext>, 
    foo: Res<Foo>, 
    bar: Res<Bar>
) {
    egui::Window::new("Hello").show(ctx.ctx_mut(), |ui| {
        ui.label(foo);
        ui.button(bar);
    });
}

This is fine, but things start to get more difficult as the GUI grows. Let's start adding a ribbon and tabs to the application:

/// Our bevy system
fn ui_system(
    ctx: ResMut<EguiContext>, 
    foo: Res<Foo>, 
    bar: Res<Bar>,
    baz: Res<Baz>, 
    qux: Res<Qux>
) {
    egui::Window::new("Hello").show(ctx.ctx_mut(), |ui| {
        ui.label(foo);
        ui.button(bar);
        ribbon_tab_home(ui, baz, qux);
    });
}

// A function with gui logic extracted
fn ribbon_tab_home(
    ui: ResMut<Ui>, 
    baz: Res<Baz>, 
    qux: Res<Qux>
) {
    // Do some UI stuff
}

As we add more stuff, the function signature of our bevy UI system grows, and grows, and grows. We can't just move the logic in our function to a new system, because we need the Ui to be in the correct state, e.g. inside that Window closure.

A more significant problem is that this makes leaky abstractions inevitable. Instead of being able to define self-contained widgets inside a "feature" crate, all of the implementation details of that feature end up leaking all over the UI code. As the UI grows more complex and you have layers and layers of function calls (i.e. window > panel > tab view > button), the parent function signatures start to grow rapidly. Every time you need to access a resource or component in your widget, you now have to add that to the function signature of every single parent function, all the way up to the top level system. Adding a new resource suddenly becomes a chore as you have to fix every call site that you just broke.

Solutions

It was pretty clear at this point that what we were doing was becoming more and more unmaintainable by the day.

The API I wanted to have, without really knowing if it was possible, was the ability to run functions as if they were their own systems. Instead of nested function calls, imagine if each widget could be called without needing to pass in resources. This would alleviate the problem of the ever-growing ui system function signature.

Passing around the World

The simplest solution is to just pass the World as your only function parameter, and run the UI as an exclusive system. Your function can now get whatever it needs from the world. Performance isn't a problem, it's not as if you were running the UI in parallel before. This doesn't make for a great API surface, and it's hard to enforce any sort of guarantees if you just toss a function the World and tell it to go have fun.

The magic of SystemState

Browsing through the ECS docs, trying to find some way to improve the situation, I ran across the SystemState docs. This is what tracks the state of bevy systems under the hood, it's the thing keeping track of query mutations and system local variables between runs of a system. Without going into too much detail, the final solution is a widget trait implemented on your widget, and a generic function that allows you to pass in the type of your widget:

widget::<MyCoolWidget>(world, ui, "unique name");

The widget function handles the creation and storage of every widget's SystemState in a resource. If you do want to get into the details, you can see the implementation below:

SHOW ME THE CODE

pub trait WidgetSystem: SystemParam {
    fn system(world: &mut World, state: &mut SystemState<Self>, ui: &mut Ui, id: WidgetId);
}

pub fn widget<S: 'static + WidgetSystem>(world: &mut World, ui: &mut Ui, id: WidgetId) {
    // We need to cache `SystemState` to allow for a system's locally tracked state
    if !world.contains_resource::<StateInstances<S>>() {
        // Note, this message should only appear once! If you see it twice in the logs, the function
        // may have been called recursively, and will panic.
        debug!("Init system state {}", std::any::type_name::<S>());
        world.insert_resource(StateInstances::<S> {
            instances: HashMap::new(),
        });
    }
    world.resource_scope(|world, mut states: Mut<StateInstances<S>>| {
        if !states.instances.contains_key(&id) {
            debug!(
                "Registering system state for widget {id:?} of type {}",
                std::any::type_name::<S>()
            );
            states.instances.insert(id, SystemState::new(world));
        }
        let cached_state = states.instances.get_mut(&id).unwrap();
        S::system(world, cached_state, ui, id);
        cached_state.apply(world);
    });
}

/// A UI widget may have multiple instances. We need to ensure the local state of these instances is
/// not shared. This hashmap allows us to dynamically store instance states.
#[derive(Default)]
struct StateInstances<T: WidgetSystem> {
    instances: HashMap<WidgetId, SystemState<T>>,
}

#[derive(Debug, Clone, Copy, PartialEq, Eq, Hash)] 
 pub struct WidgetId(pub u64); 
 impl WidgetId { 
     pub fn new(name: &str) -> Self { 
         let bytes = name.as_bytes(); 
         let mut hasher = FxHasher32::default(); 
         hasher.write(bytes); 
         WidgetId(hasher.finish()) 
     } 
     pub fn with(&self, name: &str) -> WidgetId { 
         Self::new(&format!("{}{name}", self.0)) 
     } 
 }

Finally, let's see what it takes to define a widget. We start off by defining the widget's type. This is similar to defining a system:

#[derive(SystemParam)]
pub struct SpawnButton<'w, 's> {
    commands: Commands<'w, 's>,
    counter: Local<'s, usize>,
}

This widget/system only needs access to Commands and a local resource. Pretty boring. Let's define what happens when we show our widget:

impl<'w, 's> WidgetSystem for SpawnButton<'w, 's> {
    fn system(world: &mut World, state: &mut SystemState<Self>, ui: &mut Ui, _id: WidgetId) {
        // This will get everything our system/widget requested
        let mut params = state.get_mut(world);

        if ui.button("Spawn a thing").clicked() {
            params.commands.spawn();
            params.counter = params.counter + 1;
        }        
    }
}

That's all there is to it. We now have a widget we can add, and each instance of our SpawnButton widget will have its own local counter state. We can add as many instances as we need, and each one will have independent state:

widget::<SpawnButton>(world, ui, "first instance");
widget::<SpawnButton>(world, ui, "second instance");
widget::<SpawnButton>(world, ui, "third instance");

This is a pretty simple example, but it works with anything you could use in a bevy system.

Outcome

I'm pretty happy with the result. It's by no means perfect (we'll talk about that next), but it solved the biggest issues I was experiencing when scaling the application up. We can now develop features in independent crates, and only make widgets public, but keep all implementation details private to the crate. We're also looking to build off of this, adding stylesheets to our widgets.

Limitations and Future Work

This technique, in its current form has some known limitations.

Exclusive World access

The ui system is an exclusive_system, meaning no other systems can run while this system is running. This might be intuitive - the UI needs mutable access to the World, which means nothing else can access it while mutably borrowed.

In practice, this doesn't seem to be a problem. Building the UI doesn't take long with egui, it's designed to build the entire UI from scratch in a few milliseconds, at most. And while we can't run other systems in parallel, it doesn't stop us from doing other useful work in an independent task pool.

This limitation could be removed if one-shot systems were allowed to be dynamically added to the schedule, and only mutably borrowed the components and resources they use, like normal systems.

Boilerplate

Unfortunately, there's no way I'm aware of to elide the lifetimes in a SystemParam. If you don't use one of the two lifetimes, you will need to add a PhantomData field to ensure all lifetimes are used in the struct:

#[derive(SystemParam)]
pub struct Widget<'w, 's> {
    foo: ResMut<'w, Foo>,
    #[system_param(ignore)]
    _phantom: PhantomData<(&'w (), &'s ())>,
}

While it looks ugly, it's not really a problem in practice. When widgets are used in the UI, it looks nice and is relatively information dense. Plus, you will only see these lifetimes in the struct where the widget is defined.

Nested widgets with conflicting data access

If you nest widgets that need access to the same data, there are cases where building recursive widgets is impossible. To be clear, the widgets presented here can be nested arbitrarily, it's an edge case we found that used a self-referential data structure.

Closing thoughts

While egui is quite different from bevy_ui, I think this is an interesting avenue worth exploring. Using systems as widgets makes accessing and updating ECS state through the UI both intuitive and composable, and makes it much easier to scale up GUI-heavy applications. If we end up merging one-shot systems, widgets like this might become even more ergonomic to write.

[Weibye]

1. I really appreciate the writeup! This is very insightful and will help inform what direction we should take with bevy_ui
2. Based on your current experience, are you able to picture how this could look using a retained-mode UI? Or is that so fundamentally different that you'd need to design a solution from scratch?

[aevyrie]

Based on your current experience, are you able to picture how this could look using a retained-mode UI? Or is that so fundamentally different that you'd need to design a solution from scratch?

I think much of this is still applicable. While a retained mode UI probably won't be passing the context around like egui, I think the rest still applies.

• Widgets reading/writing data via the same system syntax we use in systems is incredibly intuitive and powerful, reducing the need to learn new paradigms to use UI.
• This plays well with event bubbling: widgets can simply listen for events like a regular system.
• This should work with declarative scene files. The scene would define the structure and layout of widgets, while the behavior is defined in code.

are you able to picture how this could look using a retained-mode UI

Maybe something like:

command.spawn()
    .insert(Widget<MyButton>)
    // add other ui hierarchy and components

Because we only need type information, not data, for widgets, we could get away with a zero sized type like Widget(PantomData<MyWidget>), so we can retain type information without the struct data needing to be filled. From there, the widget can be executed with a trait implemented on the generic type, like I've shown in the original post.

[Weibye]

This is very interesting! :)

[RobWalt]

I tried out your approach and I really like it! I have one question though: Let's call the "main" system that you run with bevy run_ui, in code:

...
.with_system(run_ui.exclusive_system())
...

Do you have a smart way of passing the EguiContext to the top layer UI element? I only got it working by removing the EguiContext and inserting it back again, e.i.

pub fn run_ui(world: &mut World) {
  let mut egui_ctx = world.remove_resource::<EguiContext>().unwrap();
  egui::CentralPanel::default.show(egui_ctx.ctx.mut(), ...);
  world.insert_resource(egui_ctx);
}

but that feels a bit wonky. Is there another approach to this?

[mvlabat]

@RobWalt what do you need from EguiContext specifically? If you just need the Egui context and you don't care about the bevy_egui wrapper, you can also call ctx.get_mut().clone() (which will point to the same context thanks to the underlying Arc<RwLock<ContextImpl>>).

[RobWalt]

@mvlabat Sorry, my question was a bit short.

The problem is that withing the widget function proposed in this discussion here, we need to borrow the World mutably. Previously, we could do that because the EguiContext was a Resource and we could clearly separate it from the world with resource_scope (as mentioned above) and borrow the rest of the world to the widget function.

Since the EguiContext is a component now, this separation isn't as easy. Meanwhile some workaround surfaced however, which also answered my question for the most part. Here it is:

pub fn with_world_and_egui_context<T>(
    world: &mut World,
    f: impl FnOnce(&mut World, &mut EguiContext) -> T,
) -> T {
    let mut state = world.query_filtered::<Entity, (With<EguiContext>, With<PrimaryWindow>)>();
    let entity = state.single(&world);
    let mut egui_context = world.entity_mut(entity).take::<EguiContext>().unwrap();
    let ret = f(world, &mut egui_context);
    world.entity_mut(entity).insert(egui_context);
    ret
}

All credits for finding this go to @Azorlogh btw!

The only questions that are still open are:

• How performant is it to remove and re-insert the component every frame?
• Could this potentially mess up some bevy-egui internal invariants?

From what I could test, it seems to work fine for smaller examples.

[mvlabat]

How performant is it to remove and re-insert the component every frame?

I don't know the exact answer myself, but I would guess that the performance impact won't be too significant. Even if that will make the ECS rebuild archetypes and move some data around, applications don't usually have that many windows to cause noticeable performance issues.

Could this potentially mess up some bevy-egui internal invariants?

As long as EguiContext gets immediately re-added during the same exclusive system run, I think it's fine.

@RobWalt btw, maybe you don't need to keep mutable access to EguiContext itself in let ret = f(world, &mut egui_context);. As I mentioned in the previous comment, did you consider passing egui::Context? The code would look as follows (I didn't test, but it should compile):

pub fn with_world_and_egui_context<T>(
    world: &mut World,
    f: impl FnOnce(&mut World, egui::Context) -> T,
) -> T {
    let mut state = world.query_filtered::<Entity, (With<EguiContext>, With<PrimaryWindow>)>();
    let entity = state.single(&world);
    let mut egui_context = world.get_mut::<EguiContext>(entity).unwrap();
    let ctx = egui_context.get_mut().clone().unwrap();
    // drop(egui_context); // shouldn't be required
    f(world, ctx)
}

[RobWalt]

Ah yeah thanks! I didn't understand that properly but your example makes it clear 👍🏼 That works aswelll 👌🏼

With the clone approach we need to be a bit careful though to not do the same within the f (for instance for creating windows?). I'll need to check that for a bigger example

[mvlabat]

Cloning is fine as long as you don't access clones pointing to the same window concurrently. If all the UI systems are exclusive (i.e. require World) and don't have inner parallelism, it's unlikely to be a problem in your case.

[zicklag]

I've been working with Egui in Bevy for a little bit and ran into similar challenges. So far my solution was just to put everything in a massive system parameter that had everything the entire UI tree needed, and while it worked, that system param kept getting bigger and bigger. 🙃 Then I ran into the sixteen-field limit on the derive and had to start nesting custom system parameters in each-other to get around it.

Anyway, this looks great, and thanks for sharing! I'm going to try it out.

[zicklag]

I just tried out an idea to let you write widgets as normal Bevy systems with a special expected In<WidgetSystemInput> parameter, but I ran into issues nesting the widget.

For example, here's what I wanted to be able to do:

fn main_menu_widget(
    In(ui): In<WidgetSystemInput>,
    mut menu_page: Local<MenuPage>,
) {
  match *menu_page {
        // home_menu_widget is another widget system like main_menu_widget
        MenuPage::Main => widget(ui.with("home"), home_menu_widget),
    }
}

I almost got it working, but we've got an issue with the nested widget that I think might be logically impossible to workaround.

Essentially, because rendering a new widget needs exclusive access to world, because it's SystemParam could borrow anything, we have to stop borrowing all of the system parameters of the main_menu_widget before rendering home_menu_widget, but since they are passed in directly as args, there's no way to stop borrowing them while we render the child widget! sigh... It was so close!

In @aevyrie's original example, we don't have the issue because system params aren't passed in directly as args, just the SystemState, and you have to explicitly borrow the params with let params = state.get_mut(world) to get access. Allows rust to ensure your borrow of params and the world are dropped before you render a child widget.

---

Anyway, I think it's logically flawed, but I figured I'd share just in case somebody could prove me wrong. :)

Here's the code:

pub trait WidgetSystem<Out, Param: SystemParam, Marker>:
    for<'a> SystemParamFunction<WidgetSystemInput<'a>, Out, Param, Marker>
{
    type Param: SystemParam;
}

impl<
        Out,
        Param: SystemParam,
        Marker,
        T: for<'a> SystemParamFunction<WidgetSystemInput<'a>, Out, Param, Marker>,
    > WidgetSystem<Out, Param, Marker> for T
{
    type Param = Param;
}

pub struct WidgetSystemInput<'a> {
    id: WidgetId,
    ui: &'a mut egui::Ui,
    world: &'a mut World,
}

impl<'a> WidgetSystemInput<'a> {
    pub fn with(mut self, name: &str) -> Self {
        self.id = self.id.with(name);
        self
    }
}

impl<'a> Deref for WidgetSystemInput<'a> {
    type Target = egui::Ui;

    fn deref(&self) -> &Self::Target {
        &self.ui
    }
}

impl<'a> DerefMut for WidgetSystemInput<'a> {
    fn deref_mut(&mut self) -> &mut Self::Target {
        &mut self.ui
    }
}

pub fn widget<W, Out: 'static, Param: 'static, Marker: 'static>(
    ui: WidgetSystemInput,
    mut widget_system: W,
) where
    W: WidgetSystem<Out, Param, Marker, Param = Param>,
    Param: SystemParam,
{
    let WidgetSystemInput { ui, world, id } = ui;
    // We need to cache `SystemState` to allow for a system's locally tracked state
    if !world.contains_resource::<StateInstances<Out, Param, Marker, W>>() {
        // Note, this message should only appear once! If you see it twice in the logs, the function
        // may have been called recursively, and will panic.
        trace!("Init widget system state {}", std::any::type_name::<W>());
        world.insert_resource(StateInstances::<Out, Param, Marker, W> {
            instances: HashMap::new(),
        });
    }
    world.resource_scope(
        |world, mut states: Mut<StateInstances<Out, Param, Marker, W>>| {
            if !states.instances.contains_key(&id) {
                trace!(
                    "Registering widget system state for widget {id:?} of type {}",
                    std::any::type_name::<W>()
                );
                states.instances.insert(id, SystemState::new(world));
            }
            let cached_state = states.instances.get_mut(&id).unwrap();
            // Can't borrow world mutably twice. 🙁
            widget_system.run(
                WidgetSystemInput { ui, world, id },
                cached_state.get_mut(world),
            );
            cached_state.apply(world);
        },
    );
}

/// A UI widget may have multiple instances. We need to ensure the local state of these instances is
/// not shared. This hashmap allows us to dynamically store instance states.
#[derive(Default)]
struct StateInstances<Out, Param, Marker, T>
where
    Param: SystemParam,
    T: WidgetSystem<Out, Param, Marker>,
{
    instances: HashMap<WidgetId, SystemState<T::Param>>,
}

#[derive(Debug, Clone, Copy, PartialEq, Eq, Hash)]
pub struct WidgetId(pub u64);
impl WidgetId {
    pub fn new(name: &str) -> Self {
        let bytes = name.as_bytes();
        let mut hasher = FxHasher32::default();
        hasher.write(bytes);
        WidgetId(hasher.finish())
    }
    pub fn with(&self, name: &str) -> WidgetId {
        Self::new(&format!("{}{name}", self.0))
    }
}

impl From<&str> for WidgetId {
    fn from(s: &str) -> Self {
        Self::new(s)
    }
}

[aevyrie]

I'm feeling the big dumb right now. I'm not sure how to parse In(ui): as a function parameter destructure. I understand that it allows you to use ui, but I don't understand how the In enum relates to the generic In type. Is there a reference in the rust docs? Not easy to search for In.

[aevyrie]

https://docs.rs/bevy/latest/bevy/ecs/prelude/struct.In.html

I think?

pub struct In<In>(pub In);

Ah, but of course. 😆

[aevyrie]

Okay, so key thing I was missing here - In is a special type used to pass data into bevy systems:

Systems may take an optional input which they require to be passed to them when they are being run. For FunctionSystems the input may be marked with this In type, but only the first param of a function may be tagged as an input. This also means a system can only have one or zero input parameters.

[Ratysz]

Yeah I probably should've put that a new reply rather than editing, sorry for the confusion 😅

[aevyrie]

... continuing my stream of consciousness ...

Okay, so the reason In is useful here, is that it allows you to pass the egui Ui context through chained widgets, which is needed for egui to work (the ui context is built serially). The entire reason I needed the abstraction in the OP is to allow you to pass the Ui through widgets while maintaining a fixed function signature. The proposal from @zicklag attempts to sidestep this by reusing bevy's own system abstraction which already solves the function signature problem. However the issue, as stated above, is that it doesn't allow you to express the desired ownership of the input arguments.

[aevyrie]

@mvlabat Not sure if you've seen this, but you might find it interesting or useful as the bevy_egui maintainer!

[zicklag]

Here's a small tweak I made in my project. I had a widget that needed to take a simple index value to tell it which player is was related to. Unfortunately now most widgets that don't take extra arguments have an extra ignored argument that looks like this _: (), and you have to pass an extra () argument when calling widget, but that's not that bad.

pub trait WidgetSystem: SystemParam {
    type Args;
    fn system(
        world: &mut World,
        state: &mut SystemState<Self>,
        ui: &mut egui::Ui,
        id: WidgetId,
        // Now you can pass arbitrary, yet statically typed, data into the widget
        args: Self::Args,
    );
}

#[derive(SystemParam)]
struct PlayerIndicator<'w, 's> {
    commands: Commands<'w, 's>,
}

impl<'w, 's> WidgetSystem for PlayerIndicator<'w, 's> {
    type Args = usize;
    fn system(
        world: &mut World,
        state: &mut SystemState<Self>,
        ui: &mut egui::Ui,
        id: WidgetId,
        player_idx: usize,
    ) {
        // Widget code
    }
}

#[derive(SystemParam)]
struct WithoutCustomArgs<'w, 's> {
    commands: Commands<'w, 's>,
}

impl<'w, 's> WidgetSystem for WithoutCustomArgs<'w, 's> {
    type Args = ();
    fn system(
        world: &mut World,
        state: &mut SystemState<Self>,
        ui: &mut egui::Ui,
        id: WidgetId,
        // Just ignore custom arguments
        _: (),
    ) {
        // Widget code
    }
}

[dmlary]

Update: The egui-based storage approach presented here is a dead-end. You'll eventually need SystemState to mutably access multiple things in World, but SystemState cannot be cloned, so it can't be stored in egui.

Original content:

If you're ok not having access to Commands, and your per-widget state is small, you can use the temporary per-widget storage present in egui in a similar way. This gets away from SystemParam & the lifetime work, but at the cost of world.spawn(), and the performance hit of the widget state clone.

I'm honestly not sure if the trade-off is worth it, but I'm going down this path for now.

use bevy::prelude::*;
use bevy_egui::egui;

pub trait WidgetSystem: Default + Clone + Send + Sync {
    fn run(&mut self, world: &mut World, ui: &mut egui::Ui, id: egui::Id);
}

pub fn widget<S: WidgetSystem + 'static>(world: &mut World, ui: &mut egui::Ui, id: egui::Id) {
    let mut state = ui
        .memory_mut(|mem| mem.data.get_temp::<S>(id))
        .unwrap_or(S::default());
    state.run(world, ui, id);
    ui.memory_mut(|mem| mem.data.insert_temp(id, state));
}

Usage:

#[derive(Default, Clone)]
pub struct CountingButton {
    count: usize,
}

impl WidgetSystem for CountingButton {
    fn run(&mut self, world: &mut World, ui: &mut egui::Ui, _id: egui::Id) {
        if ui.button(format!("click {}", &self.count)).clicked() {
            world.spawn(Name::new(format!("ClickEntity{}", self.count)));
            self.count += 1;
        }
    }
}

[dmlary]

Ok, so this approach can take you back around to SystemState and managing lifetimes. This happens when you need multiple pieces from &mut World that are blocked by the borrow-checker. SystemState is the tool to split those pieces out of world.

Also for anyone else struggling with the lifetimes for a Query in SystemParam:

#[derive(SystemParam)]
pub struct TilesetList<'w, 's> {
    tilesets: Query<'w, 's, &'static Tileset>,
}

impl<'w, 's> WidgetSystem for TilesetList<'w, 's> {
    fn system(world: &mut World, state: &mut SystemState<Self>, ui: &mut egui::Ui, _id: egui::Id) {
        let params = state.get(world);
        for tileset in &params.tilesets {
            ui.label(format!("tileset {}", tileset.id));
        }
    }
}

[dmlary]

Aaaand, the approach of using egui mem.data.get_temp::<T>() is a dead-end.

SystemState does not implement Clone, so it can't be cloned into egui's temporary storage. egui does not provide any move-based method for storing. This means you can't includea SystemState in your widget struct.

[alice-i-cecile]

Can you mem swap it?

[dmlary]

I wasn’t able to find an interface to get direct access to the stored value: https://docs.rs/egui/latest/egui/util/id_type_map/struct.IdTypeMap.html#method.get_temp

I switched my implementation to use a HashMap Resource for storing state, and that worked well enough. Most of my widgets have no lifetimes, the few I need a SystemState, I add it as a struct member.

[UkoeHB]

With @ItsDoot's recent work evolving this discussion, I came up with a way to do the egui-based widget calls without SystemParam structs. The key is passing the egui stuff by value to an In param, then returning it in the Out param.

Preview (see link):

fn display_number(In((egui_ctx, num)): In<(egui::Context, u32), ... your system parameters ...) -> egui::Context
{
    ...
    egui_ctxt
}

let egui_ui = named_syscall(&mut world, "fps", (egui_ui, fps), display_number);
let egui_ui = named_syscall(&mut world, "health", (egui_ui, health), display_number);

[ItsDoot]

FWIW, you do not need to pass the egui::Context back out, since it is cheaply cloneable (wraps an Arc).

[UkoeHB]

Right, this pattern is more useful for egui::UI (will edit my comment).

[JeanMertz]

@UkoeHB in your example, how would you pass around Ui as a value? As I understand it, you only ever get a mutable reference to this type, after creating a top-level/root widget by passing in a Context (which you can get as an owned value).

update: The answer is, child_ui

[JeanMertz]

@UkoeHB Another thing I wanted to run by you:

If I want nested widgets, I have to have world: &mut World as part of my nested systems (to pass it into named_syscall), which then also means I cannot add any other queries to the system function, right?

Now, I know I can do world.query(...), but that kind of makes the system function stand out compared to other functions in which I write the queries directly in the function arguments, which is unfortunate.

This seems to be the thing that using SystemParam can resolve somewhat more elegantly because that allows you to "move" all your regular Query arguments into the struct fields.

Here's an example of what I mean:

fn navbar(In(ctx): In<Context>, world: &mut World) -> Context {
    egui::TopBottomPanel::top("navbar").show(&ctx, |ui| {
        ui.system(world, "label", "Hello Bevy!".to_owned(), label);
    });

    ctx
}

fn label(
    In((mut ui, text)): In<(Ui, String)>,
    // We don't need access to `&mut World` in this case, but we would
    // if we wanted to next another widget system.
    _world: &mut World,
    foo: Query<&Foo>,
) -> Ui {
    ui.label(&text);
    ui
}

The above won't compile, unless I rewrite label to only take &mut World, and in the body write let foo = world.query::<&Foo>().

[UkoeHB]

If I want nested widgets, I have to have world: &mut World as part of my nested systems (to pass it into named_syscall), which then also means I cannot add any other queries to the system function, right?

Yes this named_syscall approach only lets you have normal systems in the leaf nodes of your call tree.

[Novakasa]

With regards to nesting widgets with this approach, I guess this doesn't really play well with loops over queries? The query implicitly still borrows &mut World through SystemState::new(world), so passing the &mut World to another widget in each iteration is impossible. This seems to me a limitation of this approach compared to just passing the SystemParams through nested function calls from one root ubersystem that passes all the queries/ressources. Am I maybe missing something?

[JeanMertz]

I have a newer version of this

Given that egui is still the preferred UI solution in Bevy for many (at least until bevy_ui gets its much anticipated upgrade/overhaul in the coming months/years), could you share that newer version with the community? Thank you!

[aevyrie]

I recently had some time to revisit improving the widget trait, so I'm exploring the space again. I think the WIP version is all-around nicer, but I'm still trying it out in our codebase to see if there is anything I've missed. Once it's been reviewed internally, I'll see if I can share an update.

[MatLeid]

I really like this approach to create reusable widgets with bevy and egui. It would be a nice way to represent a complex Ui in a bevy app. I would love to see your latest iteration of the code.

[JeanMertz]

Agreed. Keep us posted @aevyrie ❤️

[aevyrie]

It is close to merging internally. I'll keep this in mind and try to share something - I don't mind the occasional ping to remind me!