Adding support for FigureSpec model in intents

[danielballan]

Notes and follow-up thoughts from today's best-effort-viz call with @ronpandolfi, @HarinarayanKrishnan, @ihumphrey, @cryos, and @AbbyGi

• Intents could grow a new keyword argument for injecting bluesky-widget's plot models (e.g. FigureSpec). The "canvas" objects that interpret them could likewise grow to understand these and create what amounts to a PyQtGraph view for FigureSpec. This would allow us to experiment with integrating the two without fully committing.
• I see two advantages of FigureSpec (and friends) over intents as a base layer. One I thought of on the call: intents accept a single namespace of kwargs, whereas there is a nesting to figure.axes[0].lines[0] that keeps things organized and separates figure.title vs figure.axes[0].title vs figure.axes[1].title for example. But, as @ronpandolfi observed, this could definitely be recreated with nested dicts in the signature without any fundamental difference. The second is, by encoding the plot description in observable objects with properties that emit signals when they are set, conceptually similar to Qt signals/slots or Jupyter traitlets, we make it possible to define them in one part of the code and then change/update/augment them in another part of the code in a way that the view code can immediately respond to just by subscribing to the relevant signals as soon as it receives the model.

---

Edited potentially confusing typos for clarity.

[ronpandolfi]

@danielballan A few questions about FigureSpec and friends:

1. Can the variety of Spec's be extensible? If I want to describe a new type of visualization that can't well be described in terms of the available primitives, how would I supply my own? With Intent and Canvas, we currently have plugins for both providing an option for extensibility; I've applied this in our hyperspectral imaging visualizations.
2. Then, if I write a PyQtGraph interpreter for Spec's, I'd also want to provide a point of extensibility to complement the extensibility of Spec's. I think there is an advantage here in separating out the Canvas's as individual components independent of the 'Manager'. Could the Canvas concept be fit into your design?
3. AxesSpec, PlotSpec, and ImageSpec have appropriate analogs in PyQtGraph. Even though FigureSpec could be compared to GraphicsView, rendering directly into GraphicsView rather than a more specialized widget would mean you'd give up some useful elements. For example, PyQtGraph's ImageView gives you a free HistogramLUTWidget that couples with its ImageItem, as so on. Would it be safe to build into FigureSpec an option to specify a 'Canvas' type?

[danielballan]

Follow-up from the call:

1. The refactor in Refactor Model <---> View-model contract bluesky/bluesky-widgets#97 makes it possible to add custom models to a Axes, beyond the Line and Image models currently defined. It's up to the views to decide what to do with an unsupported or unrecognized model: make a best effort at representing it, silently ignore it, issue a warning, or raise an exception.
2. Is there documentation on Canvas somewhere? This has been mentioned on previous calls but not explored in the same depth as Intents.
3. Does splitting out Figure into different types address this in part or in whole?

[ronpandolfi]

1. Agreed. Can we add an entrypoints registry to support their serialization?
2. Not yet, I'll get something for you to look at
3. Yes it does.