Panel toggle buttons should not be disabled when panel state overrides are set

[gavrelina]

Problem

When the web viewer is embedded (e.g. arkit), the host page calls override_panel_state() to hide panels for a clean initial look in the context of web. This correctly hides the panels, but also disables the toggle buttons — making it impossible for users to open them without entering fullscreen first.

The override API conflates two concerns:

1. Setting the panel's visible state (intended)
2. Disabling user interaction with the toggle button (unintended)

Root cause

In top_panel.rs, the panel toggle buttons use *_overridden() as a disable condition (for all three panels):

ui.add_enabled_ui(                                                                          
      route.has_selection_panel() && !app_blueprint.selection_panel_overridden(),
      ...                                                                                     
  ); 

When an override exists, the button is grayed out, the toggle action is also blocked through hot keys.

Proposed fix after chatting to claude

• top_panel.rs: Remove !app_blueprint.*_panel_overridden() from the three add_enabled_ui conditions
• app_blueprint.rs: Remove the early returns in toggle_*_panel() so clicking the button works, and toggle from the effective state (self.*_panel_state()) rather than the blueprint store value (self.panel_states.*)
• Clear the override for that panel on toggle so it doesn't fight back on the next frame (?)

[Yadav108]

Hi @gavrelina and Rerun maintainers,

I'd like to work on this issue. The analysis looks spot-on — the current implementation conflates panel visibility control with UI interactivity, which breaks the user experience in embedded contexts.

Understanding of the Problem

When override_panel_state() is called (common in web embeds like the ARKit scenes example), the viewer correctly hides panels but also disables the toggle buttons. This prevents users from reopening panels without entering fullscreen mode, which defeats the purpose of providing clean initial state while preserving user control.

The root cause is in top_panel.rs where add_enabled_ui() uses *_overridden() as a disable condition:

ui.add_enabled_ui(
    route.has_selection_panel() && !app_blueprint.selection_panel_overridden(),
    ...
);

This couples two distinct concerns:

1. Initial visibility state (what override_panel_state should control)
2. User interactivity (which should remain enabled)

Proposed Implementation Approach

Following the suggested fix:

1. top_panel.rs changes

Remove the !app_blueprint.*_panel_overridden() checks from add_enabled_ui for all three panels (Selection, Blueprint, Time). This allows buttons to remain interactive even when overrides are active.

2. app_blueprint.rs modifications

• Modify toggle_*_panel() methods to:
  • Toggle from the effective state (self.*_panel_state()) rather than the blueprint store value
  • Clear the override for that panel when toggled, preventing state conflicts
  • Ensure the toggle behavior feels natural and doesn't "fight" with the override on subsequent frames

3. Hotkey handling

Keyboard shortcuts should follow the same logic as button clicks — toggle from effective state and clear overrides.

Questions Before Starting

1. Override clearing strategy: Should we clear the override immediately on button press, or only after the panel state successfully changes? The latter might provide better immediate mode consistency.

2. State persistence: When a user toggles a panel that had an override, should that preference persist across sessions, or should it be ephemeral?

3. Documentation update: The override_panel_state() API docs should clarify this behavior. Should I include doc updates in the PR?

4. Testing approach: Are there existing tests for panel override behavior, or should I add new integration tests covering the embedded viewer scenario?

Timeline & Background

I can submit a PR within 5-7 days including:

• Implementation across both files
• Testing with the ARKit embedded example
• Documentation updates if desired

Background: I've worked on optimization and architecture work in similar contexts (on-device ML inference, performance-critical systems), though this would be my first contribution to Rerun specifically.

Let me know if this approach aligns with the team's vision, or if there are architectural considerations I should account for!