refactor filter, results, & visualization

[prjemian]

There seems to be some question about where best to save the server object and the catalog object. Should it be saved in the resultswindow or the filterpanel?

[prjemian]

IMO, this is evidence of something to be improved in our overall strategy (that's why I marked this issue as a bug). Our current work has been focused on browsing a tiled catalog of type CatalogOfBlueskyRuns. Our code will break if we load a different catalog type, such as a file system directory. We need a redesign. In programming terms, that is a refactor.

My concept is that the UI panels loaded here: https://github.com/BCDA-APS/tiled-viz2023/blob/99dd2c8ff18a441288ad4a37771d79a7a966d957/gemviz23/demo/mainwindow.py#L27-L33 are specific to the type of catalog opened from the server. The catalog drop-down should be moved out of the filterpanel. Like this sketch

[prjemian]

Once a catalog is selected, its type can be discovered and the appropriate MVC class is called to handle that type of catalog. We only have one choice now (CatalogOfBlueskyRuns), but that list of types will grow.

The MVC class:

• is responsible for managing the catalog, the filtering, search results table, and any visualizations
• will choose the UI panels (each should be a QWidget) to set into each of the QGroupBox containers in the mainwindow

[prjemian]

We'd start with a BlueskyRunsCatalogMVC.

[prjemian]

For a tiled catalog of a file directory, see the comments here:

• https://github.com/bluesky/tiled/issues/535

[prjemian]

Specifically:

What should a client do when it wants to know how to browse a given structure for data?

First, it should look at the structure_family. Every item in tiled always has exactly one of these, and it's from a fixed (not configurable list). This is enough information to know how to slice into it, know some of the formats it supports, and how to get from bytes to numbers.

Second, it ~should~ may look for specs. This provides additional context that may be helpful but is never essential for the basic activity of accessing the data. The specs are given as a list, which may be empty. The specs are meant to be sorted from broadest to most precise, so you should keep going until you find one that you don't recognize. This provides additional context that may be useful in understanding the meaning of data or metadata. For example, CatalogOfBlueskyRuns can be used to set the expectation that the contents have certain metadata like start.time and start.scan_id.

A generic directory or HDF5 group or any "container" does not have any specific attributes. Therefore I think it is well described by just the structure_family. I would layer on specs only if the directory or Group in question should be always expected to have specific metadata, or contain files/datasets with specific names.

[prjemian]

With this issue, we should change gemviz23 to gemviz throughout.

[prjemian]

@rodolakis asks:

Why can't we use the (bluesky) BestEffortCallback to choose data from a run and plot it?

[prjemian]

Issue #113 should be completed before work on this issue is started.

[prjemian]

• 113

[prjemian]

Current catalog view (filtering, table, and viz not yet re-applied)

App now correctly handles catalogs it is not prepared to browse, such as this directory of files:

[prjemian]

This code decides what to show: https://github.com/BCDA-APS/gemviz/blob/b7e52eba1110d5ef2048353e10ce188872c4c2c8/gemviz/mainwindow.py#L137-L144

[prjemian]

Time to rename filter, results, viz to indicate they are part of one particular MVC representation.