[Kst] datasource paths in kst files

D. V. Wiebe dvw at ketiltrout.net
Thu Sep 17 22:29:47 CEST 2009


On Thu, Sep 17, 2009 at 03:08:48PM -0400, Barth Netterfield wrote:
> In 1.x, kst stored the entire path to the data source in the .kst files.
> 
> Currently, 2.0 records the file path relative to the cwd (this seems bad to 
> me).
> 
> Josh suggests that kst 2.0 records the file path relative to the location of 
> the .kst file.
> 
> Thoughts?
> 
> cbn

Yeah, paths suck.

The 1.x way is great if you want to truck your .kst file around and you
know your data is in a constant place.  For example, the 1.x way worked
great for BLAST quick-look, where the datafile was always
/data/etc/defile.cur.  We could store .kst files in CVS, and when people
downloaded them, they just worked with kst and defile.

Josh's way is sort of how GetData handles relative paths in the format
file.  It works well if you're planning on shipping the .kst file around
with the data (which dirfiles do with their format files).  But it
wouldn't work well with the old BLAST defile scheme.

The kst 2.x way is sort of "user-relative" and I agree, it could get
bad.  One advantage is that the user can fix "broken" .kst files by
simply going to the proper directory.

I'd like to see a kst with a flexible, adaptable approach to paths.
Specifically:

1) kst should honour the method by which users specify paths.  An
absolute path specified should be saved as absolute:

  $ kst -y 1 /tmp/datafile

as should a relative one:

  $ kst -y 1 ./datafile

(Presumably the user has a better understanding of whether absolute or
relative is more appropriate.)

2) Store paths to files selected with the file selection widget relative
to some known base; store the base path, too.  Store kst's cwd in the
file, too, while your at it.

Then, when the .kst file is loaded later, attempt to find a data source
specified by relative path by trying different bases (in some specified
order, though not necessarily this one):

* the base path to the relative file stored in the .kst file (this is
  effectively and absolute path)
* the current working directory (kst 2.x style)
* the cwd stored in the .kst file (another form of "absolute path")
* the directory containing the .kst file (Josh style)

3) If this is done, there needs to be a facility in kst to allow users
to rewrite data source paths, so that they can change absolute paths to
relative ones, &c.

Bottom line: there are cases were absolute paths work best, and cases
where relative paths work best.  Restricting yourself to one or the
other will always create problems.  Be flexible.

Cheers,
-dvw
-- 
Don Wiebe                                   dvw at physics.ubc.ca
Department of Physics and Astronomy
University of British Columbia
6224 Agricultural Road                      Tele: +1-604-822-2585
University Endowment Lands, BC
Canada   V6T 1Z1                            http://ketiltrout.net/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kst/attachments/20090917/88a0e73e/attachment.sig 


More information about the Kst mailing list