On Friday, 11 September 2015 03:48:44 UTC+2, Tom Breloff wrote: > > 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. >
Overwhelmingly, I do relatively simple scatter plots and line plots; with the occasional "heat map" plot. The priority for me is to be able to fiddle with the details of the plot: change the font, define a new colour, remove the tick marks, have two y-axes, change the aspect ratio, insert formulas in LaTeX, etc. So the plot itself is usually very simple, but I need to be able to make any change requested by my supervisor, or the journal editor, or the referee. Cheers, Daniel. > > > On Thursday, September 10, 2015, Miguel Bazdresch <[email protected] > <javascript:>> 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]> 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 >>> >> >>
