[Kst] [Bug 85676] Wish for 0.99/1.0: allow datasources to have configuration dialog/settings

[George Staikos]

We agree, and this is one of the primary reasons for adding configuration.  
Thanks for the files.  I'll look at them if I get that far and have some 
time.

On Tuesday 19 October 2004 04:57, Nicolas.Brisset at eurocopter.com wrote:
> On Tuesday 19 October 2004 08:07, George Staikos wrote:
> > Already started, almost there.  I just need to sort out a layouting
> > issue.
>
> Once it is possible to configure the datasources, you may want to merge
> some code I wrote for a in-house ASCII format which uses fixed columns into
> the general ASCII datasource. It is pretty trivial but if it can save you a
> couple of hours or even minutes, that's so much more for the other
> bugs/features :-)
>
> I adapted the base ASCII source, but to make it as fast as possible in the
> case of fixed width columns (pretty common I suppose) I use 2 things:
> - fixed column width (13 characters in my case, will have to be
> configurable) allows to compute the offset from the beginning of a
> record/line and atof() whole blocks
> - there are no comments beyond the header lines (4 lines in my case), so
> that we can directly call atof() and do not need to parse the whole file
> character by character.
>
> I attach the codes (see.h and see.cpp) since I'll be on vacation next week
> and that may be when you want to look at it.
>
> The configuration options I'd suggest for the ASCII datasource are (George,
> make sure your mechanism allows this :-)):
> - number of header lines to skip
> - line number in which to look for variable names
> - (optional) "units in separate line" checkbox and line number for units if
> they should be used
> - "non-standard separator" checkbox and lineedit for either a regexp or a
> character to use as field separator (either complete file or only header
> ?), by default, use one or more spaces, tab, or ;
> - whether the format is fixed width and if so, spinbox for the
> corresponding number of characters
> - whether to expect embedded comments past the header (which means
> different parsing), and possibly a list of comment characters (#, //, ...)
> - I suppose it is enough to detect lines beginning with these characters
> and that should be treated as comments, but I fear there are people out
> there with files containing non-numbers in some columns, which could mean
> trouble... Of course, it should be possible to save these options. The best
> would be to be able to store sets of options with a name and associated
> file extension that we can recall later, but I think this can be seen as
> optional for now :-)
>
> It looks like some work, but I think it is really worth it having a great
> ASCII datasource as most people will have ASCII files or can easily create
> them, though with some specificities... and none of my colleagues would
> really like to have only numbers as variable names !
> Note that I you had probably guessed I am willing to help with that
> datasource (albeit from Nov. 4th, which may be too late for 1.0 ?).
>
> Nicolas

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