[Kst] Datasource questions

[George Staikos]

On Tuesday 18 October 2005 06:51, Brisset, Nicolas wrote:
> Regarding the problem I reported yesterday, it seems that "INDEX" is the
> default X axis value stored somewhere (kstvectordefaults.cpp ?), which
> for some reason "overwrites" the first value in the list built by the
> datasource in some cases. Once you've managed to change that value to
> something else, it works fine. The funny thing is that you can load
> other vectors (say  Vec3 as X and Vec4 as Y) and when you invoke the
> datawizard again, the list for X vectors is right. Maybe I should file a
> bug report for that one ?

  It should not overwrite.  Please file a bug report with a concrete example 
so we can investigate.

> If I've understood the process correctly (which I doubt), it works in
> the following way:
> - invoke the datawizard and select a file: all installed datasources (a
> .desktop file is provided and the .so can be loaded) are queried via the
> undertands_[type] functions

  Yes

> - for all datasources returning "understands" values > 0, the field list
> is queried via fieldList_[format] functions if existing, otherwise the
> constructor is called and then the fieldList() method, then the
> destructor

  Yes

> - the datasource returning the highest number in understands_[format]
> wins, if there are equal results the number of fields returned is used
> to determine the best candidate (I don't know whether understands values
> are limited to 100 prior to comparison ?)

   Yes, whichever is largest.  100 is not enforced, but anything >100 is not 
supported.

> - when you click Next, the lists for X and Y vectors are built calling
> the constructor and fieldList methods (which can result in some delay
> e.g. when the constructor parses the whole file). I don't have the
> feeling that previously built field lists are reused here, or at least
> not always. That is also where I don't understand why the value stored
> in KDE settings (INDEX) can overwrite the first element in the X axis
> list: it should be set as default selection if present in the list, but
> not overwrite the first element

   This could change, so we can't reuse.  That's up to the source to deal with 
internally.

> - step through other pages in the wizard, click "Finish": it creates the
> vectors, asking for the number of samples for each (I suppose
> frameCount(field), but maybe just frameCount() in some cases ?) to then
> load the values with readFiled(field, 0, nb_samples). Apparently, it
> actually does readField(field, 0, nb_samples-1) and just after
> readField(field, nb_samples, -1). There must be a reason (maybe update()
> is called in between ?) but it's not very clear

   That's for frames > 1 samples.

> - at the pace determined by the time setting, update() is called. (Is it
> called a first time unconditionnally to detect updates while
> initializing plots ?). If it returns ::UPDATE, something happens
> (frameCount(field) + readField(...) for each plotted field ?) otherwise
> nothing. Another question I have here is whether it is OK for update to
> set _valid to false if there is a problem (e.g. the data file is gone
> !). Apparently, it takes more than that to stop the update process...
> Even so, what happens when _valid becomes true again ?

   Hm, I haven't thought of this.  File a feature request for the ability to 
go valid/invalid at any given time please.

> - if the user hits "Reload", George already wrote what was supposed to
> happen. But I have put a trace in the constructor at some point while
> trying to understand something, and I noticed that it gets called 19
> times (!) for a given file. That does not sound right to me! (This
> should perhaps go into another bug report ?)

  Doesn't sound right.  Caching must be failing.  Please file a bug report.

> I would be grateful if someone with more insight could correct/complete
> the above description and post it somewhere. Of course, I could look at

  I hope that helps.

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