[matplotlib-devel] Tutorial topics for SciPy'09 Conference

2009-06-01 Thread Fernando Perez
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

[matplotlib-devel] mplot3d - text3D replacement?

2009-06-01 Thread Tom Loredo
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.t

Re: [matplotlib-devel] arbitrary spine locations in svn trunk

2009-06-01 Thread Andrew Straw
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 ba

Re: [matplotlib-devel] arbitrary spine locations in svn trunk

2009-06-01 Thread Eric Firing
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

Re: [matplotlib-devel] arbitrary spine locations in svn trunk

2009-06-01 Thread Andrew Straw
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

Re: [matplotlib-devel] gtk versions: drop support for less than 2.4?

2009-06-01 Thread Eric Firing
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 r

Re: [matplotlib-devel] gtk versions: drop support for less than 2.4?

2009-06-01 Thread Michael Droettboom
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 e