[Kst] Kst2DPlot brainstorming

[Ted Kisner]

On Wednesday 05 October 2005 17:01, George Staikos wrote:
> Hopefully we can use that opportunity to pull this stuff -out- of Kst2DPlot
> and into a separate class.  I would like to see it down to a maximum 2000
> lines of code again.  It's doing too much in one place, making it hard to
> understand, hard to extend, and hard to maintain.

George, I've been studying kst2dplot a bit closer, and I see what you mean 
about it being a swiss army knife class :-)  I also have been doing a lot of 
thinking about this since Barth's subtle remark yesterday that I should 
"explain how a healpix basecurve would display in a log plot".  

The point which I was missing is that any basecurve is currently able to be 
displayed with any other basecurve, so they must all support *every* type of 
display.

The KstHealpix basecurve I had been thinking of would create a ton of 
redundancy with the stuff already in 2dplot.  This is obviously the wrong way 
to go about it.

Sooo, it seems that the healpix issues are more interwined with the 2dplot 
code than I had realized.  Specifically, Barth was right that there needs to 
be a generalized method for projections from any 2D coordinates to the 
cartesian plane.  This needs to happen outside of kst2dplot to avoid bloat.

---------
I guess the current purpose of kst2dplot is to handle a variety of things 
which are common to all basecurves in a given plot:

1.  telling the basecurves when to paint
2.  painting the axes, legend, axis labels, grid lines, etc
3.  mouse/keypress handling, including zooming, finding nearest points, etc
4.  launch pop-up menus to configure everything

---------
It seems to me that one way to split this up is the following:

1.  Move all the time related functions to a separate KstTime class or 
something similar.

2.  Move all mouse/key handling to an external class.  This will also make it 
more portable when we want to use it for Kst3DPlot in the future.

3.  So Kst2DPlot will still be responsible for drawing the axes, plot labels, 
grid, and legend.  It will also call on all the basecurves to paint 
themselves.

---------
The next question is:  how to handle projection?  All of the basecurves 
currently know how to draw themselves to a rectangular QPainter using 
graphics primitives.  Kst2DPlot knows how to draw gridlines in the same way.  
Ideally we would have a magical class that would take QPainter-like calls and 
transparently handle the projection onto the "real" QPainter.

What about a new "KstPainterObject" class that has the following members:

a)  a pointer to a QPainter
b)  low-level projection functions that define the forward and reverse 
projections for a single coordinate pair
c)  range min/max parameters for both the real and projection spaces
d)  a subset of the normal drawing primitives.  Each descendent of 
KstPainterObject (KstPainterPolar, KstPainterLog, KstPainterSin, etc) will 
specify how to draw a projected graphics primitive (point, line, etc).

How it would work in practice:

Kst2DPlot would have an instance of a KstPainterObject.  It would paint some 
things (axes, labels, legends) directly to the KstPainterObject->QPainter.  
When drawing tick marks, it would call the simple coordinate pair 
transformation functions to determine where to place the tick marks and what 
numbers to place by the ticks.  It would paint the grid lines by calling the 
KstPainterObject->drawLine member, which would project it onto the underlying 
QPainter.

A pointer to the KstPainterObject would get passed in the context variable to 
basecurves.  Basecurves would only need slight modifications in order to use 
the KstPainter functions instead of the QPainter functions.

-----------
For healpix support, all that would be needed is a very simple and general 
vectorfield basecurve.  All the projection, gridlines, etc would be taken 
care of.


So what do you all think- am I crazy?  :-)

-Ted