[Kst] creating a new datasource reader

[Brisset, Nicolas]

> > Also, could you point us to directions on installing kst 
> from CVS?  Up 
> > to now we've been downloading and compiling the releases.
> [...]
Alternatively, you can download the daily kdeextragear-2 snapshot from
ftp://ftp.kde.org/pub/kde/snapshots/kdeextragear-2.tar.bz2 if CVS is not
an option from you (proxy in the way or other reason). Note that you
have to configure in the root of kdeextragear-2, but you can compile and
install only kst (after configure finished, just do "cd kst;gmake &&
gmake install").

> > Finally, our modifications to Nicholas' code were meant to be quite 
> > general and to only add functionality.
That's the way it should be :-) Please try to avoid adding/changing
stuff that is specific to your usage of netCDF and that would not work
with other netCDF files. As netCDF allows to organize data in pretty
much any way, it is true that you may have internal "standards" you can
benefit from, but not everybody may have files conforming to your rules.

>    You have [at least] three choices:
> 
> 1) you can implement it in a generic way and use 
> configuration variables or other such things to implement 
> your specific functionality
Since datasources can now be configured, I suppose providing
configuration options in the appropriate place/dialog (look at the ascii
datasource for examples, and ask for help on this list if you're stuck)
is the best way to go. There again, try to make the options as generic
as possible. For example, imagine you are using particular ascii files
with 2 header lines (the first line containing free information and the
second variable names) and fixed-width columns of 14 characters. It is
better to define options allowing to set the number of header lines and
location of variable names, and use the values provided by the config
widget in the code, than providing a checkbox in the config dialog
saying something like "astro format". I guess this is pretty obvious,
but in most cases there should be a way to make the option reusable for
others, even if it is not the simplest way to go from the programming
point of view.

> 2) you can fork a copy of the datasource and implement your 
> own functionality.  
> datasources -can- be developed outside the Kst source tree.  
> If not, it's a bug that should be reported to us.
I confirm that this works, but you will have to learn how to tweak
configure.in and the like :-)

> 3) you can use the main data source but apply your own 
> patches before compiling it
Also an option, but if other people make changes that conflict with
yours, it will not be the best options in the long run.

Nicolas