[Kst] Kst "projects" vs files

[George Staikos]

On Monday 22 March 2004 14:01, Barth Netterfield wrote:
> > - 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.

   I thought so. :-)  Basically there would be a way to select what you want 
to export and it would automatically drag in any dependencies (or save all as 
a project, of course).

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

   I assume you're just referring to the "style sheet" idea.  I think it's a 
natural part of it.  It separates the "view" from the "objects" in the file, 
and lets you mix and match views and objects very easily.  It's not complex 
to implement - it just splits the parse loop in two.  The benefit to the user 
is that Alice can send Bob a Kst project, and Charlie can send just an 
updated view that displays in a different way, or a different set of data 
from the same data collection.

-- 
George Staikos
KDE Developer				http://www.kde.org/
Staikos Computing Services Inc.		http://www.staikos.net/