Project: filtering entities in the UI (first iteration)

[abey79]

Summary description

Implement the first iteration of a text-based entity path filtering for the streams, blueprint and add/remove entities trees. (The operative words being "first iteration".)

• Fixes Add filtering to blueprint view #4597

Background and grounding use-cases

The primary (and only means) of finding entities in (large) recordings currently consists of scrolling through the list. This is obviously cumbersome and annoying as soon as the list of entities grows. This is compounded by the streams tree not being tall in the UI by construction (a conundrum that proved tricky to resolve so far).

This project is thus about making it easy to find the needle(s) in the entity haystack, in a way that is local to the following areas:

• streams tree
• blueprint tree
• add/remove entity modal

Impact on Entity Path Filter

Although this project (and the general feature of filter-based searching in the UI) is technically independent of the entity path filter stuff (at least initially), it is related in the sense that both are about filtering the list of entities. For consistency, expanding the feature set on one side should typically be mirrored on the other side, lest users get confused. This is particularly true for any syntax introduced to match entities (glob, etc.).

In this spirit of keeping this (design) complexity in check, this project is narrowly scoped on this front.

Designs and plans

Figma designs

The primary paradigm of this first iteration is to introduce text field that are local to the list to be filtered.

Search widget

Search icon -> click -> search widget appears and "replaces" section title:

This applies to both streams and blueprint trees.

Note: for the blueprint tree, this implies moving the reset and + button to a ... more menu, to leave room for the filter widget:

Add/remove modal

Search widget is permanently displayed (no toggling behaviour):

Highlight

Query is highlighted in the displayed entity:

Note: highlight color in add/remove entity modal is slightly subdued because of the background thing we have there.

Tasks

•  Implement the search widget
• Implement highlighting
• Add search widget to streams panel + implement filtering in tree
• Add search widget to blueprint panel + implement filtering in tree
• Add search widget to the add/remove entities modal + implement filtering in tree
• Stretch/TBD: non-trivial query syntax (keyword, fuzzy, glob, etc.—see discussion above)

Non-goals

These are all very useful/needed addition to the base filter feature, but are outside of the scope of this initial project.

TODO: open issues of all of these!

• Have custom search settings (accessibly via a setting icon).
  
• Have one such setting be listing entities as a list instead of a hierarchy
  
• Search by component
• Much needed thorough Add/remove entity modal overhaul, e.g.:
  
• Global "search everywhere" feature: Global fuzzy filtering that applies _everywhere_ #5233

[abey79]

The naive "find the query string within the full entity path" matching semantics proved to be hellish when it comes to highlighting matches, so we further discussed the match semantics with Katya and settled on the following progression. We converged on this proposal because it strikes a balance between implementation complexity, usefulness, and intuitiveness (aka minimise user astonishment).

I'll start with level 0 for now and build on that later on if/when time/alignment allows.

Level 0: per-entity-part match

For a match, at least one entity part must contain the entire query string. In that context, whitespace and / are considered text that must be present within the entity part (not path).

Note: forbidding whitespace and / in the query field would usefully set user expectations for the feature at this level.

Query	Matches	Doesn't match
"hello"	/a/b/hello/o /a/xxxhelloyyy	/hel/lo
"hel/lo"	/"hel/lo"/world	/hel/lo
"hel lo"	/"hel lo"/world	/hel/lo

Level 1: space-separated keywords

Whitespace in the query string defines multiple keywords. Each of the keywords must be contained in at least one of the entity parts to match. Keywords otherwise retain the semantics of level 1.

Note: as before, forbidding / at this level seems like a good idea.

Query	Matches	Doesn't match
"hello world"	/a/b/hello/world /a/helloworld	/world/ /hel/lo/world
"hello/ world"	/"hello/"/world	/hello/world
"hello/world"	/a/"hello/world"/b	/hello/world

Level 2: slashes define part boundaries

Within keyword, starting or ending slashes define boundary requirements, similar to regex's $ and ^. Also, slashes within a keyword define a constraint on parts neighborhood.

So, for each keyword:

• query/ -> at least one part must end with "query"
• /query -> at least one part must start with "query"
• hello/world -> at least one part must end with "query", AND must be followed by a part starting with "world"

Query	Matches	Doesn't match
"hello world"	/a/b/hello/world /a/helloworld	/world/ /hel/lo/world
"hello/ world"	/hello/world /blahello/c/world	/hellobla/world
"hello /world"	/hello/world /hello/c/worldbla	/hello/blaworld
"hello/world"	/a/hello/world/b	/hello/b/world /hello/blaworld
"a/b/c"	/x/y/bla/b/crap	/x/y/bla/bro/crap /x/y/bla/b/lol/crap