[Kst] ASCII config patch

Brisset, Nicolas Nicolas.Brisset at eurocopter.com
Tue Feb 1 09:22:45 CET 2005

> Regarding ascii configuration:
> It seems to me that perhaps the correct way to do this is to make a
> separate
> csv data source, rather than using the generic ascii one.  csv seems
to be
> pretty well documented  - see
> http://www.creativyst.com/Doc/Articles/CSV/CSV01.htm
> and, as it is used by exel, very common.  So it would be really great
> support it.
This document describes a very generic CSV format. In all real-life
cases I see around here that deal with _numerical data_ (the only case
of interest for kst, where we won't have line breaks embedded in the
fields !) the configurable ASCII source as I proposed works very well. I
personally don't see the need to add a specialized CSV datasource but I
don't mind if there is one, as long as it is still possible to use the
configurable ASCII source to read formats not picked up by the CSV one.

> The one configuration option we *might* need is whether the first row
> contains
> field names.  We could guess correctly with pretty high reliability,
> seeing if the first row is numbers or not, but we should allow a
> override to our guess.
Adding automatic format detection is something I also considered. I
believe it would not be overly difficult to find some heuristics to
determine the major characteristics automatically. As you say, we'd
still need a manual option in case we get it wrong. But I see that as a
subsequent step: first, add the manual configuration options, then add
further options, one being automatic format detection.


More information about the Kst mailing list