[Kst] Kst2DPlot brainstorming

Barth Netterfield netterfield at astro.utoronto.ca
Sat Oct 8 01:06:02 CEST 2005


I agree with your suggested approach, in general, subject to a closer look....

cbn

On October 8, 2005 03:39 am, Ted Kisner wrote:
> 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
>
>
> _______________________________________________
> Kst mailing list
> Kst at kde.org
> https://mail.kde.org/mailman/listinfo/kst


More information about the Kst mailing list