[Gambas-user] Charts in Gambas: alternatives to "Chart"

[Bruce]

On Mon, 2013-10-14 at 10:09 +0200, Fabien Bodard wrote: 
> I will work on that in 2 week to one month. I need to finish to harvest my
> grappes before and then finish the new report layout function.
> 
> Well to all those are interesting. A first question :
> 
> Is the structure for set the data to the chart is enouth easy to use and
> complete ?
> 
> Then can you give me a list of all kind of chart/chart/plotting you want to
> see.
> 

I have been thinking about this for some time. Months actually.

About 6 months ago we put our first data plots together for some
specific client's use. After a LOT of mucking around with various tools
(and gambas) I finally decided that using a very basic tool gnuplot was
the way to go. After some work we came up with something (very specific
to the user's needs at the time that could achieve the things in the
attached "Jockey Statistics" screenshot.

Note that the chart is embedded in a gambas form.

This was achieved by manually building a gnuplot script and then
submitting the script and a /tmp datafile to gnuplot. Which is able to
output to an X-window. So what you see is a normal gambas panel with a
gnuplot output, based on the jockey name and clicking the Performance
button.

Fine and good. Sort of.  The work involved in the development of the
gnuplot scripts to produce the "Performance" chart (and the "Hit Rate"
chart (that I haven't included)) was terrific.  So that got me thinking.

And here's the results.

The first issue is this. Does the user want to produce a one-off chart
of some data in some format? If so, this is beyond our current
capability and is dismissed out of hand. Go use a spreadsheet.

The second most probable requirement is to plot a different dataset in
the same way. That is what we have with the Jockey Statistics chart.
The greyed out combobox lets them select any jockey they have in employ
and review that jockey's performance over the last 12 months.  This lead
me to believe that we need to separate the chart definition from the
data definition. Of course, under the GIGO principle if the data
supplied does not match the chart needs then gibberish will result. But
more on this later.

Thirdly and with the greatest respect to Fabien for all his work, I
thought "why try to do this stuff from scratch when other people have
done it all before?" Since obviously a) something like gnuplot (or
octave or py-whatever" can produce the graphics we need and b) at least
for gnuplot, there is a way to embed the output in a gambas form, then
why not take the approach "build a component/library/toolkit/whatever
that can ease the task of defining the plot ... and the data
schematic... (told you that would come back) ... define a way to easily
pass the chart definition and the data to that tool and embed the
result.

That was the easy bit.

Then came the following ...

1) What about real time charts? Like those infuriating "applets" that
tell you how much your CPU usage is etc, or more usefully: patient
monitoring, remote weather station tracking etc.

2) What about alternate output destinations. To put that another way,
now I have a pretty picture of the chart on the screen, I want to print
it or save it to a .png file or copy it to the clipboard so I can stick
it in my monthly report etc etc etc.  What a minefield!

3) What about user interaction with a chart? Say zooming in on one area
or scrollling hither and thither along some axis. Etc etc.

So much for the bad news.

Pretty well, gnuplot has answers for most of the above. 
PROS
I can embed the output in a gambas control.
I can separate the data from the chart definition.
I can (now that I have finally sort of almost worked out how to use
pipes) solve 1,2 and 3 above.
CONS
The font control is abysmal (read "Bruce does't understand it")

So, three months later I have a rudimentary tool that is intended to let
the developer 
a) define a chart : the Title, Background, Chart area, whether or not
grids are displayed or not
b) set up a data grid and import sample data from a csv file (reworking
this to allow using an SQL query to load the grid and thus derive its'
attributes
c)define attributes for X,Y and Z axes and X2,Y2 as well.

The results are in the attached GnuPlotter image.

I have still got a long way to go with this but I thought I'd provide
this info in case it is of use.

Bruce

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Jockey Statistics_028.png
Type: image/png
Size: 23422 bytes
Desc: not available
URL: <http://lists.gambas-basic.org/pipermail/user/attachments/20131014/723bb440/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: GnuPlotter_029.png
Type: image/png
Size: 16390 bytes
Desc: not available
URL: <http://lists.gambas-basic.org/pipermail/user/attachments/20131014/723bb440/attachment-0001.png>