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
>>>>>
>>>>
>>>>

Reply via email to