I know it sounds incredibly simple, but I just can’t figure it out.
In this screenshot, the blue is the html div container background. The thin red outline is the bgcolor set as hv.Image(...).opts(bgcolor="red"). But how do I edit the white part for this one image?
I know about bokeh theming, but that sets the theme globally, and I don’t want to modify all my plots. I have two groups of plots, each group in a different area (content/sidebar) with different styling including their different background, so only some of the plots need to be restyled.
Bokeh has an apply_theme() function for every related area, is that reachable somehow in an interactive (not statically exported) app?
@jbednar : You accidently edited my original post instead of replying, so now my question is not visible anymore. I’ve looked and did not see a restore option for me as a normal user, can you restore it?
I have to tell you, considering how unbelievably fine-grained the holoviz tools are and thus how they offer almost limitless possibilities, it’s a shame how much of these are missing from the documentation and practically the only way to get this information is in person here.
Like I found now that there is a mention of hooks on the Holoviews Customizing Plots page, but other than having a basic example it
does not provide any information on the editable options or links where to find them;
does not contain any reference to the state.update() function you used above;
the “Plot hooks” is the least descriptive title for a block about detailed customization (which is what a user will look for), so I’m pretty sure I’ve automatically already skipped this block every time I’ve read this page.
I’m not saying this as a critique. I think I start to understand how the development of these modules happen and that the price for the truly amazing constant improvements considering the limited resources is that the documentation lags behind. I just wanted to give feedback that I’m pretty sure the main cause for this toolset not being extremely popular (as it should be based on its capabilities) is that for somebody new to this ecosystem it is extremely difficult and time-consuming to figure out how anything works compared to many other tools. And I would offer my help (planning on actually as soon as I feel comfortable enough with everything), but it seems to be a bigger task than what a few volunteers could solve and maybe it deserves a dedicated project and even a full-time team member to bring the documentation to the same high level as the functionality is at. I’ve been developing for a while now (mostly web applications, interactive systems) and I had to learn a few times again and again that the products created by me can and will be way more confusing even for smart people than I would think. It’s easy to think as a developer that if something is evident for me (who knows the whole code), it will be at least somewhat logical to everybody else too, but for people who have just seen bits and pieces from the outside and are not familiar with the system’s inner workings, there’s no way to see the logic.
Sorry if I’m being obnoxious, I assume you too know very well about the issue. This was just a too good example to let it side.
Sorry for editing your post instead of replying; must have been in a hurry! If anyone in the world knows a tech writer taking a year off from paid work and wanting to do some good for an OSS project, or someone willing to fund such a writer for a year, we could make so much use of them! In any case the main issue is that because these tools do so much, whenever we try explaining things better in the docs, the docs get longer and it gets harder to find anything and less likely that people will find things on their own. So things get worse, not better! We really could use someone from “outside” who takes the time to figure out what the experience of a new user is and should be, and can do something about that.
Yeah, I can totally imagine why this would be a challenge.
Have you thought about trying to grab this documentation issue from the other way around and create enrich the API reference like pandas did? Their API documentation is by modules and by functions, but it contains a reproducible example for practically every possible parameters, so whenever I run into a new function or a previously unknown parameter, I don’t have to guess what they mean by the description, I can immediately see it in action. This itself, of course, would not help much in understanding the underlying logic behind the tools and to answer “which function do I use to…?” questions, but at least if I managed to find a function that supposedly does what I want, I won’t be stuck with just a docstring in the function definition itself that assumes a deeper understanding of the vocabulary than what I possess. And also, their “See also” blocks at least give me an opportunity to go through possibly relevant other functions until I find what I’m looking for.
This, of course, would also be an enormous undertaking, especially with everything changing as rapidly as they do, but maybe it would disable the “we don’t know what newbies don’t know” barrier and resolve the “more documentation makes it harder to find anything” issue as everything is explained right where its definition is. And then the current “let us show you how stuff works in practice” type of notebooks would only sit on top of this, not bearing the burden of having to explain every parameter. Also, this probably would be easier to start with and to include volunteers in, as an initial documentation most probably could be generated from the already existing docstrings and while that itself would not provide any additional benefits compared to the docstrings themselves, it would allow us to contribute with smaller examples in smaller areas we are pretty sure already understand instead of the current barrier where I would have to have a pretty wide and deep understanding to create a full-blown example notebook and to be sure in not just that it works, but that it is actually the best way to implement that solution. Listing all the opts available for hv.Points with an example for each would be a much more well-defined task with a lower chance to accidentally spread misinformation.
Not trying to be smarter than you guys, just thought to share my viewpoint as a possible inspiration, as somebody who’s really grateful for these tools but still somewhat on the other side of this barrier…
Yes, I do think that we have some low-hanging fruit we can pick here. Right now, for technical and historical reasons, our reference gallery notebooks for HoloViews, GeoViews, Panel, and hvPlot are fully standalone and in no way integrated with the reference material that’s tied to the source code, i.e. the docstrings and function signatures. Plus there’s no clear documentation of the underlying plotting-library options, which aren’t actually in the source code but which can be introspected from Bokeh’s spec and probably from Matplotlib and Plotly somehow too. Until recently, we haven’t had any mechanisms to be able to refer to the API docs, and so the Reference Gallery and the API Docs lived in separate universes, with a huge gap between them. Now @philippjfr has brought in MyST-NB, my hope is that there is a way we could pull in the reference material naturally into the notebook, explicitly linking to it and expanding it inline where needed (e.g. listing the options in a way that could be expanded when the user wants more info). That way there would be a single place where a user could get all the info about an Element or Panel Widget or Pane. And then we could encourage users to beef up these examples to cover the various currently undocumented options and configurations, because they would now have an obvious home. Finishing such a project would take ages, but it seems to me that starting it would immediately give major benefits, by automatically incorporating all the docstring and parameter info we already have right into the gallery page where we can see what that object does. And then actual working docs of the various undocumented bits could gradually fill in over a long time. Not entirely sure if @jstevens or @philippjfr would agree with me here, but I personally would love to see work in this direction!
@philippjfr
is there a way to setting opts for a parametrised object when it is included in the panel realm?
For instance the function “explorer.plot” in the gallery example Stocks hvplot is called inside pn.Row() and returns an hv.Curve plot eventually. It would be useful to be able change opts within that pn.Row() definition, somehow, rather than in the upstream class, so that it can be reused in another context.
