[Kst] Kst2DPlot brainstorming
netterfield at astro.utoronto.ca
Sat Oct 8 02:43:11 CEST 2005
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
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
> 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.
More information about the Kst