Improve the Selection Panel with better title, context, and Space View key properties

[abey79]

What

Do not merge until after 0.11.

This PR reworks the Selection Panel to improve the title ("What is selected?"), the context ("Where is the selected thing to be found?"), and the key properties of Space Views (name, origin, type). This is a first step towards the WIP designs by @martenbjork related to blueprints.

Changes:

• Full-width, blue title bar consistent with other panel's style and with the idea that this thing is selected.
• "Context" section listing the place(s) this thing is to be found.
  • This is much more consistant across Item kinds. Previously, stuff was displayed all over the place.
  • From StreamEntity, it's now it's possible to navigate to any related SpaceViewEntity or Space Views. Previously, a button confusingly named after the space view would actually lead to the SpaceViewEntity.
• For Space Views, the Name/Origin/Type are now displayed on top (for all types of space views).
  • This greatly increase the discoverability of the "Name" property. Previously it was hiding in plain sight in what appeared to be contextual information.

Note: the end-game for context is bread-crumbs like these, but that's for another day as we're don't yet have an easy way to walk up the hierarchy:

• Closes Rework how the selected item title is displayed in the Selection Panel #4159
• Closes Display the parent item in a consistent way in the Selection Panel #4288
• Closes Add an explicit "Name" field to Selection Panel when object can be renamed (space view) #4160

Screenshots

Space View:

Group:

Entity in Space View:

Entity in Streams:

Component:

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 demo.rerun.io (if applicable)
• The PR title and labels are set such as to maximize their usefulness for the next release's CHANGELOG

• PR Build Summary
• Docs preview
• Examples preview
• Recent benchmark results
• Wasm size tracking

[nikolausWest]

From a first test, I think it's a pretty straight forward improvement over what we have now. I guess the only thing that is a slight negative is that we no longer write out what the type of the thing you've selected is. Since this info exists on hover and we intend to indicate the type also through a new set of icons in the future I don't think that should be a blocker.

I would just ship this as-is. Good stuff!

[abey79]

@nikolausWest I don't disagree. As a matter of fact, my "design" included explicit type:

We shortly discussed that with @martenbjork who preferred to not overload this title bar. We can certainly revisit this and iterate.

[emilk]

Do not merge until after 0.11.

why not?

[abey79]

why not?

I was seeing this as a first step towards a bigger story, but yeah if we like it we can roll it in 0.11—no technical reason not to. We probably shouldn't delay 0.11 for this though.

[emilk]

I don't know if this is new, but the existence or not of scroll bars causes the width of the header fills to change:

[abey79]

@emilk This is not new, but got more visible with the blue background. I had hoped the floating scroll bars would magically fix it, but it's apparently not the case. I will look into it—at minima, open an issue if we dont have one.

edit: fixed by #4340

[emilk]

I think the // NOLINT is a hint that we're doing something wrong, but otherwise LGTM

[abey79]

I just noticed this PR makes a pre-existing visual glitch way more apparent, see the blue background shrinking when the scroll bar appears.

I believe this is not fixed by #4340, though worth rebasing and checking when it's merged. Nvm, this should be fixed by #4340 now.