matplotlib-devel Mailing List for matplotlib (Page 4)

John,
This should now be fixed in the svn, although I haven't actually
tested it in solaris machine.
Please check if this works.
-JJ
On Wed, Jun 3, 2009 at 4:01 PM, Jae-Joon Lee<lee...@gm...> wrote:
> On Wed, Jun 3, 2009 at 11:22 AM, John Hunter <jd...@gm...> wrote:
>> so we may want to special case the code to handle 0.0, 0.0 as inputs.
>
> Thanks a lot for tracking this down!
> It would be best if my algorithm does not produce such a case, but
> evidently it does. Yes, I'll put some code to treat this special case
> and also see if I can avoid such cases by improving my algorithm.
>
> Thanks again.
>
> -JJ
>

On Wed, Jun 3, 2009 at 11:22 AM, John Hunter <jd...@gm...> wrote:
> so we may want to special case the code to handle 0.0, 0.0 as inputs.
Thanks a lot for tracking this down!
It would be best if my algorithm does not produce such a case, but
evidently it does. Yes, I'll put some code to treat this special case
and also see if I can avoid such cases by improving my algorithm.
Thanks again.
-JJ

On Wed, Jun 3, 2009 at 11:04 AM, Michael Droettboom <md...@st...> wrote:
> Jae-Joon,
>
> I just saw your curvelinear grid support fall into SVN. Very
> impressive! We actually may have a use for it here at Space Telescope
> for drawing "World Coordinate System (WCS)" plots.
>
Well, the WCS support is actually my whole motivation for this (I'm
also in astronomy).
> One quick question though -- it seems that this functionality is
> completely independent of the axes_grid stuff, which is primarily about
> layout out axes within a figure, correct? Is there a reason why it's
> part of the axes_grid toolkit that I'm missing?
>
Well, axes_grid is actually a byproduct of my effort to nicely
display FITS image with matplotlib. And I tend to put everything that
is not astronomy-specific into axes_grid toolkit, which may not be
such a good idea.
While one needs to use a custom Axes class (axes_grid.axislines.Axes)
to support the curvelinear grid, this part of the code can be easily
separated out. But I'm not sure if creating another mpl_toolkit
package is best way to do here. Any suggestion will be welcomed.
Regards,
-JJ
> Cheers,
> Mike
>
> --
> Michael Droettboom
> Science Software Branch
> Operations and Engineering Division
> Space Telescope Science Institute
> Operated by AURA for NASA
>
>
> ------------------------------------------------------------------------------
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On Wed, Jun 3, 2009 at 10:04 AM, Michael Droettboom <md...@st...> wrote:
> Jae-Joon,
>
> I just saw your curvelinear grid support fall into SVN. Very
> impressive! We actually may have a use for it here at Space Telescope
> for drawing "World Coordinate System (WCS)" plots.
I am getting an exception with a clean numpy/mpl build from svn HEAD>
This appears platform specific because I am only seeing it on my
solaris box at work, not on a linux box I am also testing on.
johnh@flag:axes_grid> uname -a
SunOS flag 5.10 Generic_118855-15 i86pc i386 i86pc
Here is the complete traceback:
Traceback (most recent call last):
 File "demo_curvelinear_grid.py", line 127, in ?
 plt.draw()
 File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/pyplot.py",
line 350, in draw
 get_current_fig_manager().canvas.draw()
 File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/backends/backend_tkagg.py",
line 215, in draw
 FigureCanvasAgg.draw(self)
 File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/backends/backend_agg.py",
line 314, in draw
 self.figure.draw(self.renderer)
 File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/artist.py",
line 46, in draw_wrapper
 draw(artist, renderer, *kl)
 File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/figure.py",
line 774, in draw
 for a in self.axes: a.draw(renderer)
 File "/home/titan/johnh/dev/lib/python2.4/site-packages/mpl_toolkits/axes_grid/axislines.py",
line 1350, in draw
 super(Axes, self).draw(renderer, inframe)
 File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/artist.py",
line 46, in draw_wrapper
 draw(artist, renderer, *kl)
 File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/axes.py",
line 1826, in draw
 a.draw(renderer)
 File "/home/titan/johnh/dev/lib/python2.4/site-packages/mpl_toolkits/axes_grid/axislines.py",
