[Kst] Time index lookup

[Nicolas Brisset]

Hi Barth,

I hope you're busily committing to a local git repository, or conceiving this time stuff while I'm enjoying the last days of my vacation :-)
Good questions, see my answers below...

Nicolas

> I agree. But:
> A) Should the list of index-able fields be attached
> -to the current session (ie, the kst file)?
> -to a particular data file?
> -to the data source type (eg, all dirfiles),
> or should it be global?

I think it is enough to have a two-level config for that:
1) if the datasource for this particular file has defined a time vector, then store it as part of the .kst and use that so that .kst files can be transferred between users and work directly
2) have a global config with a UI to store the default time vector

This is not 100% of possible use cases (e.g. there could be more than one time vector in a given file - though it seems you've already planned that as you mention fields in the plural), but I think the best compromise between usability and code complexity.
I don't see the need for a session-level config (you can change it in the global settings for the duration of a session, not a big deal). And I think a data-source level config is awkward. For ASCII for instance I get all sorts of files, and netCDF has different conventions. I think we should not even try it.

> B) Where should the list be managed? This will depend on the answers
> to (A). If global, then the settings dialog. Otherwise, either in
> the data source configuration, or in the range dialog itself.
Hopefully the previous answer is enough for the settings, otherwise ask a more specific question.
I haven't thought about the range dialog yet, it's an interesting question as well but I'll have to think about it a bit more - and maybe experiment with the first versions you'll release to see what works best.
 
> CTime isn't that much different than frame numbers once you have a
> few million frames. I think we should try to eventually implement
> string based time, but I suspect we will mainly use ctime indexes in
> practice.
I'm not sure I understand what CTime means here. But I definitely hope we can use things like 120000.000 to indicate 12 hours 00 minutes and 00 seconds. It's quite easy to use, we have a tool which works like that and it's quite simple and efficient.

On a different front, I'm hHoping to have some time for more PR work on 2.0.6 when I'm back because it looks like this release went a bit unnoticed so far...

Nicolas