Filter entities in the UI (part 3): Move action to a menu in the blueprint panel and keep default blueprint when using heuristics

[abey79]

Related

• Part of Project: filtering entities in the UI (first iteration) #8586
• Part of a series of PR:
  • Filter entities in the UI (part 0): Make CustomContent more useful #8645
  • Filter entities in the UI (part 1): Introduce a filter widget #8652
  • Filter entities in the UI (part 2): Introduce entity filtering in the time panel #8654
  • Filter entities in the UI (part 3): Move action to a menu in the blueprint panel and keep default blueprint when using heuristics #8672
  • ...

What

In preparation for adding the filter UI in the blueprint panel, we must move the current actions (add view/container, reset blueprint) to a "more" (…) icon menu. This in turn allows us to be explicit with the reset actions, and have both "reset to default" and "reset to heuristics" (like in the application's selection panel).

In turn, this exposes the weird behaviour where resetting to heuristics also deletes the current blueprint, for no reason other than it made implementation easier. This PR fixes that. So it's not possible to reset to heuristics and then go back to the default blueprint.

Also:

• Remove the "Reset to default"/"Rest to heuristic" buttons from the application selection panel (double duty).
• Reworded the "Reset to heuristics" command palette actions for consistency
  • See also: Add "Reset to default blueprint" to the command palette #8677

new-blueprint-panel-more-menu.mp4

[github-actions]

Web viewer built successfully. If applicable, you should also test it:

• I have tested the web viewer

Result	Commit	Link	Manifest
✅	c5bc66b	https://rerun.io/viewer/pr/8672	+nightly +main

^{Note: This comment is updated whenever you push a commit.}

[emilk]

Makes sense, but it is also all very confusing to me, because we are inconsistent in the naming.

We have the default blueprint (fine), and then we have the "automatic" "generated" "heuristic" blueprint. I wish we could settle on one name for it, instead of three.

[emilk]

I don't follow this. Why do we need to explicitly engage the heuristics to restore the default blueprint? Is the heuristic bools not part of the actual blueprint? If not, why aren't they reset automatically when there is no blueprint (i.e. after a reset)?

[abey79]

Bad wording on my end, I meant to imply that the default blueprint (if any) is left alone, so the user may restore it later on. I've rewritten entirely that (and other) comment to clarify this.

[emilk]

I wonder if we can come up with better copy here. "Create automatic blueprint"? Maybe @gavrelina has ideas

[abey79]

We discussed that and decided to stick with "heuristics" for now.

[abey79]

We have the default blueprint (fine), and then we have the "automatic" "generated" "heuristic" blueprint. I wish we could settle on one name for it, instead of three.

I tried to further cleaned that up. We should never use "generated". We agree to keep "heuristics" for user-facing stuff. We still have auto_layout/auto_view in the code. Maybe we should renamed those as well, but I'll keep that for another day.