Legendmarkersize discussion

[isentropic]

Do you perhaps think that markersize scaling logic should one day move to Pipeline? If one day we decide that this computation for legendmarkersize and stuff is not preferred or needs some minor tweaks, only Pipeline code would need to be altered. I know that this is again back to square one, but now that we defined some ground rules and have solid arguments about preferring one behavior over another maybe it should be embedded in the pipeline.

I'm hinting into having plot arguments like legendmarkersize, legendmarkerstroke, legendlinewidth

Perhaps this would make legends logic more decoupled and not repetitive in the backends?

To be fair we had around 50 posts in total only from #2616 and #2620 discussing the behavior of legend stuff.

There are of course,
#2650
#2643
Thanks to @daschw who did most of the work to make everything consistent and nice.

I know that this would lead to yet another rearrangement of the logic. But I guess it does not to be done in one PR, we can for now create unused by GR and PyPlot legendmarkersize, legendmarkerstroke, legendlinewidth and try to make it work with Plotly and perhaps unify everything with GR and PyPlot at the end.

Maybe this is somewhat relevant to #2423
After all, if we want to have better legends, we should decouple backends from scaling logic and all.

This is of course just a suggestion, I'm not pushing anything. It would not bring any benefit now, only possibly make our lives and other future maintainers' lives easier.

[isentropic]

What do @mkborregaard @BeastyBlacksmith @SimonDanisch @jamblejoe think?

[BeastyBlacksmith]

I think, that is not unreasonable. Adding new keywords is a bit tedious though. (The reason I haven't finished #2363 yet... )

[jamblejoe]

I'm hinting into having plot arguments like legendmarkersize, legendmarkerstroke, legendlinewidth

I think we settled to a good default behaviour in #2616. Nevertheless, having more flexibility with legendmarkersize, etc. would only enable more people to use Plots.jl for plotting beyond first, quick plots.

After all, if we want to have better legends, we should decouple backends from scaling logic and all.

I highly agree with that!

@BeastyBlacksmith Plots.jl is still quite new for me. What is tedious about adding new keywords? In my understanding, they do not have to be implemented to every backend at once.

[BeastyBlacksmith]

A point I don't like about the current default in GR and PyPlot is, that it is currently not possible to differentiate between series with different markersizes in a monochrome Plot, e.g.:

scatter([rand(3), rand(3)], markersize = [10 5], label=["Very important" "Not so important"], color = :blue)

[isentropic]

Yes, I also suggest a kw for this. Something like legendmarkerscaling
Plotly has a similar thing https://plotly.com/python-api-reference/generated/plotly.graph_objects.layout.html#plotly.graph_objects.layout.Legend.itemsizing

[isentropic]

Maybe this link is better -- https://plotly.com/python/reference/layout/#layout-legend-itemsizing

All in all, I think we can afford one extra kw for this case.

And while at this, I think we can introduce one more kw for horizontal legends similar to plotly style: https://plotly.com/python/reference/layout/#layout-legend-orientation

Overall plotly docs are really good and can give us some ideas, their api is not so low level as matplotlib, yet very powerful.

[dev10110]

Hi, I too would like to be able to control the legend line width - usually i just export plots as vectors and edit it in Illustrator, but today I needed to make an animation with over a thousand frames, so I didnt want to go and edit each one. It would be nice to have control over this.