Re: [matplotlib-devel] gtk versions: drop support for less than 2.4?
I'm +1 on dropping support for gtk+ < 2.4 (if even later). Those multiple code paths were a pain, and installing multiple versions of gtk+ for testing is also something I'd like to stop doing. Cheers, Mike Eric Firing wrote: > We still require only gtk 2.2, and consequently carry around some extra > chunks of code to support versions before 2.4. Can we drop this and > require 2.4 or later? Or possibly even a later version? It looks like > 2.4 came out in the fall of 2004. > > Eric > > -- > Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT > is a gathering of tech-side developers & brand creativity professionals. Meet > the minds behind Google Creative Lab, Visual Complexity, Processing, & > iPhoneDevCamp as they present alongside digital heavyweights like Barbarian > Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com > ___ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] gtk versions: drop support for less than 2.4?
Michael Droettboom wrote: > I'm +1 on dropping support for gtk+ < 2.4 (if even later). Those > multiple code paths were a pain, and installing multiple versions of > gtk+ for testing is also something I'd like to stop doing. > > Cheers, > Mike Done. Eric > > Eric Firing wrote: >> We still require only gtk 2.2, and consequently carry around some >> extra chunks of code to support versions before 2.4. Can we drop this >> and require 2.4 or later? Or possibly even a later version? It looks >> like 2.4 came out in the fall of 2004. >> >> Eric >> >> -- >> >> >> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT >> is a gathering of tech-side developers & brand creativity >> professionals. Meet >> the minds behind Google Creative Lab, Visual Complexity, Processing, & >> iPhoneDevCamp as they present alongside digital heavyweights like >> Barbarian Group, R/GA, & Big Spaceship. >> http://p.sf.net/sfu/creativitycat-com >> ___ >> Matplotlib-devel mailing list >> Matplotlib-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> > -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] arbitrary spine locations in svn trunk
Thanks everyone for the feedback. I have made Spine subclass Patch in svn r7170, which I just committed. This resulted in a slight API change, but addresses most of the more substantial points raised. The slight API change is that spine.set_color() is now spine.set_edgecolor(). More below. > On Thu, May 28, 2009 at 9:18 PM, John Hunter wrote: >> You do an isinstance(arg, basestring) to check for string input. >> Typically, we encourage cbook.is_string_like to have a central point >> of maintenance and consistency for these checks. fixed in r7169 >> Also, in the example, you appear to turn off a spine by setting the >> color to 'none'. My thought it would be more natural to use the >> "visible" artist property here (or at least support both) I think this is addressed naturally by the new "Spine is a Patch" behavior. >> Also, I think the class of strings representing "no color" in mpl is >> larger -- it should also include self.color.lower()=='none' and the >> empty string, which I've included in the example code. Same for this. Now there's a single point of failure in the Patch.draw() method. Jae-Joon Lee wrote: > The zorder of the spine artists is set to 0 by default. > I notice that you're changing the zorder of its artist attribute, but > note that it has no effect as what matter is the zorder of the spine > itself. Again, I think this is dealt with by the "Spine is a Patch" patch. > As a related issue to what John mentioned, I think one option you can > do is to derive the Spine class itself from a real artist class, > rather than the base "Artist". With this, you don't need to implement > all other set/get method, e.g., color, etc. For example, you may > derive it from the Patch class. Note that while the Patch class is > intended for closed path, you can stroke a straight line with it. Good idea -- done! :) > * cla() does not reset spines (positions, color, etc). I think it is > better to be reset, since all other things are. For example, cla() > resets visibility of ticks, etc. Nice catch. Fixed in r7168. > * better support for log scale. I see the issue here, but I haven't had a chance to fix it. To be honest, I'm surprised there aren't more of these types of issues... You're welcome to take a look if you're so inclined -- it'll probably be a few days before I have a chance to look at it. -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] arbitrary spine locations in svn trunk
Andrew Straw wrote: > Thanks everyone for the feedback. I have made Spine subclass Patch in > svn r7170, which I just committed. This resulted in a slight API > change, but addresses most of the more substantial points raised. > > The slight API change is that spine.set_color() is now > spine.set_edgecolor(). But spine.set_color() is much more natural and easy to remember, so maybe it can be restored: Collections have had a set_color() for a long time, and I don't see any reason Patch shouldn't have the same, so I added it. My first thought was that this would have no effect on spines except to permit the alternative and more natural "spine.set_color()" to work like set_edgecolor, but now I see that this is not true--in the case of a circular spine, calling set_color(c) would have the unintended effect of filling the circle. I still think having the set_color method in Patch and Spine is good, so what I propose is that Spine override the Patch version with a simple alias to set_edgecolor. Eric -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] arbitrary spine locations in svn trunk
Eric Firing wrote: > Andrew Straw wrote: >> The slight API change is that spine.set_color() is now >> spine.set_edgecolor(). > > But spine.set_color() is much more natural and easy to remember, so > maybe it can be restored: Good idea. I just re-added Spine.set_color() and changed the example back. -Andrew -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] mplot3d - text3D replacement?
Hi- I'm sorry if this should be in mpl-users; since mplot3d is a work in progress and not documented I thought the question might better fit mpl-devel. I'm trying to migrate some old code that used matplotlib.axes3d to use mpl_toolkits.mplot3d.axes3d. For an axes3d instance ax, it used the ax.text3D method to place labels on the 3-D axes. Is there a counterpart for mplot3d.axes3d? The only similar method I see there is text(), which only takes an (x, y) position instead of an (x,y,z) position. Thanks, Tom - This mail sent through IMP: http://horde.org/imp/ -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Tutorial topics for SciPy'09 Conference
Hi all, The time for the Scipy'09 conference is rapidly approaching, and we would like to both announce the plan for tutorials and solicit feedback from everyone on topics of interest. Broadly speaking, the plan is something along the lines of what we had last year: one continuous 2-day tutorial aimed at introductory users, starting from the very basics, and in parallel a set of 'advanced' tutorials, consisting of a series of 2-hour sessions on specific topics. We will request that the presenters for the advanced tutorials keep the 'tutorial' word very much in mind, so that the sessions really contain hands-on learning work and not simply a 2-hour long slide presentation. We will thus require that all the tutorials will be based on tools that the attendees can install at least 2 weeks in advance on all platforms (no "I released it last night" software). With that in mind, we'd like feedback from all of you on possible topics for the advanced tutorials. We have space for 8 slots total, and here are in no particular order some possible topics. At this point there are no guarantees yet that we can get presentations for these, but we'd like to establish a first list of preferred topics to try and secure the presentations as soon as possible. This is simply a list of candiate topics that various people have informally suggested so far: - Mayavi/TVTK - Advanced topics in matplotlib - Statistics with Scipy - The TimeSeries scikit - Designing scientific interfaces with Traits - Advanced numpy - Sparse Linear Algebra with Scipy - Structured and record arrays in numpy - Cython - Sage - general tutorial - Sage - specific topics, suggestions welcome - Using GPUs with PyCUDA - Testing strategies for scientific codes - Parallel processing and mpi4py - Graph theory with Networkx - Design patterns for efficient iterator-based scientific codes. - Symbolic computing with sympy We'd like to hear from any ideas on other possible topics of interest, and we'll then run a doodle poll to gather quantitative feedback with the final list of candidates. Many thanks, f -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
