[Kst] Kst generalized "plotsource"

[Andrew Walker]

Hi Ted,

I think this sounds like an excellent idea, as Kst2DPlot
shouldn't really know how to plot a curve or image. A
Kst2DPlotSource sounds like a good approach to this.

George Staikos has a stranglehold on architectural changes
like this, so you should await a response from him as well.

Andrew


-----Original Message-----
From: Theodore Kisner [mailto:kisner at physics.ucsb.edu]
Sent: Monday, June 06, 2005 6:10 PM
To: kst at kde.org
Subject: [Kst] Kst generalized "plotsource"


Hello Kst folks,

I've been reading through the Kst source and have a couple questions about
the
structure of Kst.  I also see that in the release plan, there is a planned
refactoring of the KstImage/KstMatrix classes, so some of my questions may
not be relevant...

I've been trying to think of ways to make it easier to add support for
display
of new types of data.  Reading any kind of data from a file to vectors is
already wonderfully easy through use of datasource plugins:

(data file) --> [datasource] --> (Kst Vectors) --> (KstDataObject)

The final step that seems to be needed is to provide an easy way to describe
how a new type of data is displayed.  Currently there are KstBaseCurve and
KstMatrix that inherit from KstDataObject.  Kst2DPlot keeps a list of these
(well, actually curves and images) and also paint functions for each of
these.

So, keeping in mind that I am a *complete newbie* KDE programmer, I was
thinking it might be easier if we had something like a "Kst2DPlotSource"
plugin that describes how a KstDataObject should be painted:

(KstDataObject) --> [Kst2DPlotSource] --> (Kst2DPlot for zooming, buffering,
etc)

 AND

(KstDataObject) --> [Kst3DPlotSource] --> (Kst3DPlot for zooming, buffering,
etc)

class KST_EXPORT Kst2DPlotSource : public KstObject {
  protected:
    Kst2DPlotSource(const KstDataObject& data, const QString& type);
    ...
  public:
    ~Kst2DPlotSource();
    void plotData(QPainter& p,
      double Lx, double Hx, double Ly, double Hy,
      double m_X, double m_Y, double b_X, double b_Y,
      double x_max, double y_max, double x_min, double y_min);
    ...
  protected:
    KstDataObject* _data;
    ...
}

So then the idea would be to move all of the Curve-specific and
Image-specific
code from Kst2DPlot into their respective "plotsources", while leaving in
all
of the buffering, zooming, etc.  Kst2DPlot would then have a list of
plotsources for each plot, and simply call the paint function for each one.

In this way, supporting a new data format would consist of writing a
datasource and a plotsource.  The plotsource would have control over
low-level
painting of information in the KstDataObject.

Of course, I have not given any thought to how slow it would be calling
external plugins at this stage of the plotting.  This may be an unacceptable
performance hit...

In any case, you all are more experienced at KDE programming than I am, so
you
probably can think of a better / more elegant way to generalize this.  Is
some kind of restructuring along these lines planned for the future?

I am starting to implement support for healpix plotting, and have found that
there is no general way of doing this aside from creating yet-another-class
that inherits from KstDataObject and cluttering up Kst2DPlot with many more
functions specific to the new class.

Of course, I don't believe in making idle suggestions for massive code
restructuring without offering to help out ;-)  If you think that this is a
worthwhile effort, I will try to create a finely grained "demonstration"
patch set that attempts this kind of reorganization.

Alternatively, if someone is already working on something like this or will
be
in the future, just let me know and I'll get out of the way :-)

Any thoughts or comments?

cheers,

-Ted




_______________________________________________
Kst mailing list
Kst at kde.org
https://mail.kde.org/mailman/listinfo/kst