[Kst] Kst generalized "plotsource"

[Theodore Kisner]

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