[Kst] kst2 problems...

[Barth Netterfield]

the ascii data source actually is used to load a variety of different file 
types.  It can read white space delimited columns, csvs, fixed with columns, 
etc.  And it might be taking field names from the file.  There may be 
different standards for comment delimieters.... And it may be that in a given 
session, you have read in some of each.

SO:
-we need to be able to have a different (sticky) setting for each specific 
file
-we need to be able to have a (sticky) set of rules for knowing that .csv 
files are comma separated files, etc.  
-we need to be able to set a (sticky) default for all files it can't figure 
out some other way.

BUT:
someone might send me a .kst file and a tmp.dat file (in some format that I 
don't typically use)....  Loading the kst file should work.  So the sticky 
settings need to be able to be overriden by non-sticky settings in the kst 
file.

Now... how you store all this information is another question.  Maybe just one 
ascii config place where all of the stuff is stored is the easiest.

Time to re-visit the Data Source doc I think.

cbn

On September 27, 2007, Adam Treat wrote:
> On Thursday 27 September 2007, Brisset, Nicolas wrote:
> > I can't really help you with the details here, all I can say is:
> > - we use the datasource config stuff very often (especially with ASCII)
> > - something I had in mind when I did the first prototype (which George
> > then improved heavily :-)) and which was never implemented would be to
> > remember extension <-> settings so that we can switch settings from a
> > combobox. It is not high priority, though as long as saving/loading
> > remembers the settings for each datasource as it currently does...
> > - even in the 1.x series, configuring the datasource from the first
> > datawizard page does not always work. I forgot the scenario but there
> > are cases when you'd run into problems. I think it happens if you come
> > back to the first page after you create a datasource instance, e.g. if
> > you see only numbers in the list of fields when you expected to see
> > names. I believe the datasource does not get destroyed and reconstructed
> > with the new settings, but that needs to be checked. I guess this is
> > pretty complex to implement properly...
>
> I don't think it is.  I just need to know whether we expect to have a
> separate qsettings object for each datasource per session.  ie, does ascii
> datasource plugin just want a place to write its global settings? or does
> ascii datasource plugin want a qsettings object *specific* to some session
> we've just loaded?
>
> Cheers,
>
> Adam
> _______________________________________________
> Kst mailing list
> Kst at kde.org
> https://mail.kde.org/mailman/listinfo/kst