[Kst] Kst2DPlot brainstorming

[Barth Netterfield]

On October 7, 2005 04:38 pm, Ted Kisner wrote:
> 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.

I think part of the reason they are all together is that these tasks share 
data to such a large extent.

> ---------
> 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.

There are two aspects that have to be addressed related to projections:
	-Drawing (which your idea seems to handle *very* well
	-Mouse position feedback in, eg, data mode and zoom modes

As a modification to your idea: How about giving KstPlots a 
kstProjectedDrawArea which has both drawing primitives and mouse coordinate 
transformations.

> -----------
> 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?  :-)

The problem is a very thorny one, and we are just scratching the surface of 
the problems that are to be faced, I fear.  I think that 2D plot is a beast 
at least as much because of the complexity and inherent interconnectedness of 
the the problem as because of bad planning.