[Kst] [Bug 123699] fails to create INDEX from .fits file binary extention

Nicolas Brisset nicolas.brisset at eurocopter.com
Mon Jun 19 16:19:40 CEST 2006


------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=123699         




------- Additional Comments From nicolas.brisset eurocopter com  2006-06-19 16:19 -------
Well, I'm also getting confused. When I wrote the cdf and netcdf datasources, I implemented per-field NF, and that's still the way it works. These datasources do not provide INDEX (in the field list) for the reason that I did not see how I could provide the number of frames for that virtual field, and how it would be used. They still return values in readField(...) for INDEX, though, but I'm not sure whether/how this is used.

I'd like to have a clear picture of what I should do to these datasources:
- add "INDEX" to the field list so that the user can pick it as X vector ? But then kst should not call frameCount("INDEX") because I can't return any sensible value in the general case, it should determine the right range by calling frameCount(field) for each field to plot and create index vectors as required (and not more than one for each range !!!)
- do nothing ? But then you need to have useful X vectors in your data file because otherwise you have nothing like an index to plot against (apart from a manual static vector, but that can't be handled from the datawizard and isn't nice)

The better option in my view would be to do as I suggested on the mailing list a while ago: implement a virtual buddyVar() method which by default returns "INDEX" and can be overriden by asynchronous datasources who can handle index/time vectors as appropriate.
Actually, the main difficulty here is that there could be one INDEX per Y vector, and we don't want such a potentially large list. Maybe we need to make a special case for it so that it is not stored, but recomputed as needed ? Clearly not a simple problem...


More information about the Kst mailing list