From: Bryan Scott <Bryan.S<cott@aa...> - 2002-04-24 02:27:03
Sorry about the late reply.
I am understanding the first three interfaces and think they would be a
great idea. That is :
1) Value - a single value (a simplified version of MeterDataset)
2) Values - a list (or vector) of values (exists now).
3) Values2D - a table (or matrix) of values.
However I do not completely understand the categories concept, so I am
unable to comment on the remanding three interfaces.
I will purchase the JFreeChart docs in the new financial year when we
get a new budget, and maybe that will help.
From: David Gilbert <david.gilbert@ob...> - 2002-04-24 07:18:34
On Wednesday 24 April 2002 03:22, Bryan Scott wrote:
> Sorry about the late reply.
> I am understanding the first three interfaces and think they would be a
> great idea. That is :
> 1) Value - a single value (a simplified version of MeterDataset)
> 2) Values - a list (or vector) of values (exists now).
> 3) Values2D - a table (or matrix) of values.
> However I do not completely understand the categories concept, so I am
> unable to comment on the remanding three interfaces.
A category is just a key for accessing each value, so instead of just a value
you have a key-value pair. Perhaps the term Key would be better than
category. With the Values interface above, you just have a list of raw
values that you can access by index 0, 1, ... , n-1. By extending the
interface (perhaps calling it KeyedValues) you can access the values using
key0, key1, ... , key(n-1). Charts can use the keys/categories to generate
labels for the values (for example, the pie chart using PieDataset).
> I will purchase the JFreeChart docs in the new financial year when we
> get a new budget, and maybe that will help.
I don't expect you to purchase the documentation, you are already one of the
biggest contributors to the JFreeChart project. I'll e-mail you the password
for downloading the latest version.
The same goes for anyone else that has contributed to the project - e-mail me
and I'll send you the details.
Buying the documentation is a good way for people to contribute to the
project when, for whatever reason, they can't contribute anything else. And
I'm happier selling something to people rather than begging them for
donations. But I'd rather have your ideas, code, bugfixes, translations etc
than your money. Sorry if I haven't made that clear previously.
From: David Gilbert <david.gilbert@ob...> - 2002-04-24 16:40:33
I've just committed some revisions to the combined plots. There are now two
key classes: OverlaidXYPlot and MultiXYPlot, both extensions of XYPlot.
These work with regular XYPlots as the subplots, and regular axes. All the
other combined classes can be ignored, although I haven't removed them yet.
The idea is simple enough...for an OverlaidXYPlot, the parent plot maintains
the axes, all the subplots have null axes (the subplots use the parent plot's
The MultiXYPlot can have a HORIZONTAL or VERTICAL layout (as in the existing
CombinedPlot) and maintains one common axis (the other axis is null), with
each subplot maintaining one "non-shared" axis (and one null axis - it uses
the common axis instead).
As part of the change, the dataset is now a property of the plot, not the
chart, which means the constructor API has changed a bit (I expect to get
some hate mail about this, but I think the change makes sense).
I'm not completely finished on this, but it mostly works and I think it will
make the combined plots a little easier to use. I think it will also be
quite easy to implement combined plots for the bar charts using the same