line 874, in draw
 self._grid_helper.update_lim(self.axes)
 File "/home/titan/johnh/dev/lib/python2.4/site-packages/mpl_toolkits/axes_grid/axislines.py",
line 564, in update_lim
 self._update(x1, x2, y1, y2)
 File "/home/titan/johnh/dev/lib/python2.4/site-packages/mpl_toolkits/axes_grid/grid_helper_curvelinear.py",
line 114, in _update
 self._update_grid(x1, y1, x2, y2)
 File "/home/titan/johnh/dev/lib/python2.4/site-packages/mpl_toolkits/axes_grid/grid_helper_curvelinear.py",
line 149, in _update_grid
 self.grid_info = self.grid_finder.get_grid_info(x1, y1, x2, y2)
 File "/home/titan/johnh/dev/lib/python2.4/site-packages/mpl_toolkits/axes_grid/grid_finder.py",
line 241, in get_grid_info
 x1, y1, x2, y2)
 File "/home/titan/johnh/dev/lib/python2.4/site-packages/mpl_toolkits/axes_grid/grid_finder.py",
line 118, in get_grid_info
 bb)
 File "/home/titan/johnh/dev/lib/python2.4/site-packages/mpl_toolkits/axes_grid/grid_finder.py",
line 163, in _clip_grid_lines_and_find_ticks
 xy, tcks = clip_line_to_rect(lx, ly, bb)
 File "/home/titan/johnh/dev/lib/python2.4/site-packages/mpl_toolkits/axes_grid/clip_path.py",
line 72, in clip_line_to_rect
 ly3, lx3, c_top_ = clip(ly2, lx2, y1, clip="right")
 File "/home/titan/johnh/dev/lib/python2.4/site-packages/mpl_toolkits/axes_grid/clip_path.py",
line 51, in clip
 a = degrees(atan2(dy, dx))
ValueError: math domain error
In the debugger:
In [3]: %debug
> /home/titan/johnh/dev/lib/python2.4/site-packages/mpl_toolkits/axes_grid/clip_path.py(51)clip()
 50
---> 51 a = degrees(atan2(dy, dx))
 52 _pos_angles.append((x0, y0, a))
ipdb> print dy, dx
-0 0.0
ipdb> print type(dy), type(dx)
<type 'numpy.float64'> <type 'numpy.float64'>
ipdb> print atan2(dy, dx)
*** ValueError: math domain error
The root cause seems to be the math.atan2 function on solaris
In [4]: import math
In [5]: math.atan2(0., 0.)
------------------------------------------------------------
Traceback (most recent call last):
 File "<ipython console>", line 1, in ?
ValueError: math domain error
so we may want to special case the code to handle 0.0, 0.0 as inputs.
JDH

