[Kst] kdeextragear-2/kst/kst

[George Staikos]

On Thursday 22 May 2003 19:25, Barth Netterfield wrote:
> CVS commit by netterfield:
>
> Made kstvector a kstdataobject
> 	this breaks d2asc compiles, but kst is still OK: Help
> Made doc->scalarList a static member of kstvector, so that kstvectors
> 	can insert their scalars into the list.

  Ah perfect!  Only one suggestion:  From the comments in KstDataObject, it 
looks like Curves, Equations, Plugins, etc all share things in common that 
they do not share with Vectors and Scalars.  Would it make sense to make an 
inheritence structure like this then?

KShared, QObject   (QObject for signals as we talked about before)
	|
KstObject
	|
	|- KstDataObject
	|	|
	|	|- KstPlugins, Curves, Equations, etc
	|
	|- KstContainerObject  (name??)
		|
		|- KstVector
		|	|
		|	|- KstDataVector  (read-only vector effectively, needed?)
		|
		|- KstScalar

We would then have global statics:

QValueList<KSharedPtr<KstVector> > vectorList;
QValueList<KSharedPtr<KstScalar> > scalarList;
QValueList<KSharedPtr<KstDataObject> > objectList;

This will eliminate a lot of code I think, and make it more flexible for the 
future.  I think KstDataObject should also just use a generic input vector 
list, input scalar list, output vector list, output scalar list.  The various 
types of objects don't -have- to use all this functionality, but it's generic 
enough to go in the base I think.

Should I maybe draw this up with Umbrello?

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