[Kst] Kst "projects" vs files

[Barth Netterfield]

On March 16, 2004 10:36 pm, George Staikos wrote:
>    There have been several requests for various mechanisms to do things
> like load in data with a kst file, then switch the "kst file" without
> switching the data, or switch the data without switching the "kst file".  I
> was thinking that there might be a solution to this with a slightly
> different mentality.  Background:

> - You can already switch data very easily using "indirect files".

or by using the changeFile dialog...  Or from the command line (-F)

> - Kst files are handy because they separate the data from the
> view/structure, and are editable.
> - We have no good way to create new data and attach it to a Kst file
> cleanly. - We don't want data inside Kst files since it breaks the
> data-independence and makes Kst files big and inefficient.
>
>    Why not take an approach similar to what IDEs do, using a "project" and
> associated files?  We could then have these concepts:
>
> - Kst Project - a tar.gz stream of some or all of the below - probably not
> commonly used, but convenient for transporting.

Actually, this could be exceedingly useful!  Instead of dropping a png (which 
is static, non zoomable, etc) on the elog server, one could drop one of 
these, generated from the existing vectors.  Currently people email around 
kst command lines, and hope you have all of the data local, which one 
normally doesn't.  I'm imagining a .kst plus binary data vectors.

> - Kst Project File - describes a list of .kst files, data files/sources,
> and kst style sheets
> - Kst file - same as we have now, slightly restructured to more clearly
> separate data logic from style/output logic.  Actual styling would go into
> something analogous to a style sheet as seen on the web.
> - Kst Style Sheet - another XML file that describes the output to generate
> from a set of data objects.  can also exist as content embedded in a Kst
> file, and can be dynamically changed at runtime.

???  This seems to have a low benefit to complexity ratio.    What does it 
give the user?

> - Data files - the usual
>
>   Now if the user creates vectors at runtime, they can be stored as data
> files on disk and registered in the Kst project file.
>
>    Does this sound useful and sensible?