[Kst] Kst2DPlot brainstorming

[Ted Kisner]

On Friday 07 October 2005 17:43, Barth Netterfield wrote:
> I think part of the reason they are all together is that these tasks share
> data to such a large extent.

ok, I don't have much experience playing with kst2Dplot yet, so I was just 
throwing out ideas for discussion...

> 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

Let's say for the purposes of projection discussion that Kst2Dplot stays 
exactly the same except for the addition of a "KstProjectionObject".  In this 
scenario, drawing is handled as previously stated.  Mouse position feedback 
info just involves standard coordinate pair mappings.  

For example, the coordinates of a new zoom box would be given to Kst2DPlot in 
the form of (X,Y) coordinates.  Kst2DPlot would have to call 
"KstProjectionObject::reverseProjection" to get the coordinates in (U,V), and 
then adjust the scale in U/V space and repaint. 

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

How does this differ functionally from above?  A "mouse coordinate 
transformation" seems to just be a set of one or a few coordinate pair 
transformations, that are done with a simple function call...

Maybe you are suggesting putting *all* the mouse handling inside the projected 
drawing area?  So in this case, Kst2DPlot would simply have its member 
functions called by the projected drawing area, and Kst2DPlot would have no 
knowledge of anything except the (U,V) coordinate space.  The only issue I 
could see with this is how do we draw directly to the QPainter for things 
like labels, etc, since these positions are specified in (X,Y) screen 
coordinates?

> 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 don't think it's *that* bad, we just have to plan carefully and think ahead 
about what details we might have problems with.  Whatever we do will be 
temporarily disruptive to 2dplot, but maybe that's good :-)

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

yes, but it still would be nice to modularize somewhat- even splitting things 
into a couple of files would be better than scrolling through 6000 lines of 
code or having to regex search for everything...

-Ted