bevy-inspector-egui V2 - call for feedback

[jakobhellermann]

I've been rewriting bevy-inspector-egui to work just on Reflect and obsolete the Inspectable trait, while also improving a bunch of other things, and wanted to get feedback on some design decisions.

First, some background:

Background (optional)

When I first started the inspector, it was very focused around the Inspectable trait, which you can derive to get a fn ui(&mut self, ui: &mut egui::Ui, ...) that you can execute to display the UI.
The way you could use this was with the InspectorPlugin<T: Inspectable> which would insert T as a resource that you could then you.
Later, someone contributed a "world inspector", which let you just display all entities together without having to create your inspectable resource. For me this world inspector became the only thing I used because of the simplicity of just adding WorldInspectorPlugin and being done with it, and for the flexibility of inspecting every entity and component there is in the world.
For the world inspector to work I added a InspectableRegistry resource, which is a HashMap<TypeId, fn(&mut ?, ui: &mut egui::Ui, ...) and had to register every type that derived or implemented Inspectable on it: app.register_inspectable::<Type>(). This was particularly annoying because everyone that defined their custom components also had to do it in order to get their type displayed in the world inspector.
Meanwhile, bevy_reflect had been gaining functionality and usage, so I hacked on Reflect support into bevy-inspector-egui. If you derived (and registered) Reflect for a type, that type would show up in the world inspector, but it was always a second class citizen, you couldn't derive Inspectable with just Reflect fields, and the Reflected component could not define attributes like min = 0.0, max = 1.0.

The rewrite

This is where the rewrite comes in, instead of focusing on the Inspectable trait which 1. enables walking the type hierarchy and 2. can render UI I realised that I could do the same by just using Reflect to inspect the "structure/shape" of a type and write a

fn ui_for_reflect(value: &mut dyn Reflect, ui: &mut egui::Ui, ...) {
  ..
}

function that displays the UI.
That way, users of the library don't have to #[derive(Inspectable)] anymore, the can just use #[derive(Reflect)] which is useful for other things as well.
On top of this, I also reimplemented the world inspector, which now looks like this:

fn ui_for_world(&mut World, ui: &mut egui::Ui) {
  // pseudocode
  for entity in world.query::<Without<Parent>>() {
    ui_for_entity(entity);
  }
  for resource in world.resources() {
    ui_for_resource(resource);
  }
  for asset in world.assets() {
    ui_for_asset(asset);
  }
}

It would be very easy to build your own specific UI as well with these building blocks.

Options

This still leaves open the question of how to represent #[inspectable(min = 0.0, max = 1.0)] options.
The way I settled this is by introducing a type, InspectorOptions, which can represent these field -> arbitrary options and can be derived separately:

#[derive(Reflect, InspectorOptions)]
#[reflect(InspectorOptions)] // register the `InspectorOptions` as well when calling `app.register::<MyType>()>`
struct MyType {
  #[inspector(min = 0.0, max = 1.0)]
  value: f32,
}

The Questions

Before polishing this and releasing this (hopefully with bevy 0.9) I'd like to get some feedback on a few design decisions and also look at what people actually want to use this for.
I'll open separate comments on the discussion for each question.

• Actual Use Cases
• Ergonomics of the InspectorOptions derive
• Reusability outside of bevy

Feel free to open any other comments below.

[jakobhellermann]

Actual Use Cases

Or what do you want from the inspector?

• a no-thoughts-required WorldInpectorPlugin that you can add to your app and it shows a window with your entities, maybe even resources, assets, events
• a build-your-own-editor-ui toolkit that allows you to write your own app specific UI without having to know all the details. Something like

fn show_inspector_system(world: &mut World);
  egui::Window::new("Inspector").show(|ui| {
    egui.collapsing("Settings", |ui| {
      bevy_inspector_egui::ui_for_resource::<GameSettings>(world); 
    });
    egui.collapsing("Entities", |ui| {
      bevy_inspector_egui::ui_for_entities(world); 
    });
  }
}

Also how powerful should the default world inspector be? Do you want to search for entities? For components? Same question for potentially displaying resources.
Or would you rather just have such functionality be packaged up into a more editor-like crate like https://github.com/jakobhellermann/bevy_editor_pls.

