We should allow plotting various plots in loglog scale, which is very useful for many applications.

The API can either by Axes#loglog or can be specified as an option to a method.

The present GR backend is basically just a simple Ruby wrapper. Integrating the rubyplot interface with the GR framework should open up massive potential for expansion of rubyplot by leveraging GR's already amazing plotting capabilities.

This issue will focus on only integrating the parts of GR that can currently be used through the current rubyplot interface.

@pgtgrly and @Arafatk post your thoughts and other links about the Transformation API in this thread.

From this list: #4

Integrate graph generation and verification into rspec.

The themes file contains various color names that are current stored simply as RGB values. These should be changed to symbols denoting names of the colors and the relevant entries should be made in colors.rb.

From this list : #4

A weird problem happens when calling Figure#write twice on the same graph. For the first time, all the text on the Figure is antialiased however the second time, the text appears fuzzy and is probably not so.

Here is the image of the first time:

And this is the second time:

You can reproduce this issue by running any test in the rspec and comparing both images.

Traceback (most recent call last):
./a.rb:11:in `<main>': uninitialized constant Rubyplot (NameError)
Did you mean?  RUBY_PLATFORM

on fedora linux

Using XND as the storage and algebra backend.

From this list: #4

@v0dro
Plots are not coming appropriately as they were coming earlier. Many plots are coming in a single plot. Even my branch is with current master.

Integrate rubocop into tests and make sure all code is rubocop compliant.

Hi.
I think grruby.so location is ambiguous.

By default, gems/rubyplot -0.1 .pre.a1/lib/grruby/grruby.so is generated.

But this file is not read.
rubyplot reads gems/rubyplot -0.1 .pre.a1/lib/grruby.so

We should have our own rubyplot GUI that will accept plots generated by GR or Magick and show them in a GUI using Qt or GTK that will allow the user to interact with them freely.

At the most basic level it should allow the user to save the plot to a file. More advanced behaviour should allow basic interaction with the plot such as moving it around etc.

Support multiple plots on the single Axes. For example a scatter and line plot on the same Axes.

Currently the legend is drawn at a default location within the plot.

This should be changed so that the location of the legend changes as per the plot and is drawn at a place where the no data (or less data) exists on the plot.

Integrate #7 into Travis CI.

New plots are to be implemented on a priority basis. Priority to be determined by:

• Frequency of usage.
• Need and requests by users.
• Dependence on other kinds of plots.

Please post your comments in this thread and we can update the new plots to be implemented.

List:

• Histogram.
  • GR
  • Magick
• Error bars.
  • GR
  • Magick
• Candle sticks.
  • GR
  • Magick
• Violinplot - https://seaborn.pydata.org/examples/grouped_boxplot.html
  • GR
  • Magick
• Grouped boxplot. - https://seaborn.pydata.org/examples/grouped_boxplot.html
  • GR
  • Magick
• Dot plot.
  • GR
  • Magick.

I've added a GR formula to homebrew (libgr): Homebrew/homebrew-core#37046 it's waiting for review. Hope this helps you with the rubyplot work :)

Support should be provided major ticks on Y axis using the YAxis class.

Since rubyplot is backend agnostic, there should be a consistent way of specifying various sizes things in a backend agnostic way that is applicable throughout the library. For example, the size conventions of various markers or the spacing between elements.

The conventions should be followed such that they uniformly apply to both GR and Magick and can be easily understood by end users without much head scratching.

The legends in the Legend box should have a black border for a better-looking legend box and to make the legends with background colour visible.

Currently the GR backend wrapper does not allow changing the opacity of the color fill. Should be added.

Currently the margins (top/bottom and left/right whitespace after which the X & Y axis begin) are defined by two variables @x_axis_margin and @y_axis_margin. As a result we cannot customize 4 sides individually.

Change these to @top_margin, @left_margin, @bottom_marginand@right_margin`. Changes should reflect in the other parts of the code too.

A 'plot' method should be created that will be able to plot all sorts of simple 2D plots like scatter, line etc. using only arguments passed to it.

If there are too many legends, for example in this spec:

      it "adjust legends if there are too many", focus: true do
        @figure = Rubyplot::Figure.new
        axes = @figure.add_subplot 0,0
        axes.title = "My graph."
        [
          [[1, 2, 3, 4, 4, 3], 'Apples oranges Watermelon'],
          [[4, 8, 7, 9, 8, 9], "Oranges"],
          [[2, 3, 1, 5, 6, 8], "Watermelon"],
          [[9, 9, 10, 8, 7, 9], "Peaches"]
        ].each do |d, name|
          axes.bar! do |p|
            p.data d
            p.label = name
          end
        end
        axes.x_ticks = ['2003', '', '2004', '', '2005']
      end

The legend box should properly be configured such that it is displayed appropriately.

Also make sure MultiBar handles legends.

Currently many of the plots require that the user specify various options during the time of creating the plot which help in changing the nature of the plot. However, this limits customizability since the current design does not allow directly accessing elements inside a given plot (for example the boxes in a box plot).

This issue will require some redesign of the internals such that extensive customization of each element within the plot can be permitted by the user. Essentially, the current scheme of process_data -> make new objects -> draw those objects should change to make new empty objects -> process data -> populate empty objects with data -> draw those objects.

In pursuit of better architecture I'm ditching good looks of the plots. Following are the things that strike me as needing change:

• Show non-overlapping X ticks.
• X and Y axis should be of equal length.
• Plot should not exceed X and Y axis.
• Allow rotating the ticks if they might overlap.
• Make axes intersect at the origin and put '0'.
• Draw arrows at the either of each axis.

Adding 'guide' lines can help in navigating the plots better and lead to better visibility. There should be two options - one for major ticks with higher opacity and the other for minor ticks with lower opacity.

Would be great if we can have a debug mode that can display various grid lines, co-ordinates and optional labels on a graph for purposes of debugging.

Currently only MajorTick support exists. Would be beneficial to add minor ticks as well.

The current implementation keeps the X and Y axes fixed. Change this to accommodate data that spans positive and negative values in both X and Y axes.

Currently LegendBox dimensions are almost hard coded and hard to scale.
Change this to first check the space occupied by the contained legends, and then set the dimensions appropriately.

Customize stroke width.

Currently we simply get the center of the Axes and set the start point of the Axes title text from there.

However, this is not a good and scalable approach because it turns out rather ugly especially when the font size is larger. This issue will involve fixing the current situation by coming up with a better heuristic to determine the location of the title text for an Axes object.

Here's the current situation:

As per #1 , we are in the process of separating the backend from the Artist layers. This makes the design of the code very object oriented and nicely encapsulates data within many varied elements for any given plot.

Therefore, there is now no need of having various Geometry objects for holding data.

This refactoring will involve putting things from one or many Geometry objects to the Aritist where it is actually useful with the aim of removing the Geometry object from the code base altogether.

This issue can be broken down into several sub-issues:

• Remove Bar::Geometry object.
• Remove Line::Geometry object.
• Remove Scatter::Geometry object.
• Remove Artist::Geometry object.

Each of the above tasks should be a separate PR/commit.

@Arafatk and @pgtgrly discuss common Artist layer APIs in this thread.

-- EDIT 20 June 2018

As per discussion between @Arafatk and @pgtgrly , we will implement common scripting layer and differing artist classes.

Support bar plots with negative values.