bluesky / bluesky-mpl

ARCHIVED. See instead http://blueskyproject.io/bluesky-widgets
Other
2 stars 3 forks source link

Proposed API for Best-Effort Callback successor #15

Open danielballan opened 4 years ago

danielballan commented 4 years ago

The name

"Best-Effort Callback" is not very descriptive from a user point of view. Since this is, in practice, about creating and managing matplotlib figures based on documents, let's just call it Viewer.

Structure

The Viewer has multiple "outer tabs". Each outer tab can be used to (over-)plot one or more runs. The plots reside in one or more "inner tabs", contained by an outer tab.

Proposed API

Viewer is a callable that can be used directly as a callback for consume streaming live data

RE.subscribe(viewer)

or saved data.

for name, doc in run.canonical(fill='yes'):
    viewer(name, doc)

A method that understands the API of run is available as a terse way to display saved data.

viewer.add_run(run)

By default all of the above target the currently-active outer tab. It is also possible to address a specific outer tab, to explicitly control what is plotted over what.

viewer.add_tab(name)  # must be unique or ValueError is raised

A tab can be accessed by name

viewer.tab[name].add_run(run)

or by position.

viewer.tab[0].add_run(run)

A tab may be renamed.

viewer.tab[name].rename(new_name)  # must be unique
tacaswell commented 4 years ago

This seems good to me.

An emplishment I would add would be for the outer tabs to keep a list of the uids it has plotted and an API for removing a run you no longer want to see. This would also give a nice path to implement a FIFO plotting mode.

prjemian commented 4 years ago

Was thinking about this more. Tom's suggestion to keep a list of uids fits in with those thoughts. The number of tabs could grow to be more than done window managers can display well. A scrolling tree view of tabs, with collapsible subtree of uids would scale.

On Fri, Dec 6, 2019, 8:13 AM Thomas A Caswell notifications@github.com wrote:

This seems good to me.

An emplishment I would add would be for the outer tabs to keep a list of the uids it has plotted and an API for removing a run you no longer want to see. This would also give a nice path to implement a FIFO plotting mode.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/bluesky/bluesky-mpl/issues/15?email_source=notifications&email_token=AARMUMARSUV4EOWLRCJCCEDQXJM2DA5CNFSM4JWYE6HKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGEGKCQ#issuecomment-562586890, or unsubscribe https://github.com/notifications/unsubscribe-auth/AARMUMBBMNRSVNLAVPL2JILQXJM2DANCNFSM4JWYE6HA .

danielballan commented 4 years ago

That's a good idea. I'm also interested to see how users react to "overplot by default". That seems to be what users generally want --- some UI to add a new tab when needed, otherwise overplot in the currently-active tab.

danielballan commented 4 years ago

@prjemian If you're up for taking this for an early spin, try out

git clone git@github.com:bluesky/bluesky-mpl
pip install -e .
ipython -i example_with_databroker.py

There many obvious omissions from the UI (closable tabs, etc.) but I'm interested in early reactions to the Python API.

danielballan commented 4 years ago

An emplishment I would add would be for the outer tabs to keep a list of the uids it has plotted and an API for removing a run you no longer want to see.

Yes, and further, the low-level document-to-artist classes like our Line, Grid, and so on should get a close() method that removes their artists. Thus, tab.remove(uid) can cascade down into those classes which can clean themselves up.

danielballan commented 4 years ago

I just read through the documentation of napari, and its API has much in common with the one proposed here. That kind of accidental "convergent evolution" is encouraging.

jklynch commented 4 years ago

Wow, what a bitchy comment I left. Here's version 2.

I would like to propose the name "RunViewer". I think it is helpful to say what will be viewed and while it's not perfect I think it is descriptive.

danielballan commented 4 years ago

Thanks, @jklynch. I agree that RunViewer is better and more clearly communicates the scope.

I could imagine the base RunViewer eventually growing the ability to dispatch to things that aren't matplotlib-based. For example, maybe we want to use napari instead of imshow to view images, if it's available. This kind of thing might be a user-configurable extension. All that to say: avoiding "Figure" or "Matplotlib" in the name of this base object might turn out to be a forward-looking decision.