Any other feature requests can go here too.

[IceSentry]

Personally, I prefer the toolkit approach. A world inspector could just be one building block of that toolkit though.

[askor]

I really like to have both. My entry into Bevy and Rust has been difficult. Having a no-thoughts-required plugin to give me some insight into the game has been very helpful. Now that I'm more advanced, I'm making my own ui, and love the options there.

[jakobhellermann]

I wrote a README for my rework branch, it documents both the quick drop-in plugin and the customization abilities: https://github.com/jakobhellermann/bevy-inspector-egui/tree/rework

[jakobhellermann]

Ergonomics of the InspectorOptions derive

In my current prototype the way to define options for your type is

#[derive(Reflect, InspectorOptions)]
#[reflect(InspectorOptions)] // register the `InspectorOptions` as well when calling `app.register::<MyType>()>`
struct MyType {
  #[inspector(min = 0.0, max = 1.0)]
  value: f32,
}


#[derive(Reflect, InspectorOptions)]
#[reflect(InspectorOptions)]
enum Shape {
  Box(#[inspector(min = Vec3::ZERO)] Vec3),
  Icosphere {
    #[inspector(min = 1)]
    subdivisions: usize,
    #[inspector(min = 0.1)]
    radius: f32,
  },
}

or manually

let mut options = InspectorOptions::default();
options.insert(Target::Field(0), NumberOptions::<f32>::between(0.0, 1.0));
type_registry.insert::<MyType, ReflectInspectorOptions>(ReflectInspectorOptions(options));

If you preferred to not have another derive next to Reflect, we could also build this "associate fields with data" mechanism directly into bevy_reflect:

#[derive(Reflect)]
struct MyType {
  #[reflect_attr(InspectorOptions, min = 0.0, max = 1.0)]
  value: f32,
}

#[derive(Reflect)]
enum Shape {
  Box(#[reflect_attr(InspectorOptions, min = Vec3::ZERO)] Vec3),
  Icosphere {
    #[reflect_attr(InspectorOptions, min = 1)]
    subdivisions: usize,
    #[reflect_attr(InspectorOptions, min = 0.1)]
    radius: f32,
  },
}

Which one do you prefer?

[MrGVSV]

The attribute idea would be really nice to have in general for bevy_reflect. Here, though, I personally think it's nicer to have the derive. It cuts down on rewriting InspectorOptions over and over again so the attributes are shorter and cleaner.

Also, I wanted to mention that I really like the type data approach overall. It allows users to configure reflectable types that they don't own really easily it would seem (they can just register InspectorOptions themselves).

[jakobhellermann]

Reusability outside of bevy

The core fn ui_for_reflect(value: &mut dyn Reflect, ui: &mut egui::Ui, ..) function can work independant of bevy_ecs, just using bevy_reflect. The function is made to be extensible so that additional code can be executed at each value in the UI, like checking if the type is a Handle<StandardMaterial> and instead of displaying an ID directly looking up the material in the World.

Would anyone want to reuse the ui_for_reflect and InspectorOptions without depending on bevy, the engine?
If so, I could split the crate into a bevy-independant "reflect egui inspector" and the bevy-specific bevy-inspector-egui.

The bevy_reflect_inspector crate could be useful for non-egui inspector implementations (e.g. autocomplete on a console, or json schema generation).

[jakkos-net]

I'm aware I'm pretty late to this thread, but if this is still under consideration, this would be really helpful for me!

[nicopap]

Someone made a crate inspired by bevy-inspector-egui specifically to get the same capabilities for games not build with bevy, so there is probably some demand https://crates.io/crates/guiedit

[jakobhellermann]

I'm aware I'm pretty late to this thread, but if this is still under consideration, this would be really helpful for me!

Are you interested in using the inspector without bevy or InspectorOptions without egui?

[jakkos-net]

Sorry for not being specific, I'd want to use the inspector with egui but without bevy

[jakkos-net]

Someone made a crate inspired by bevy-inspector-egui specifically to get the same capabilities for games not build with bevy, so there is probably some demand

https://github.com/Meisterlama/egui_inspect also exists, but doesn't seem to be maintained