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

Support modifying the plot style by introducing a generic framework for overriding components #4914

Merged
merged 27 commits into from Jan 29, 2024

Conversation

jleibs
Copy link
Member

@jleibs jleibs commented Jan 25, 2024

What

This tackles the problem of allowing SeriesStyle components to be overridden by building out a significant chunk of a general component override framework.

The new UI is limited to TimeSeriesScalar view at the moment because it still requires special Visualizer-side handling of the component data.

High level idea

When selecting an entity within a space-view, we now have the ability to override any component that is both queried by the visualizer, and for which we have a registered component-editor.

This override value is initialized based on looking for, in order:

  • The current value of the component for the entity
  • A value provided by the Visualizer (useful for things like matching the current auto-color)
  • A default value provided by a function registered along with the editor.

Notable changes:

  • Adds a new mechanism to the Component UI Registry that allows us to register editors and default-value providers for any component.
  • Adds a mechanism to all visualizers to find out the full set of components they query.
  • During the update_overrides process, we now checks the appropriate location in the blueprint override tree and insert the path to any overridden components into the DataResult.
  • In the TimeSeriesSpaceView we now respect any overrides that come from the DataResult.
  • Introduce a new Override Components UI in the seleciton panel, which allows us to add an override using a default-provided, or visualizer-provided initial value.
  • Once the override has been added, the override UI dispatches to the registered editor for each overridden component.

Screenshot

image

Checklist

  • I have read and agree to Contributor Guide and the Code of Conduct
  • I've included a screenshot or gif (if applicable)
  • I have tested the web demo (if applicable):
  • The PR title and labels are set such as to maximize their usefulness for the next release's CHANGELOG

@jleibs jleibs added the 🟦 blueprint The data that defines our UI label Jan 25, 2024
@jleibs jleibs changed the title New framework and UI for overriding components Support modifying the plot style by introducing a generic framework for overriding components Jan 25, 2024
@jleibs jleibs marked this pull request as ready for review January 25, 2024 23:18
@Wumpf Wumpf self-requested a review January 26, 2024 15:53
Copy link
Member

@Wumpf Wumpf left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

absolutely marvelous and not as complex as I feared it would be.

Comments are mostly starts of discussions, some of which we should have over Zoom or Slack instead, some of which need to be postponed.
The only thing that I believe is actually wrong is how initial overrides are determined (see comments). But since this won't affect the time series space view, I'll approve anyways (:

fn edit_color_ui(
ctx: &ViewerContext<'_>,
ui: &mut egui::Ui,
_verbosity: UiVerbosity,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if ui verbosity ever makes sense for editors. Aren't they always only available at full verbosity?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it will eventually. I suspect there will be both a Small/Inline editor for some things, when it's appropriate, but I could imagine a way of expanding that to a more "full" multiline editor that we won't always want to show in the selection panel by default.

Comment on lines +209 to +220
let override_color = lookup_override::<Color>(data_result, ctx).map(|c| {
let arr = c.to_array();
egui::Color32::from_rgba_unmultiplied(arr[0], arr[1], arr[2], arr[3])
});

let override_label =
lookup_override::<Text>(data_result, ctx).map(|t| t.to_string());

let override_scattered =
lookup_override::<ScalarScattering>(data_result, ctx).map(|s| s.0);

let override_radius = lookup_override::<Radius>(data_result, ctx).map(|r| r.0);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

let's discuss after this PR how we can make this pattern nice, easy and fast. Overall doesn't look as bad as I thought it would (:

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, it's not awful, esp since we restrict things to splats at the moment, but I'd still love to have it automagically happen inside one of the archetype-view-style generic queries.

crates/re_viewer/src/ui/selection_panel.rs Show resolved Hide resolved
crates/re_viewer/src/ui/selection_panel.rs Outdated Show resolved Hide resolved
crates/re_viewer/src/ui/override_ui.rs Outdated Show resolved Hide resolved
}
})
.or_else(|| {
system_for_initial_value.initial_override_value(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this doesn't check out for me: The system for the initial value may not have brought up the component that we're on right now.
I think what you iterate instead is pairs of component-visualizer where you somehow removed duplicated components, i.e. decided which visualizer would provide the initial override value :/

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aha! Yes, good catch. Changed to build a map of Component -> Visualizer and use the right now.

return;
};

initial_data.compute_size_bytes();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why is this needed?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤷 it's always needed when we write data to the store or else we get errors about using data that hasn't been sized yet.

crates/re_viewer/src/ui/selection_panel.rs Outdated Show resolved Hide resolved
crates/re_viewer/src/ui/override_ui.rs Outdated Show resolved Hide resolved
@jleibs jleibs merged commit 5d9b278 into main Jan 29, 2024
40 of 41 checks passed
@jleibs jleibs deleted the jleibs/component_overrides branch January 29, 2024 23:54
@abey79 abey79 added ui concerns graphical user interface 📺 re_viewer affects re_viewer itself and removed ui concerns graphical user interface labels Feb 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🟦 blueprint The data that defines our UI include in changelog 📺 re_viewer affects re_viewer itself
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants