Randy: do you have an issue or design description of what you're looking to accomplish with your "interactivity interface"? There could be more overlap than you think...
On Mon, Sep 14, 2015 at 11:02 AM, Randy Zwitch <[email protected]> wrote: > 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]> >> 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 >>>>>>> >>>>>> >>>>>> >>
