[Scipy-chaco] RE: [SciPy-user] FW: anti-grain

[eric jones]

Hey David,

> eric jones wrote:
> 
> > ???  I don't quite get this.  We have to know the sizes of the axis
> > labels (both titles and numbers) to trim off enough real estate
around a
> > plot so that the numbers don't overlap onto the graph (y labels) or
onto
> > each other (x labels).  I'm not sure how you would do this without
> > precalculating the actual screen size of the text.
> 
> You're right.  I didn't realize the sophistication in your algorithms
(I
> should have, I've admired the tick marks and labeling choices).
> 
> > It would be better not to have the reportlab dependency if we don't
> > loose any capabilities, so if the backend is trivial (nearly
identical
> > to the PS one I guess?), I'm for removing the dependency.
> 
> Ok, I'll try and do that later this week.

Cool.

> 
> > I'm betting OpenGL will win -- or if it doesn't now, it will in the
> > future.  Unless there is a compelling reason to get rid of it at
some
> > point, keeping an OpenGL backend seems like a good idea.  There are
only
> > a few features that will be problematic with it (and probably won't
be
> > supported).  These include "join mitering" and "line end caps."
> 
> I've never needed those in display code -- only in printouts.  PIL
will
> never support that either, and I don't care =).

I don't see these as major right now either.  On the other hand, one of
the desired "selling points" for Kiva is that you get the same output on
all platforms.  I also hope that it expands to be useful in areas
outside of just scientific plotting, and other disciplines may consider
these capabilities important.  PDF,PS, and (I think) SVG will all
support them.  It'd be nice if the bitmap/screen rendering did also.

> 
> > The
> > other thing I'm a little worried about is thick lines.  I think some
> > OpenGL implementations don't support lines thicker than 10 points.
> > Beyond that, you have to draw a polygon.  This will lead to silly
> > if/then code.  There are probably other things, but Dave Morrill,
has
> > gotten it all 90% there.
> 
> There are other weirdnesses, such as the fact that OpenGL "points" are
in
> screen pixels, not in viewspace coordinates.  But since Kiva doesn't 
> support points yet, you haven't noticed it =).

DisplayPDF (or at least the API we're emulating) doesn't have a "point"
command.  I think you would create a point by calling the arc() command
to form a circlular path of a given size.

> 
> [..docs...]
> 
> > I promise that this will be remedied, but I won't promise when. :-)
> 
> I'll produce a quick writeup of how to do a backend like the ones I
did --
> someone else can write the "interactive" part.

That would be very nice. Thanks.

> 
> What I'm most in need of isn't Kiva information -- that code is fairly
> straightforward.  It's the Chaco class hierarchy and fancy 'delegate'
> handling
> which I'd love to learn more about.
> 
> Ooh.  I just figured out how to do compound plots -- there's a minor
bug
> in
> plot_container.py:NestedContainers._add_item() -- it shouldn't fail if
> there's no "window" attribute.  With a try/except around that access,
I 
> get compound plots w/o having to invoke any of the GUI stuff.  Yeehah!

You should have CVS access soon to fix this.

> [Aside: why do some lines in .co files have the format "foo = bar"
while
> others have "foo: bar"?]

That is a question for Dave M.

> 
> > Wait a second... Something must be wrong with the email transmission
> > here.  I'm missing the file where you defined all the javascript
code to
> > support interaction with the plot.:-)
> 
> Until I get marker support code in Kiva, there's not much point to
doing
> that. 

That is definitely desirable.  Realistically, that is weeks away, unless
you work with Dave M. to rectify it.  He is re-factoring this week to
make it easy to support multiple kinds of plots with stacked bar charts
being the first priority.
 
> I'm don't see SVG as the base for a full-fledged interactive UI 
> (although that would be cool in a sick kind of way) 

Yeah, I'm kinda curious how much effort it would take or if it is even
possible from Chaco.  I'm thinking it will fall in the "a lot of work"
category.

> -- but I do want to 
> support some "data mining operations" -- click on a marker hits
another 
> web page that gives you more details about that data point, etc.  That

> will happen by adding metadata to individual data points (aka
markers).

Sounds like something Chaco should support to me.

Also, lets move future discussions to scipy-chaco at scipy.org.  We're
(thankfully) getting pretty noisy about the plotting stuff, and the
scipy-user crew may not be interested in the discussion.

Thanks,
eric