Struct re_viewer_context::component_ui_registry::ComponentUiRegistry

pub struct ComponentUiRegistry {
    fallback_ui: Box<dyn Fn(&ViewerContext<'_>, &mut Ui, UiLayout, &LatestAtQuery, &EntityDb, &EntityPath, Option<RowId>, &dyn Array) + Send + Sync>,
    legacy_display_component_uis: BTreeMap<ComponentName, Box<dyn Fn(&ViewerContext<'_>, &mut Ui, UiLayout, &LatestAtQuery, &EntityDb, &EntityPath, Option<RowId>, &dyn Array) + Send + Sync>>,
    component_singleline_edit_or_view: BTreeMap<ComponentName, Box<dyn Fn(&ViewerContext<'_>, &mut Ui, &dyn Array, EditOrView) -> Option<Box<dyn Array>> + Send + Sync>>,
    component_multiline_edit_or_view: BTreeMap<ComponentName, Box<dyn Fn(&ViewerContext<'_>, &mut Ui, &dyn Array, EditOrView) -> Option<Box<dyn Array>> + Send + Sync>>,
}

How to display components in a Ui.

Fields

fallback_ui: Box<dyn Fn(&ViewerContext<'_>, &mut Ui, UiLayout, &LatestAtQuery, &EntityDb, &EntityPath, Option<RowId>, &dyn Array) + Send + Sync>

Ui method to use if there was no specific one registered for a component.

legacy_display_component_uis: BTreeMap<ComponentName, Box<dyn Fn(&ViewerContext<'_>, &mut Ui, UiLayout, &LatestAtQuery, &EntityDb, &EntityPath, Option<RowId>, &dyn Array) + Send + Sync>>

Older component uis - TODO(#6661): we’re in the process of removing these.

The main issue with these is that they take a lot of parameters: Not only does it make them more verbose to implement, it also makes them on overly flexible (they know a lot about the context of a component) on one hand and too inflexible on the other - these additional parameters are not always be meaningful in all contexts. -> They are unsuitable for interacting with blueprint overrides & defaults, as there are several entity paths associated with single component (the blueprint entity path where the component is stored and the entity path in the store that they apply to).

Other issues:

• duality of edit & view: In this old system we didn’t take into account that most types should also be editable in the UI. This makes implementations of view & edit overly asymmetric when instead they are often rather similar.
• unawareness of ListItem context: We often want to display components as list items and in the older callbacks we don’t know whether we’re in a list item or not.

component_singleline_edit_or_view: BTreeMap<ComponentName, Box<dyn Fn(&ViewerContext<'_>, &mut Ui, &dyn Array, EditOrView) -> Option<Box<dyn Array>> + Send + Sync>>

Implements viewing and probably editing

component_multiline_edit_or_view: BTreeMap<ComponentName, Box<dyn Fn(&ViewerContext<'_>, &mut Ui, &dyn Array, EditOrView) -> Option<Box<dyn Array>> + Send + Sync>>

Implements viewing and probably editing

Implementations

impl ComponentUiRegistry

pub fn new( fallback_ui: Box<dyn Fn(&ViewerContext<'_>, &mut Ui, UiLayout, &LatestAtQuery, &EntityDb, &EntityPath, Option<RowId>, &dyn Array) + Send + Sync> ) -> Self

pub fn add_legacy_display_ui( &mut self, name: ComponentName, callback: Box<dyn Fn(&ViewerContext<'_>, &mut Ui, UiLayout, &LatestAtQuery, &EntityDb, &EntityPath, Option<RowId>, &dyn Array) + Send + Sync> )

Registers how to show a given component in the UI.

If the component has already a display UI registered, the new callback replaces the old one.

pub fn add_singleline_edit_or_view<C: Component>( &mut self, callback: impl Fn(&ViewerContext<'_>, &mut Ui, &mut MaybeMutRef<'_, C>) -> Response + Send + Sync + 'static )

Registers how to view, and maybe edit, a given component in the UI in a single list item line.

If the component already has a singleline editor registered, the new callback replaces the old one.

Typed editors do not handle absence of a value as well as lists of values and will be skipped in these cases. (This means that there must always be at least a fallback value available.)

The value is only updated if the editor callback returns a egui::Response::changed. On the flip side, this means that even if the data has not changed it may be written back to the store. This can be relevant for transitioning from a fallback or default value to a custom value even if they are equal.

Design principles for writing editors:

• This is the value column function for a re_ui::list_item::PropertyContent, behave accordingly!
  • Unless you introduce hierarchy yourself, use re_ui::list_item::ListItem::show_flat.
• Don’t show a tooltip, this is solved at a higher level.
• Try not to assume context of the component beyond its inherent semantics (e.g. if you get a Color you can’t assume whether it’s a background color or a point color)
• The returned [egui::Response] should be for the widget that has the tooltip, not any pop-up content.
  • Make sure that changes are propagated via [egui::Response::mark_changed] if necessary.

pub fn add_multiline_edit_or_view<C: Component>( &mut self, callback: impl Fn(&ViewerContext<'_>, &mut Ui, &mut MaybeMutRef<'_, C>) -> Response + Send + Sync + 'static )

Registers how to view, and maybe edit, a given component in the UI with multiple list items.

If the component already has a singleline editor registered, the new callback replaces the old one.

Typed editors do not handle absence of a value as well as lists of values and will be skipped in these cases. (This means that there must always be at least a fallback value available.)

The value is only updated if the editor callback returns a egui::Response::changed. On the flip side, this means that even if the data has not changed it may be written back to the store. This can be relevant for transitioning from a fallback or default value to a custom value even if they are equal.

Design principles for writing editors:

• This is the content function for hierarchical re_ui::list_item::ListItem, behave accordingly!
• Try not to assume context of the component beyond its inherent semantics (e.g. if you get a Color you can’t assume whether it’s a background color or a point color)
• The returned [egui::Response] should be for the widget that has the tooltip, not any pop-up content.
  • Make sure that changes are propagated via [egui::Response::mark_changed] if necessary.

fn add_editor_ui<C: Component>( &mut self, multiline: bool, callback: impl Fn(&ViewerContext<'_>, &mut Ui, &mut MaybeMutRef<'_, C>) -> Response + Send + Sync + 'static )

pub fn registered_ui_types(&self, name: ComponentName) -> ComponentUiTypes

Queries which UI types are registered for a component.

Note that there’s always a fallback display UI.

pub fn ui( &self, ctx: &ViewerContext<'_>, ui: &mut Ui, ui_layout: UiLayout, query: &LatestAtQuery, db: &EntityDb, entity_path: &EntityPath, component_name: ComponentName, unit: &UnitChunkShared, instance: &Instance )

Show a UI for a component instance.

Has a fallback to show an info text if the instance is not specific, but in these cases LatestAtComponentResults::data_ui should be used instead!

pub fn ui_raw( &self, ctx: &ViewerContext<'_>, ui: &mut Ui, ui_layout: UiLayout, query: &LatestAtQuery, db: &EntityDb, entity_path: &EntityPath, component_name: ComponentName, row_id: Option<RowId>, component_raw: &dyn Array )

Show a UI for a single raw component.

pub fn multiline_edit_ui( &self, ctx: &QueryContext<'_>, ui: &mut Ui, origin_db: &EntityDb, blueprint_write_path: &EntityPath, component_name: ComponentName, row_id: Option<RowId>, component_array: Option<&dyn ArrowArray>, fallback_provider: &dyn ComponentFallbackProvider )

Show a multi-line editor for this instance of this component.

Changes will be written to the blueprint store at the given override path. Any change is expected to be effective next frame and passed in via the component_query_result parameter. (Otherwise, this method is agnostic to where the component data is stored.)

pub fn singleline_edit_ui( &self, ctx: &QueryContext<'_>, ui: &mut Ui, origin_db: &EntityDb, blueprint_write_path: &EntityPath, component_name: ComponentName, row_id: Option<RowId>, component_query_result: Option<&dyn ArrowArray>, fallback_provider: &dyn ComponentFallbackProvider )

Show a single-line editor for this instance of this component.

Changes will be written to the blueprint store at the given override path. Any change is expected to be effective next frame and passed in via the component_query_result parameter. (Otherwise, this method is agnostic to where the component data is stored.)

fn edit_ui( &self, ctx: &QueryContext<'_>, ui: &mut Ui, origin_db: &EntityDb, blueprint_write_path: &EntityPath, component_name: ComponentName, row_id: Option<RowId>, component_array: Option<&dyn ArrowArray>, fallback_provider: &dyn ComponentFallbackProvider, allow_multiline: bool )

pub fn edit_ui_raw( &self, ctx: &QueryContext<'_>, ui: &mut Ui, origin_db: &EntityDb, blueprint_write_path: &EntityPath, component_name: ComponentName, row_id: Option<RowId>, component_raw: &dyn Array, allow_multiline: bool )

pub fn try_show_edit_ui( &self, ctx: &ViewerContext<'_>, ui: &mut Ui, raw_current_value: &dyn Array, blueprint_write_path: &EntityPath, component_name: ComponentName, allow_multiline: bool ) -> bool

Tries to show a UI for editing a component.

Returns true if the passed component is a single value and has a registered editor for multiline or singleline editing respectively.