[Kst] Explanations on datasource readField/update methods ?

[Nicolas.Brisset at eurocopter.com]

Dear Kst developers,

I have finally found the way to test my cdf plugin that uses an external lib. 
After some fiddling around with Makefile.am files and the like and looking at 
the lffio datasource, I managed to add the appropriate kstdata_cdf_la_LIBADD 
flag somewhere. I could probably not do it again, but at least it runs 
now :-) Once the thing is ready for commit, someone will have to integrate it 
properly, but for now it needs more testing...

When I select a cdf file in the first step of the datawizard, the 
understands_cdf function picks it up, and I can see the list of variables in 
the following page of the wizard. I select the ones I'm interested in, and 
proceed through the last steps. I can then see a progress dialog... before 
kst crashes ! Using some traces (with cout, probably not the right way but I 
don't know how to use kdDebug), I found out that the CdfSource::readField 
method is always called with a starting number of 0 and a number of values to 
read of -1. I guess that's not the way it's meant to be, but it is not 
straightforward to understand why. In the case of a plain ASCII file, the 
method is called with sensible numbers (on a test file I used, starting value 
0 and number of values = number of lines in that file). Why isn't this the 
case with cdf (which is a binary format) ?

Another thing I noticed from the traces is that the DataSource::update() 
method is called on all files which have been clicked on in the first page of 
the datawizard, even another file is used in the end. This is surely not the 
desired behavior and actually looks like a bug ?!!? (I'm using code from a 
June 22 2004 CVS snapshot). It looks as if update timers were instantiated on 
the files a bit too quickly :-)

Finally, I wonder when exactly the readField() and update() methods are called 
and when the datasource is instantiated and destroyed. I suppose it is safe 
to just return KstObject::NO_CHANGE from update when the files are not 
real-time sources but 'fixed', but I'd like to be sure...

Thanks for your help,

Nicolas