[Kst] [Bug 108025] Matrix and image reworking

[George Staikos]

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
         
http://bugs.kde.org/show_bug.cgi?id=108025         




------- Additional Comments From staikos kde org  2005-07-06 16:09 -------
On Tuesday 05 July 2005 20:05, Rick Chern wrote:
> // returns the list of matrices this datasource contains
> virtual QStringList matrixList();
>
> // whether or not the matrix name is a valid name of a matrix
> virtual bool isValidMatrix(const QString& matrix);
>
> // read the specified sub-range of the matrix, flat-packed in z
> // the suggested scaling and translation is returned in
> // xMin, yMin, xStepSize, and yStepSize
> virtual int readMatrix(double *z, const QString& matrix, int xStart, int
> yStart, int xNumSteps, int yNumSteps, double& xMin, double& yMin, double&
> xStepSize, double& yStepSize);


  I really don't like passing data out in references.  It's very unclear 
what's happening, and Kst2DPlot is turning into spaghetti (partially) because 
of it.  I think it makes more sense either to use a context handle, or use 
pointers so that we see the & and know that it can be modified.

  What is the return code mechanism for readMatrix()?

  Ted, what do you think of this interface?

> The list of matrices is separate from the list of field names, but the
> datasource may choose to support all, no, or some vector fields as
> matrices.


  Seems reasonable to me.  Maybe it makes sense to split it up like this:

fieldList(); // all fields of all types
vectorList();
matrixList();
scalarList();
stringList();

  And perhaps have a method to query the capabilities of a given field name.

> There is no concept of frames for matrices.


  Why not?  Does it never make sense?