[Kst] creating a new datasource reader

[George Staikos]

On Wednesday 16 March 2005 13:31, Grant Wilson wrote:

> Thank you for your help.  We are way out of our league in terms of
> programming here so we appreciate your guidance.

   No problem.  Feel free to use the resources of the kst mailing list to get 
help with Kst and learn more about it.

> When editing the configure script for netcdf would it be possible to also
> check for the netcdf_c++ library?  When we compile our netcdf code we need
> both -lnetcdf and
> -lnetcdf_c++ in the Makefile.  Perhaps this is something we should write
> into the Makefile.am instead?

   Yes, that would be changed in configure.in.in.

> Also, could you point us to directions on installing kst from CVS?  Up to
> now we've been downloading and compiling the releases.

  Sure, but don't forget to wait until tomorrow since anoncvs is down for 
maintenance today. :-)

Initial checkout:
export CVSROOT=:pserver:anonymous at anoncvs.kde.org:/home/kde
cvs login
<press enter for password>
cvs -z3 co kdeextragear-2

Compiling:
cvs kdeextragear-2
make -f Makefile.cvs
./configure --prefix=/path/to/kde/install --other flags that you need
cd kst
make
su -c 'make install'

To update:
cd kdeextragear-2/kst
cvs -z3 update -dP

You may occasionally need to rerun Makefile.cvs and configure, but it's not 
always necessary after updates.

If you see complaints that your KDE or Qt are too old, you can change that by 
editting the top level configure.in.in and setting:
#MIN_CONFIG(3.1)

> Finally, our modifications to Nicholas' code were meant to be quite general
> and to only add functionality. 

  That's great!

> However, they were also designed to 
> interface with our instrument's data file format which has well defined
> features that we take advantage of.  We are more than happy to share this
> scheme with anyone who wants it, but we don't want to get into a position
> where we one day download the latest version of kst and our plugin no
> longer functions with our data.  How are issues like these normally managed
> in the open source world?

   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
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.
3) you can use the main data source but apply your own patches before 
compiling it

   It all depends on how you want to manage things.

-- 
George Staikos
KDE Developer				http://www.kde.org/
Staikos Computing Services Inc.		http://www.staikos.net/