[Kst] Long Term Goals

[Barth Netterfield]

On Tuesday 23 November 2004 18:04, Andrew Walker wrote:
> Here are a few unrelated comments on the Long Term Goals:
>
> The long term goals document reflects the wishes of a marketing manager,
> in that is is a wishlist of wanted bug fixes, useful features,
> nice features, eye-candy features, etc. The trivial items (i.e.
> simple to implement or simple to describe) should be added to
> bugzilla and removed from this document.

I can't do bugzilla on the subway, and that is more or less the only time I 
really have to work on it (some in the evenings).  If I send you stuff, can 
you do the bugzilla work?  Bugzilla also needs to be cleaned out of things we 
are not going to do....  

> The difficult part now is to take this document and create a
> document that represents the view of a project manager. I think
> this should first involve setting a release date for 2.0 and then
> ripping out everything that can't be done by then, based on the
> resources available. This would involve getting time estimates
> for all of the major features.

I will work on this.  Then we can either meet or have a telecon to refine.  (I 
think a face to face would be good).

> Following that would be documents from the point of view of a
> development manager. This would involve creating specifications
> for each new feature with UI mockups, highly detailed behaviour
> descriptions. This is something we have generally been very bad at
> in the past.
>
> After that comes the class and interface design, and then implemenation.

I think we will have to do this in a distributed manner, as I don't see any 
one of us able to take on the whole thing.  The interested coder would create 
the specs, etc (at a level commensurate with the complexity of the feature) 
for comment, and iterate on the list (this way we can also include user 
feedback), then the class/interface design (back to the list) and then 
implementation.

> The long term goals are clearly very aggressive. How feasible the idea is
> to provide both near-real-time data viewing together with presentation
> quality presenation is unclear, but can certainly be aimed at.

I think there is nothing fundamental stopping us.

> One feature I think we should add is journaling - which would provide a
> log of all actions (vector creation, equation creation, fitting, etc.)
> that are taken during a session. For any group dealing with critical data
> which must be able to trace their steps this would be very useful, and
> is something that the LFI is very interested in. This could be as simple
> as extending the Kst Debug log, but would involve much more information
> being written to it.

Interesting.  The way kst stores things internally is re-generatable at any 
time (because of the real time nature).  So unlike in other environments, 
where you may act on a vector, and end up with a different vector which has 
no recollection of what operations have been performed, with kst you create a 
data object (eg, plugin) which is in fact the operation (which produces the 
output vector as a slave, which only exists as long as the data object 
exists).  So how you get to the final answer is always in the current state.

Given this, I wonder if perhaps the current elog system is exactly what you 
want - when you get to an answer, submit an elog, with the current kst file, 
and everything you need to reproduce it (except the raw data...) is there.

But on this line (to make it even better), a visual representation of the 
current state (as an alternative to the data manager view) could be pretty 
useful.

And you remind me - I forgot 'undo' in the plan.