Open danielballan opened 3 years ago
@danielballan A few questions about FigureSpec
and friends:
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.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?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?Follow-up from the call:
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.Canvas
somewhere? This has been mentioned on previous calls but not explored in the same depth as Intents
.Figure
into different types address this in part or in whole?
Notes and follow-up thoughts from today's best-effort-viz call with @ronpandolfi, @HarinarayanKrishnan, @ihumphrey, @cryos, and @AbbyGi
FigureSpec
). The "canvas" objects that interpret them could likewise grow to understand these and create what amounts to a PyQtGraph view forFigureSpec
. This would allow us to experiment with integrating the two without fully committing.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 tofigure.axes[0].lines[0]
that keeps things organized and separatesfigure.title
vsfigure.axes[0].title
vsfigure.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.