[Kst] Kst2DPlot brainstorming
tskisner.public at gmail.com
Sat Oct 8 01:38:01 CEST 2005
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
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
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
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
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
So what do you all think- am I crazy? :-)
More information about the Kst