Arrow elements should support arrows in any direction

[jlstevens]

Currently Arrow elements can only point along the cardinal directions.

[jlstevens]

This won't be implemented in time 1.1 but it is worth mentioning this is already possible by defining a finalize_hook:

def add_arrow(plot, element):
axis = plot.handles['axis']
   axis.annotate("", xy=(1.2, 1.2), xycoords='data',
      xytext=(1.8, 1.8), textcoords='data',
      arrowprops=dict(arrowstyle="->", color='k',
      connectionstyle="arc3"))

This code gets the axis from the plot.handles and then adds the custom Arrow annotation. You can then apply this function as follows:

%%opts Curve [finalize_hooks=[add_arrow]]
Curve(zip([0,1,2], [1,2,3]))

Or of course via the call method:

Curve(zip([0,1,2], [1,2,3]))(style={'finalize_hooks': [add_arrow]})

[jlstevens]

It should be noted that:

1. We need to document finalize_hooks.
2. The matplotlib figure is now plot.state

[philippjfr]

Looking at the current Arrow implementation it seems to be pretty closely tied to the matplotlib backend. While the bokeh backend does not currently support arrow annotations they will be adding it in the near future. I propose that in addition to allowing arbitrary directions on arrows we should remove parameters like the arrowstyle and expose style options like head_length and head_width instead.

[jlstevens]

I agree that Arrow is based on how matplotlib supports arrow annotations but I don't agree with deprecating arrowstyle. This is a general concept (e.g Inkscape supports different arrow heads for both single-headed and double-headed arrows) and the name arrowstyle seems perfectly appropriate.

Adding head_length and head_width sounds fine to me if we think it will be supported across backends. I am also in favor of improving the API to make it generalize better across backends but to me, arrowstyle isn't one of the things that really needs changing.

Perhaps you are suggesting making arrowstyle into a style option instead? In which case, I agree because then we can support different arrowstyles according to whatever the backend supports.

[philippjfr]

Yes at the very least it should be a style option. If we are keeping it as a style or plot option I'd at least want there to be a rough equivalence between the accepted arrowstyles across backends. It definitely should not be on the Element itself however.

[jlstevens]

It definitely should not be on the Element itself however

I'm not entirely convinced. As an annotation, what the thing looks like is part of the definition (unlike our other elements). Repeating an arrowstyle over and over again for a particular arrow seems like it would be a giant pain to me.

[philippjfr]

So then you're arguing that all backends need to support all the arrowstyles that are defined on the Element? I don't think that's practical.

[jlstevens]

No. I am arguing they should support whatever arrowstyles they can. If they have to fall back to a single arrow style (or a similar one that might not quite be identical) then so be it.

Edit: I would say the backend should just warn that a particular arrow style that has been requested is not supported. All backends will likely support the same simple arrow heads.

[philippjfr]

Okay, not a huge fan because we're letting matplotlib determine what's a valid arrowstyle but I'm happy to leave it. Just have to decide what to do about direction now, the only general solution is letting you define the start and end point of your arrow. So perhaps add a parameter that defines the starting position, which is None by default and overrides the direction if set.

[jlstevens]

Sounds reasonable to me.

Okay, not a huge fan because we're letting matplotlib determine what's a valid arrowstyle but I'm happy to leave it.

This is true for many things already. Matplotlib is what people will be familiar with and we already have utilities for Bokeh that convert from existing matplotlib concepts. We want to keep the API as consistent across backend and matplotlib is our basic, best supported (and first!) backend. As such it acts a bit like a reference backend.

Obviously, we shouldn't copy the bad bits of the matplotlib API but if a matplotlib parameter (and its values) are sensible, I don't see the problem with mirroring a convention that will be familiar to many people (with documentation online).

I also have no issue with extending the possible values beyond what matplotlib supports (say Bokeh supported more arrow styles than matplotlib did). This would be similar to the situation described in #245.

[jbednar]

I agree with that overall assessment, Jean-Luc.

[jlstevens]

I've used this issue to create the first notebook in the holoviews-contrib repository (see ioam/holoviews-contrib#2). This notebook encourages PRs to fix this issue properly (as well as to add the missing Bokeh support).

Edit: Just to say I see no reason why bokeh support wouldn't be easy to add.

[philippjfr]

Bokeh support is mostly waiting on standardizing on a general API that supports arrows in any direction.

[badiku]

http://bokeh.pydata.org/en/latest/docs/user_guide/annotations.html
bokeh has arrows in any direction

from bokeh.plotting import figure
p = figure(plot_width=600, plot_height=600)
p.add_layout(Arrow(end=VeeHead(size=35), line_color="red",
                   x_start=0.5, y_start=0.7, x_end=0, y_end=0))