Lots of god stuff John! > There is also the question of whether > we want to pay up and use 4x4 from the ground up and just ignore the > 3rd dimension to open the door for 3D support.
I say yes! 3-d really is a very often needed and requested feature. Sure, we can go to VTK or something for really sophisticated 3-d work, but being able to do the basic stuff with MPL would be wonderful. If the framework supports it cleanly internally, it's much more likely that the 3-d stuff will get written. > This is potentially a major win, because we currently > move the data around on every draw. Is it that expensive to push data around? In any case, it does sound cleaner and more efficient not to. > Do we want to use 3x3 or 4x4 to leave the door open for 3D developers? 4X4 -- is there much cost? > This approach requires the backends to be smarter, but they have to > handle fewer entities. How many back-ends does the future hold? It seems if the GUI toolkits all use *Agg, then that's only one render for all of them. Then we need: SVG PDF PS ??? Cairo would be nice, as it gives us almost all of them at once, but I guess licensing keeps that a non-starter. Oh well. > In matplotlib, the plot functions are matplotlib.axes.Axes methods and > I think there is consensus that this is a poor design. Well, the OO interface has always felt a bit clunky to me, but I'm not sure where else plot functions could go -- I'd love to hear ideas, though. > Do we want to create high level objects like Circle, Rectangle and > Line, each of which manage a Path object under the hood? I like that idea -- working with Paths should be saved for the gurus. > Just having the right Path object > will reduce the need for many of these, eg LineCollection, > PolygonCollection, etc... sounds good. > Also, everything should be numpy enabled, > and the sequence-of-python-tuples approach that many of the > collections take should be dropped. who hoo! However, numpy doesn't handle "ragged" arrays well. I wonder if there's a good way to implement those, so that transforms can be done numpy-efficient. > = Extension code = > > If we can enhance the > SWIG agg wrapper, we can also do images through there, getting rid of > _image.cpp. Having a fully featured, python-exposed agg wrapper will > be a plus in mpl and beyond. Very nice. > But with the agg license change, I'm > open to discussion of other approaches. hmm GPL now. Well, maybe Cairo's LGPL isn't so bad after all! > I want to do away with *all* GUI extension code. yeah! > = Traits = > I think we should make a major committment to traits and use them from > the ground up. Good plan. > = Breakage = > > I think we need to be prepared to break the hell out of matplotlib. > The API will basically be a significant rewrite. Well worth it. > pylab will still > mostly work unchanged -- that is the beauty of pylab As a rule for the future though, a stable OO interface would be nice. > Or we could forget all this wild speculation and resume our normally > scheduled lives. no!! > = Chaco and Kiva = > > It is a good idea for an enterprising developer to take a careful look > at the current Chaco and Kiva OK. I have to ask -- why aren't we all just using Chaco? I know I'm not because ??years ago, Enthought was not really supporting anything but Windows -- is that still true? Would it be a whole lot less work to support GTK, OS-X, ??? in Chaco than keep developing a separate lib? Great conversation starters! -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [EMAIL PROTECTED] ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
