Filter entities in the UI (part 2): Introduce entity filtering in the time panel

[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
  • ...

What

This PR introduces the filter widget to the time panel. In doing so, it deals with several shenanigans:

• The item collapsedness must not be shared between the unfiltered view, and across different filtering sessions
  Note: the collapsed state being persisted, we are now accumulating collapsedness state for every single filter session in the persistant storage. This is not ideal, but addressing that would required rolling our own collapsed state, which would leak all over the place (list item and many of its users).
• The collapse/expend all context menu must be made aware of what precedes.
• The time panel filter state must be invalidated upon switching active recording (otherwise it's weird UX).
• The streams tree UI area needs to have a minimum width otherwise search icon placement/layout breaks.

And of course the actual filtering logic must be implement. For now, the semantics are: "one of the entity part must contain the query string in its entirety". This is very (too) basic and will evolve in future PR (see #8586 (comment)).

streams_tree_filter.mp4

Next step

Major next steps:

• have filters in more places (primarily blueprint tree)
• make the filter semantics more useful

[github-actions]

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

• I have tested the web viewer

Result	Commit	Link	Manifest
✅	9b1d3db	https://rerun.io/viewer/pr/8654	+nightly +main

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

[Wumpf]

lgtm, get to have this in

Unfortunately makes an existing perf issue more prominent: We try to show the histogram for everything that's expanded and once there's a search we expand everything. We need to figure out how to disable the histogram showing code but this isn't an issue introduced here.

[Wumpf]

This feels wrong: Can we keep the id on the RecordingConfig so that we don't loose the filter when changing recording?
If a user wants to go back and forth between two similar recording this lack of state keeping can be very annoying.

[abey79]

Well I added that precisely because I wanted to disable the filter upon recording change, because it was extremely annoying to have it. Now that you mention it, I see how it could be useful to have it.

My suggestion would be to use the app id instead. Makes sense to you?

[Wumpf]

oh yeah that sounds great, then the filter sticks with the different recordings within the same app 💡