Adding option propagation to plots

[philippjfr]

The option system has served us very well so far but there has always been one major annoyance that has caught new users (and us) out very frequently. That is the fact that options that control the axes and figure options are not propagated upwards when an Element is embedded in a container. A simple example is the aspect and figure size of a plot, which apply fine when applied to a single Element but as soon as they are overlaid with something are ignored and need to be set explicitly as a plot option on the Overlay.

This is actually a problem that we have already solved for some cases, specifically I have added a _traverse_options method to DimensionedPlot which will iterate over the datastructure and gather all the requested plot options. This is currently used for things like projections, which need to be determined before instantiating the plotting classes themselves.

The major obstacle in making this happen is therefore to determine what the behavior should be. There are several decisions that need to be made:

1. Which container objects should use propagated options, in the case of Overlay it is clear that certain options such as the fig_size and aspect should be propagated upward, but for a Layout it doesn't make sense to use the fig_size set on a specific Element.
2. The decision of which containers should use propagated options is tightly coupled to which options should be propagated, I think propagating all figure and axis based options from Elements to Overlays is a sensible choice.
3. What is the precedence if multiple Elements specify clashing options? I think the most sensible policy is for the first layer from the bottom that specifies a specific option to get applied unless the container specifically overrides that option, e.g. in this case the Image would override the Points aspect but the Points xticks would be applied:

%%opts Image [aspect=2] Points [aspect=1 xticks=[0]]
hv.Image(np.random.rand(10,10)) * hv.Points([(0,0)])

and in this case the Overlay aspect would override both

%%opts Image [aspect=2] Points [aspect=1] Overlay [aspect=1.5]
hv.Image(np.random.rand(10,10)) * hv.Points([(0,0)])

I think this would remedy one of the major sources of confusion when working with HoloViews and wouldn't be too hard to implement given that the underlying infrastructure is already in place. It is a major change in behavior though and may call for a version 2.0 release.

[philippjfr]

The above PR has now finally applied the behavior defined above, we still need to make sure this is correctly documented in the Options tutorial.

[philippjfr]

Also update existing tutorials to take advantage of this new behavior.

[philippjfr]

This is now implemented and documented, closing.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.