Hi Miguel... Looking forward to your comments. The short answer is that it depends on the situation. For functionality that just isn't possible for a backend, I'll probably just throw an error (ideally with a message describing other backends that can do what you're looking for). For some cases, I might automatically replace the call with something similar. For an example, I couldn't figure out how to make a "sticks" plot in Gadfly, so I made a bar plot instead. I hope that the package authors can help me with this process though... Sometimes there's undocumented functionality that does what I need, and it would be a big help to have package authors contribute.
I also want to hear from people on visualizations that aren't possible with this API, as this all falls apart if you only cover some of your needs through Plots.jl. Look at the TODO at the bottom of the readme for an idea of my roadmap, and let me know if you want me to add to or prioritize something. On Thursday, September 10, 2015, Miguel Bazdresch <[email protected]> wrote: > 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 <[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> 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 >> > >
