On Tue, Jul 22, 2008 at 6:55 PM, Eric Firing <[EMAIL PROTECTED]> wrote: > Ryan May wrote: >> Hi, >> >> I'll continue my current flood of emails to the list. :) I'm finally >> getting back to my work on Skew-T plots, and I have a semi-working >> implementation (attached.) It runs, and as is, plots up some of the >> grid, with the x-value grid lines skewed 45 degrees to the right (as >> they should be.) The problem is as you resize the plot horizontally, >> some weird things happen. First, some of the lines that start overlaid >> end up separating as you expand the plot. The difference is between >> what is added using ax.plot and what is added using ax.vlines. The >> former adds Line2D objects while the latter adds a LineCollection which >> is holding path objects. I'm really not sure what's going on there. I'm >> not done checking it out yet, but I'm curious if anyone has any ideas >> off the top of their head. >> >> The second issue, which is more pressing, is when you resize vertically, >> the axes limits of the plot don't change (good), but unfortunately the >> lines don't stay connected to their lower y-coordinate in data space >> (bad). I'm really needing to draw things in a coordinate system that's >> independant of the data scale but also doesn't depend on the aspect >> ratio of the axes, so that I can get lines (and data plots) where the x >> gridlines are always at a 45 degree angle and the lower Y-value point >> stays fixed. By problem right now is that while I can find the lower >> left corner in pixel space and use that to do the proper adjustments, >> this changes when you resize. This changing is especially important in >> the y-direction. What I need is either of: >> >> 1) Axes space adjusted for aspect ratio (and updated with resizes) >> 2) Pixel space relative to some corner of the axes >> >> Or something similar that I don't know about. Any thoughts, or do I >> just need to come up with some magical combination of transforms that >> works? You can see what I have so far in my attached file. >> > > Ryan, based only on your description of the problems, and of what you > need, I think the answer, or at least part of it, may be in good old > quiver. Look at the way the transform is being generated depending on > the units chosen, and note that preserving a specified angle on the page > is part of it. Also note that the transform has to be regenerated on > resize events, so a custom draw method is required. > > (Mike D. translated my original quiver code to use his transforms > framework.) > > It seems like there should be an easier-to-use and more general way to > do these sorts of things, and maybe there is--or maybe it can be ginned up. > > This reminds me of a thread a long time ago regarding adding hooks so > that classes could register methods to be executed before their artists > are rendered but after things like window and axes sizes have been > determined.
Since I'm 1. A meteorologist and 2. responsible for the draw-hook thread, I see I'm implicated here :) The utility of the before/after draw hook comes in when you want to do something system wide on all draw events. If the SkewT needs to do some setup before the Axes draw, a simple override of draw() seems the better route, since the need here would be class specific. That said, I was inspired by this to add on a bit to my previous hook solution, but that belongs in a separate thread. -Eric B ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
