Advanced Timeline Filtering

[AaronPlave]

Implements dynamic activity filtering for the timeline. Closes #1391, closes #973. Potentially addresses #1138.

Changes:

• Update the way activities are specified in the UI view to support dynamic filtering. This includes a list of manually selected types ORed with a list of dynamically specified types ANDed with a list of global filters on the directives and spans themselves. Each resulting type can also contain a list of global filters targeted at instances of that specific type.
• Implement activity filtering popover. Popover provides the UI to back the view changes for activity filtering. The user can manually add and remove types, dynamically select types by Type and Subsystem, globally filter instances by Name, Parameter (filtered appropriately by the current list of resulting types), Tag, and Scheduling Goal ID. The user can also add and remove filters (the same as global filters) on specific resulting types. Popover component is draggable and resizable.
• Update Timeline Items browser (Activity, Resource, Event Types panel) to conform to the new filtering schema and use dynamic filtering whenever appropriate.
• Change the UI view resource filter specification to be a string instead of a list since only one resource can be logically selected for a layer.
• Update resource filtering to be single select
• Update CssGrid with columnMinSizes and rowMinSizes props to support min width and height for css grid sections
• Restyle searchable dropdown selected state appearance and add a checkmark
• Add Draggable window component
• Add Resizable box component
• Fetch all initial/default activity type arguments so that Parameters can be filtered client side
• Create a subsystem tags store derived from activity types store
• Use Tanstack Virtual svelte package to virtualize the SearchableDropdown and TimelineItemList to achieve acceptable performance for long lists
• Bump UI View version to 2 and create relevant migrations.

Testing (TODO):

• Use it
• Migrate

TODO:

• Blocked: Awaiting design – Implement basic resource and event filtering
• Test scheduling goal ID
• Performance testing
• Provide a mechanism for a user to easily specify that they want all activity types All Activities timeline #973
• UI View migration
• Write tests
• Code review
• Documentation
• Make issue for using the new default activity args cache instead of calling getEffectiveArguments every time a user clicks on an activity

[dandelany]

Met with @AaronPlave and @lklyne about remaining tasks this morning. All of the new functionality for advanced filtering of activities is done on this branch and available for testing on our (JPL internal) aerie-test instance. However there is still a bit of design + UI work to be done on integrating this work with the row editor in the Timeline Editor pane. Specifically:

• When the user is editing a row in the Timeline Editor, the layers on the row are now split into three categories: Activity Layers, Resource Layers and Event Layers
• The UI for these sections needs to be refined - currently some inconsistencies in design & behavior.
• The 3 types of layers have some common characteristics but some intentional differences, we should have a UI that keeps them as consistent-looking as possible while accounting for their differences
• Things in common between Activity, Resource and Event layers:
  • All have buttons to add layer, delete layer, and delete all layers
  • All have the ability to set a user-defined layer name, plus should have some space to optionally show a subtitle, such as the name of the underlying resource or a summary of activity filters.
  • All have a color swatch for setting the layer color
• Differences between layer types:
  • Activity layers now select a set of filters via the new modal window, instead of just a list of activity types
    • Per original design, they should also show the number of matching activity instances in the plan, if not too difficult to implement
  • Resource layers now only allow users to select a single resource per layer. Formerly the UI "allowed" selecting multiple but it didn't really work correctly.
    • they also have a settings icon + popover, and a selector for chart type (line vs. x-range)
  • Event layers allow the user to select multiple [external] event types to show on a single layer, unlike resources.

@lklyne will work on a unified UI design for handling these different types in a consistent way + then handoff to @AaronPlave to implement on this branch.