Sure, I was just speaking in generic terms. My goals for Vega are similar to your goals for static plots; in addition, I'm looking to define an interactivity interface...both of which don't necessarily overlap with Tom's goals with Plots.jl, but may in the future.
On Monday, September 14, 2015 at 10:50:29 AM UTC-4, Daniel Carrera wrote: > > Hi Randy, > > To be clear, interactivity (as I understand it) is not something I want or > would use. I need to change the plot settings programmatically so I can > reproduce the exact same plot later if I need to. > > Cheers, > Daniel. > > On 14 September 2015 at 16:02, Randy Zwitch <[email protected] > <javascript:>> wrote: > >> Daniel, this is the approach that I'm taking with Vega.jl; trying to make >> simple things obvious to change and crazy interactivity from Vega >> accessible *somehow* (still working on that!). Not sure how that will fit >> into a common plot interface, but once I'm further along, hopefully I can >> contribute to this effort. >> >> On Monday, September 14, 2015 at 9:03:31 AM UTC-4, Daniel Carrera wrote: >>> >>> 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]> >>>> 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 >>>>>> >>>>> >>>>> >
