staikos at kde.org
Fri May 23 01:40:29 CEST 2003
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)
| |- KstPlugins, Curves, Equations, etc
|- KstContainerObject (name??)
| |- KstDataVector (read-only vector effectively, needed?)
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?
KDE Developer http://www.kde.org/
Staikos Computing Services Inc. http://www.staikos.net/
More information about the Kst