[Kst] kdeextragear-2/kst/kst

[Barth Netterfield]

Hi,

I understand the desire to change kstvectors to be a data type rather than an 
encapsulation....  but in the mean time, here was how I was going to 
implement this part:

The way that the current structure thinks of things is as if slave vectors and 
scalars are just interfaces to some master objects data, rather than being 
the data themselfes.

-Why does countScalarsAndVectors exist?  Shouldn't the sizes be known in the 
constructor?  In which case they the sizes should be private members.

-Given that, shouldn't the constructor allocate the *inArrayLengths etc, 
rather than doing this (and undoing this) in update()?

-Also, it seems that the constructor needs the list of input vectors and input 
scalars - I was going to have the dialog create ordered lists (parsed from 
the combo boxes) and pass them into the constructor.  These lists should be 
kept in the KstPlugin as private members.

-the plugin (constructor) needs to create its own slave vectors and scalars, 
which need to be kept in its own private lists.  The constructor also needs 
to insert them all into doc->vectorList and doc->scalarList, so 
doc->vectorList and doc-scalarList need to be passed into the constructor. 

-When you create a slave vector, you need to insert its scalars into the doc's 
scalar list with slave->insertScalarsInList(slist) (I just discovered that I 
miss this in lots of places - a sure sign of a bad architecture - Perhaps we 
need a static private member which stores doc->slist for all slave vectors, 
and then put insertScalarsInList in doc->slist in the slave's constructor...

-The names of the output (slave) vectors and scalars must be unique, so in the 
dialog, the entries should be line inputs, not combo-boxes (since existing 
vector names are by definition invalid).

-save needs to save the tag names of all of the input and output scalars.
-The creator for reading a kst file needs to read and set them.

I know this has gotten pretty crufty, but this is where we are....  Lots of 
lists of different kinds of objects....

On Thursday 22 May 2003 05:23 pm, George Staikos wrote:
> CVS commit by staikos:
>
> Lots of plugin work.  Unfortunately the vector architecture is becoming a
> real problem now.  I had to put in lots of hacks that could go away if we
> make all vectors the same (or specialised) as discussed.  I think this has
> to happen sooner rather than later.
>
> The vector list classes need to be reworked too.
>
>
>   M +2 -2      kst.cpp   1.14
>   M +2 -2      kstequationcurve.cpp   1.12
>   M +11 -15    kstplugin.cpp   1.12
>   M +1 -1      kstplugin.h   1.8
>   M +167 -45   kstplugindialog_i.cpp   1.17
>   M +17 -0     kstplugindialog_i.h   1.6
>   M +1 -1      kstpluginlist.cpp   1.3
>   M +1 -1      kstpluginlist.h   1.2
>   M +2 -1      kstscalar.cpp   1.3
>   M +8 -8      kstscalar.h   1.3
>   M +3 -0      kstvector.cpp   1.10
>   M +3 -1      kstvector.h   1.11
>   M +7 -0      kstvectorlist.cpp   1.5
>   M +2 -0      kstvectorlist.h   1.5
>   M +1 -1      plugin.cpp   1.10
>   M +1 -1      plugin.h   1.11
>   M +1 -1      plugincollection.cpp   1.10
>   M +1 -1      plugincollection.h   1.9
>   M +1 -1      pluginloader.cpp   1.8
>   M +1 -1      pluginloader.h   1.5
>   M +17 -14    pluginxmlparser.cpp   1.9
>   M +1 -1      pluginxmlparser.h   1.7
>
>
>
> _______________________________________________
> Kst mailing list
> Kst at kde.org
> http://mail.kde.org/mailman/listinfo/kst