[Kst] datasource paths in kst files

[Matthew D Truch]

Since it's september, how about a good 'ol: "Me Too."

Don hit pretty much everything exactly as I would want as well.

> 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/



> _______________________________________________
> Kst mailing list
> Kst at kde.org
> https://mail.kde.org/mailman/listinfo/kst


-- 
"Things are more like they are today than they ever have been before."
--------------------------
Matthew Truch
Department of Physics and Astronomy
University of Pennsylvania
matt at truch.net
http://matt.truch.net/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kst/attachments/20090917/de54f8d0/attachment-0001.sig