[Kst] datasource paths in kst files
Matthew D Truch
matt at truch.net
Thu Sep 17 22:49:56 CEST 2009
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.
> 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.
> 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
"Things are more like they are today than they ever have been before."
Department of Physics and Astronomy
University of Pennsylvania
matt at truch.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kst/attachments/20090917/de54f8d0/attachment-0001.sig
More information about the Kst