Jae-Joon,
I just saw your curvelinear grid support fall into SVN. Very 
impressive! We actually may have a use for it here at Space Telescope 
for drawing "World Coordinate System (WCS)" plots.
One quick question though -- it seems that this functionality is 
completely independent of the axes_grid stuff, which is primarily about 
layout out axes within a figure, correct? Is there a reason why it's 
part of the axes_grid toolkit that I'm missing?
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Tue, Jun 2, 2009 at 4:52 PM, Daniel <no...@dr...> wrote:
> Hello All,
>
> I have attached a patch that updates backend_fltkagg.py to use the new
> Transform APIs for 0.98.0
> (http://matplotlib.sourceforge.net/api/api_changes.html#notes-about-the-transforms-refactoring).
> Without these changes, trying to use FLTKAgg causes a crash with a very
> cryptic error.
>
> Thanks for all your work on matplotlib!
Thanks Daniel for the patch -- it looks like Michael has committed
this to the 98 release branch and merged it into the trunk, so it will
make the next release.
JDH

Hi again,
I have just installed matplotlib 0.98.5.3 and the problem seems to have
been fixed. But the movements are a lot slower though, (probably because
a lot more paint events were added?).
Thanks for the help.
-----Original Message-----
From: mat...@gm... [mailto:mat...@gm...] On Behalf Of
Sandro Tosi
Sent: Wednesday, June 03, 2009 12:35 PM
To: Alberto Soto; matplotlib development list
Subject: Re: [matplotlib-devel] re-draw problem with FigureCanvasQTAgg
in backend_qt4agg
Please keep the list in the loop: adding it again.
On Wed, Jun 3, 2009 at 12:16, Alberto Soto <alb...@lm...>
wrote:
> Hi Sandro,
>
> I have
> $ python -c "import matplotlib as mpl ; print mpl.__version__"
> 0.98.5.2
> Installed and am running PyQt v4.4.3 because I am forced to rest on
> Python 2.5
>
> I will try installing 0.98.5.3 and see if that makes a difference.
> I have seen the same problem in a Unix installation, I will try and
see
> which matplotlib version they were running.
>
> Meanwhile can you try re-sizing the dock widgets as fast as possible?
If
> you use the mouse to re-size them but do it gradually, the problem
does
> not surface.
oh sorry, the *dock*... I understood to resize the window. :(
Resizing the dock panel I see "part" of the problem": I see the
"shadow" on the matplotlib widget but not on the right dock (I'm
unable to screenshot though).
> Thank you and I will see what happened with the new instalation
You're welcome
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

Hi Sandro,
I have 
$ python -c "import matplotlib as mpl ; print mpl.__version__"
0.98.5.2 
Installed and am running PyQt v4.4.3 because I am forced to rest on
Python 2.5
I will try installing 0.98.5.3 and see if that makes a difference.
I have seen the same problem in a Unix installation, I will try and see
which matplotlib version they were running.
Meanwhile can you try re-sizing the dock widgets as fast as possible? If
you use the mouse to re-size them but do it gradually, the problem does
not surface.
Thank you and I will see what happened with the new instalation
-----Original Message-----
From: mat...@gm... [mailto:mat...@gm...] On Behalf Of
Sandro Tosi
Sent: Wednesday, June 03, 2009 11:44 AM
To: Alberto Soto
Cc: mat...@li...
Subject: Re: [matplotlib-devel] re-draw problem with FigureCanvasQTAgg
in backend_qt4agg
Hi Alberto,
On Wed, Jun 3, 2009 at 10:49, Alberto Soto <alb...@lm...>
wrote:
> Good afternoon,
>
> I am working on a GUI that utilizes the FigureCanvasQTAgg. The GUI
consists
> of a Qt main window were the central widget includes a Figure. The
problem
> arises when this central widget interacts with re-size events of my
dock
> widgets. The Plot is not correctly re-drawn, it 'leaks' into the dock
> widgets.
>
> I think a picture would better describe this problem:
>
> Here we see 2 scripts running, the 1st one's dock widgets have been
re-sized
> by the user and the plot has 'leaked' into the right side dialog. The
second
> picture shows how the dialog normally looks.
>
>
>
> I am also attaching a simple script with the GUI that has the problem.
>
> If I move or do anything to re-trigger a paint event the plot is
re-drawn
> correctly.
I see no problem here. I'm on a debian sid OS, with
$ python -c "import matplotlib as mpl ; print mpl.__version__"
0.98.5.3
and
$ apt-show-versions python-qt4
python-qt4/testing uptodate 4.4.4-6
what do you have installed?
Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

Please keep the list in the loop: adding it again.
On Wed, Jun 3, 2009 at 12:16, Alberto Soto <alb...@lm...> wrote:
> Hi Sandro,
>
> I have
> $ python -c "import matplotlib as mpl ; print mpl.__version__"
> 0.98.5.2
> Installed and am running PyQt v4.4.3 because I am forced to rest on
> Python 2.5
>
> I will try installing 0.98.5.3 and see if that makes a difference.
> I have seen the same problem in a Unix installation, I will try and see
> which matplotlib version they were running.
>
> Meanwhile can you try re-sizing the dock widgets as fast as possible? If
> you use the mouse to re-size them but do it gradually, the problem does
> not surface.
oh sorry, the *dock*... I understood to resize the window. :(
Resizing the dock panel I see "part" of the problem": I see the
"shadow" on the matplotlib widget but not on the right dock (I'm
unable to screenshot though).
> Thank you and I will see what happened with the new instalation
You're welcome
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

Hi Alberto,
On Wed, Jun 3, 2009 at 10:49, Alberto Soto <alb...@lm...> wrote:
> Good afternoon,
>
> I am working on a GUI that utilizes the FigureCanvasQTAgg. The GUI consists
> of a Qt main window were the central widget includes a Figure. The problem
> arises when this central widget interacts with re-size events of my dock
> widgets. The Plot is not correctly re-drawn, it ‘leaks’ into the dock
> widgets.
>
> I think a picture would better describe this problem:
>
> Here we see 2 scripts running, the 1st one’s dock widgets have been re-sized
> by the user and the plot has ‘leaked’ into the right side dialog. The second
> picture shows how the dialog normally looks.
>
>
>
> I am also attaching a simple script with the GUI that has the problem.
>
> If I move or do anything to re-trigger a paint event the plot is re-drawn
> correctly.
I see no problem here. I'm on a debian sid OS, with
$ python -c "import matplotlib as mpl ; print mpl.__version__"
0.98.5.3
and
$ apt-show-versions python-qt4
python-qt4/testing uptodate 4.4.4-6
what do you have installed?
Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

Hi Tom,
This is the right place to ask.
I'm working on putting some documentation together and I'll also look
into getting Text3D supported again. I hope to push things to svn next
weekend...
Regards,
Reinier
On Tue, Jun 2, 2009 at 6:49 AM, Tom Loredo <lo...@as...> wrote:
>
> 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
-- 
Reinier Heeres
Bleijenburg 64
2511 VD Den Haag
The Netherlands
Tel: +31 6 10852639

Hello All,
I have attached a patch that updates backend_fltkagg.py to use the new
Transform APIs for 0.98.0 (
http://matplotlib.sourceforge.net/api/api_changes.html#notes-about-the-transforms-refactoring).
Without these changes, trying to use FLTKAgg causes a crash with a very
cryptic error.
Thanks for all your work on matplotlib!
Daniel

On Tue, Jun 2, 2009 at 7:59 AM, Charlie Moad <cw...@gm...> wrote:
> I can't say that I have them. Petr, you can use 98.5.3 binaries found
> here, "http://drop.io/tvuqe3o". Just keep in mind that png operations
> will fail.
I've done some digging on this -- the segfault is happening in
_png.cpp on the line
 png_write_info(png_ptr, info_ptr);
and the error is
 Unhandled exception at 0x7c91b1fa in python.exe: 0xC0000005: Access
violation writing location 0x00000010.
when I paste this part of the message into google "python.exe:
0xC0000005: Access violation writing location 0x00000010" I find all
kinds of matches. Eg, this page
 http://stackoverflow.com/questions/391917/jpeg-support-with-ijg-getting-access-violation
suggests that there could be a problem in trying to pass FILE *
pointers to shared libraries. It seems we've done what is necessary
to compile these statically, but I'm just throwing this out there in
case it stimulates some ideas. I'm stuck so far in trying to fix
this.
JDH

I can't say that I have them. Petr, you can use 98.5.3 binaries found
here, "http://drop.io/tvuqe3o". Just keep in mind that png operations
will fail.
On Sat, May 30, 2009 at 2:14 PM, John Hunter <jd...@gm...> wrote:
> On Fri, May 29, 2009 at 9:44 PM, Petr Marhoun <pet...@gm...> wrote:
>> Hello,
>>
>> Few days ago there were new windows binaries on Sourceforge - version
>> 0.98.5.3. Yesterday I also found them in Google cache (see the
>> attachment - I am interested mainly in Python 2.6).
>>
>> But they are not now on Sourceforge. Is there a good reason for it
>> (for example there could be problematic)? Or is it a Sourceforge
>> mistake (I am not sure but I think that design of the Sourceforge
>> download page was different)?
>>
>> Maybe there is another explanation - but if it is possible, could
>> windows binaries be uploaded again?
>
> The 0.98.5.3 binaries have a problem with the PNG output, so I pulled
> them. Charile, do you still have the 0.98.5.2 win32 binaries to
> reupload while we are sorting out this problem?
>
> JDH
>

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

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/

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

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

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 <jd...@gm...> 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.

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
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> 
> 

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
> Mat...@li...
> 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