I saw it already. I asked about the future intention. What can be reused between Grapher and Kiviat are the axis logic. This is what we had in EyeSee and it worked well.

This is what we have actually. RTAxisConfiguration and RTAxisRenderer are instead used by Grapher and Kiviat.


 [...]
- I do not quite understand how to distinguish the difference between DataSet and StackedDataSet.

Yeah, not easy to grasp. Consider an histogram and a scatter plot.
You will define an histogram as a list of values, e.g,. 4, 5, 6, 7

What you call a histogram is actually just a bar chart :). The histogram is a way to represent the distribution of data, not individual data points. I would rename the vocabulary to use the term "bar (chart)"  instead of histogram.

Well spotted!
I replaced referenced of “histogram” by “bar chart"


You will define a scatterplot as a list of points, e.g., 2 @ 3, 5 @ 6, …

An histogram is obtained from a list of objects, and a function Y to obtain the values.
A scatter plot is obtained from a list of objects, and _two_ functions X and Y to obtain the points.

When you do not need to specify an X, e.g., an histogram, then you need a RTStackedDataSet.
When you need to specify an X, e.g., a scatter plot, then you need a RTDataSet. 

Is it clear? Maybe the vocabulary we use is not obvious. 

Yes, I understood this before but the names do not say that. Some names that come to mind are:
- RTUnidimensionalData/RTBidimensionalData or

These names are a bit long

- RTXData/RTXYData.

Yes, could be. 

But, I would want to raise another point: 

The decomposition is now based on the kind of data and it is the data that specifies if it wants to be represented as bars of lines. This can work if we consider bars and lines. However, if you want to implement a real histogram it won't work well because it would require you provide a list of items and a function to group them into chunks and you would show those chunks. So, you would build a RTHistogramDataSet. What's more, this histogram would work only with bar shapes.

So, perhaps a better decomposition is via the chart type. At least, this is what we learnt from EyeSee and Graph-ET. Of course, we could also build another RTHistogramBuilder altogether, like for Kiviat, but we might be missing reusability and uniformity. I think it would be useful to think about the implications at this point.

This is something that I have thought a lot. I agree with you in principle. However, having the Grapher modular with the maximum reuse is not the big challenge I see right now. Big things are missing in Grapher now, that may have an impact on the whole design. For example, consider the script:

-=-=-=-=-=-=-=-=-=-=-=-=
b := RTGrapher new.
b extent: 200 @ 200.

ds := RTStackedDataSet new.
ds points: #(-0.5 1).
ds barShape width: 30.
b add: ds.

b axisX noLabel; noTick.
b
-=-=-=-=-=-=-=-=-=-=-=-=

The produced graph is the following:



The X-axis is not on the 0 value. And this is a big problem. You can always fiddle with the number of ticks, the minimum and maximum values, but this has to be done manually. Excel does it automatically. Unfortunately, the algorithm behind is not simple (this is an optimization problem, for which there are even some research paper).

Another problem I see, is to have logarithmic scale. Actually, I suspect there is no major difficulty, excepting finding the time to do it.

Having smart ticks and logarithmic scales are the priority for now. Once we have this, we may rethink about the whole architecture. 

Cheers,
Alexandre