Setting additional options when layout is generated

hvPlot
1

I found that when generating a violin plot, some options can only be specified through .opts() rather than in the violin call, e.g.:

cost_plot = df.hvplot.violin(
    y="solution_cost",
    by="solver",
    color="solver",
    aspect=2.5,
    grid=True,
    legend=True,
    groupby=["heuristic", "min_best_path", "moves_per_iter", "add_noise", "round", "weight"],
    widget_location="bottom",
)
cost_plot.opts(
    split="solver",
    inner=None,
    bandwidth=.1,
    violin_width=1.5,
)

But if I try to customize the widget layout or widget classes, then I find that the function returns a Panel layout object instead of the DynamicMap. It is not obvious how to correct set the options in that case.

Is there a recommended way to do this?

2

That’s a good question. Having to return a Panel object is definitely not ideal, because it mimics the usual HoloViews object without behaving quite the same way, so that’s something we should try to avoid.

Anyway, your code isn’t reproducible, so I can’t try it myself, but I think you can do cost_plot.object.opts(...) instead, to get at the underlying object.

3

That does work, but if I specific widget_layout, I have to do something like cost_plot[i].object.opts() and that i depends on the particular layout choice.

It would be nice if there were a less hacky way to specify these extra options.

1 Like
4

Perhaps file an issue on hvPlot? I imagine we either

  1. get rid of these hvplot → panel layouts
  2. warn about them and offer a way to use opts as kwargs
5

I vote for option 1, which I think requires providing a way for hvplot to capture the layout info specified by the user and store those declaratively on the holoviews object so that later, when the object is rendered by panel, Panel follows those embedded hints. I think we should be shooting for hvplot to have a single, unified return type of object in all cases, so that users don’t have to figure out the corner cases like this.

6

Can bump this again:

7

This is a particularly painful issue for me, I have multiple posts about is as well (like this example).

I have seen older versions of the doc suggest that we can do

ds_plot = ds.TT.hvplot.quadmesh( ... )
ds_plot_widgets = ds_plot.widgets()

...

template.sidebar.append(app.ds_plot_widgets)

The point is the killer app that still eludes me is to allow for the user to dynamically define a dataset which then setps up a map with multiple holoviews.streams that all produce different DynamicMap objects and occupies as much of the template.main as possible and allows for widgets to update properties such as alpha, cmap, tiles etc.

8

I don’t think dynamic maps can return different types of holoviews objects. However for your use case you can just replace the entire main panel with any kind of panel object.
The only loss would be efficiency as there is some kind of magical diffs that are built into dynamic maps. You might get a bit of a flicker but that should not matter for your usecase
I did read your linked issue and the solution is infact what I use as dynamic maps with overlays don’t do well for updates. Might be that magical diff :innocent: