[Kst] [Bug 108025] Matrix and image reworking

[Ted Kisner]

Sorry for the late reply, I'll be in poor email contact for the next
couple weeks...  I don't have too strong a preference on the
datasource interface.  I like the idea of providing a different set of
fields that are available for each type of data.  This is much better
than having a global field list and then just returning zero samples
if reading the field as that type is not supported...

sorry I can't be more helpful with this effort in the short term...

-Ted

On 6 Jul 2005 14:09:57 -0000, George Staikos <staikos at kde.org> wrote:
> ------- 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?
> _______________________________________________
> Kst mailing list
> Kst at kde.org
> https://mail.kde.org/mailman/listinfo/kst
>