Hi Tom, I'm the author of Gaston.jl. This looks interesting, and I'll take a closer look. I'm wondering, how do you plan to handle the different capabilities of each backend? Say, for example, that the user specifies a plot that Gaston can't handle -- maybe the marker type is not supported by Gnuplot, or something like that.
-- mb On Thu, Sep 10, 2015 at 4:26 PM, Tom Breloff <t...@breloff.com> wrote: > This may be a slightly premature announcement, but I wanted to put it out > there so that people that have strong opinions have a chance to give their > thoughts. Here's the link: > > https://github.com/tbreloff/Plots.jl > > Plots.jl is intended to be an API/interface that sits above other plotting > packages (backends) and gives the user simple, consistent, and flexible > plotting commands. It's a problem when someone is used to a package which > is great for interactive plots, but then has to re-learn and re-code new > plots in another package when producing publication-quality plots (or vice > versa). The same goes for switching between desktop GUIs and javascript > technologies... sometimes one package is better than another for a specific > task, and it's a shame to be forced to choose. > > I've implemented a bunch of functionality for both Gadfly.jl and Qwt.jl > backends. See the examples to get a sense of how they differ. I think > Vega.jl and UnicodePlots.jl might be next on my priority list, but please > let me know if I should prioritize differently. Note: This is still a work > in progress, and I will probably change parts of the API, and not every > plot type is implemented yet. > > Please let me know comments, wish lists, etc. Issues are great for > actionable items, comments can go here. This effort was partially inspired > by various discussions here and on github, which prompted the forming of > https://github.com/JuliaPlot, and an effort to improve the plotting > landscape with tutorials and documentation. If you're interested: > https://github.com/JuliaPlot/juliaplot_docs/issues > > Tom >
