matplotlib-devel Mailing List for matplotlib

I did. But there's no manual, and the 'under construction'
placeholders in the 'how do I?' and tutorial didn't give a great first
impression. I see now there's a link to some example code, but it's a
lot more intimidating than the matplotlib introductory stuff.
>
> Did you find http://code.enthought.com/chaco/ ?
>
> Not that we are trying to drive you away <wink>, we'd love to have you
> stay. As I mentioned in my earlier post, when we migrate to traits
> for matplotlib artist properties, we will get a pretty rich
> interactive UI configuration layer.
>
> JDH
>

On Wed, Feb 13, 2008 at 11:04:13AM -0500, Paul Kienzle wrote:
> Is there anybody outside of enthought who are deploying applications
> based on TraitsUI for Windows/Mac/Linux? I would love to hear about 
> successful examples before committing to more dependencies in our own 
> applications.
I, in the lab. People at Airbus research labs (Bristol, UK), people at
Estimages (http://www.estimages.com/), people at jgeophysics, and quite a
few other researchers, for in house applications in labs (just have a
look at the enthought-dev mailing list. Airbus have actually paying a
former Enthought employee (Martin Chilvers) to develop Envisage3, and
have payed Phil Thompson (author of PyQT) to do the QT backend. This
backend is working now quite well as they are using it for their 
day-to-day work.
> A specific concern we had when investigating Traits a couple of
> years ago was long start up times.
I don't really think this has improved a lot. You would have to try it
out to see. However my experience is that if you are not loading Wx,
traits by itself is fast, if you are loading Wx, you are limited by the
cost of loading Wx. I may be wrong, as I have no hard numbers.
> The lack of clear boundaries between traits and other parts of
> enthought was a further concern, since it would make deployment more
> difficult.
That's pretty much solved. The Enthought Tool Suite has been split in
projects, each of them that can be further split in packages (just a look
at their SVN structure will tell you exactly how it is done:
https://svn.enthought.com/enthought/browser ).
Cheers,
Gaël

On Feb 13, 2008 10:04 AM, Paul Kienzle <pki...@ni...> wrote:
> On Wed, Feb 13, 2008 at 08:24:35AM -0600, John Hunter wrote:
> > As I mentioned in my earlier post, when we migrate to traits
> > for matplotlib artist properties, we will get a pretty rich
> > interactive UI configuration layer.
>
> Any sense of when this might happen?
There is no specific timeline, but Darren did a bunch of the hard work
getting a traits enabled rc configuration option (off by default) in
0.91.2. The plan is to turn get this turned on by default in the next
release of the trunk (0.98) so we can get as much pain in at once
rather than in doses. Since migrating apps to the trunk requires some
changes in the API (transformations, bounding boxes) already, this
would probably be a good time to migrate the rc configuration too.
> Is there anybody outside of enthought who are deploying applications
> based on TraitsUI for Windows/Mac/Linux? I would love to hear about
> successful examples before committing to more dependencies in our own
> applications.
Well, we are already installing enthought.traits and have not
experienced any significant user problems, so I don't think we will be
introducing a significant dependency here. This can be done so that
users who have a UI enabled traits will get the UI benefits and those
who don't will get the basic traits benefits minus the UI. So we
wouldn't need to depend on the UI components, and we have already
(mostly) solved the dependency problem on the non UI component (see
matplotlib/lib/enthought).
I say mostly because there is a problem that Gael first reported
recently that having our enthought traits installed ahead of
enthought's version can break some enthought apps, so we need to
address this. And yes, there are some startup time problems with a
namespace enabled version of enthought's packages that have caused
some concern.
> What's going to happen with Qt/Gtk/Tkinter backends? We are already
> using wx so this isn't an issue for us, but last time I looked TraitsUI
> only had wx support.
As far as I understand, there is a fully featured wx version and qt is
coming along nicely. Again, matplotlib would continue to work as
before with the other UI backends, your just wouldn't get the traits
dialogs.
> A specific concern we had when investigating Traits a couple of
> years ago was long start up times. The lack of clear boundaries
> between traits and other parts of enthought was a further concern,
> since it would make deployment more difficult.
This is getting much better, but it is still a work in progress.
traits is now in debian, for example.
JDH

On Wed, Feb 13, 2008 at 08:24:35AM -0600, John Hunter wrote:
> As I mentioned in my earlier post, when we migrate to traits
> for matplotlib artist properties, we will get a pretty rich
> interactive UI configuration layer.
Any sense of when this might happen?
Is there anybody outside of enthought who are deploying applications
based on TraitsUI for Windows/Mac/Linux? I would love to hear about 
successful examples before committing to more dependencies in our own 
applications.
What's going to happen with Qt/Gtk/Tkinter backends? We are already
using wx so this isn't an issue for us, but last time I looked TraitsUI 
only had wx support.
A specific concern we had when investigating Traits a couple of
years ago was long start up times. The lack of clear boundaries 
between traits and other parts of enthought was a further concern,
since it would make deployment more difficult.
- Paul

On Feb 13, 2008 8:05 AM, Neil Crighton <nei...@gm...> wrote:
> Another big difference between matplotlib and chaco: matplotlib has
> online documentation, examples and tutorials. I couldn't find any
> documentation on Chaco when I was looking around for a python plotting
> program. If I had, who knows, maybe I'd be using Chaco now instead of
> matplotlib :)
Did you find http://code.enthought.com/chaco/ ?
Not that we are trying to drive you away <wink>, we'd love to have you
stay. As I mentioned in my earlier post, when we migrate to traits
for matplotlib artist properties, we will get a pretty rich
interactive UI configuration layer.
JDH

Another big difference between matplotlib and chaco: matplotlib has
online documentation, examples and tutorials. I couldn't find any
documentation on Chaco when I was looking around for a python plotting
program. If I had, who knows, maybe I'd be using Chaco now instead of
matplotlib :)

On Feb 12, 2008 10:31 PM, Erik Tollerud <eri...@gm...> wrote:
> While doing some further testing, I'm getting another bug in the svn
> code - whenever I try to right-click and drag to zoom out when using
> the toolbar, an Exception is raised complaining about an unbound
> local. I traced the problem to what appears to be a typo in
> backend_bases.py where someone must have renamed some variables and
> didn't go and change them further up or something. Changing the
> variable name in a couple places seems to make it all work on my
> setup. The diff is attached.
Good catch -- applied to r4959.
Thanks,
JDH

After a little testing on the subversion repository, the attached diff
seems to work.
On Feb 10, 2008 12:12 AM, Erik Tollerud <eri...@gm...> wrote:
> I noticed while making some plots with upper bound error bars that
> whenever Axes.errorbars is called with any of the errorbars chosen as
> upper or lower bounds, that the color cycle was off, skipping over 2
> colors each time another errorbar plot was made (e.g. the first would
> be green and the second would be cyan instead of blue,green,red,cyan).
> Looking into the axes class, it appears that if you don't specify a
> color and want the markers to be drawn over the errorbars, the color
> cycle has already been skipped over one because of calls to draw the
> markers into the plot. The solution is to change all the lines that
> say " ls='None' " in the errorbar method to instead say " ls='k' " -
> this will prevent those calls from cycling the colors, and hence only
> the call to actually draw the markers will do so. Can this patch be
> committed to svn?
>
-- 
Erik Tollerud
Graduate Student
Center For Cosmology
Department of Physics and Astronomy
4155B Frederick Reines Hall
University of California, Irvine
Office Phone: (949)824-2996
Cell: (651)307-9409
eto...@uc...

While doing some further testing, I'm getting another bug in the svn
code - whenever I try to right-click and drag to zoom out when using
the toolbar, an Exception is raised complaining about an unbound
local. I traced the problem to what appears to be a typo in
backend_bases.py where someone must have renamed some variables and
didn't go and change them further up or something. Changing the
variable name in a couple places seems to make it all work on my
setup. The diff is attached.
On Feb 12, 2008 6:11 PM, John Hunter <jd...@gm...> wrote:
> On Feb 12, 2008 7:02 PM, Erik Tollerud <eto...@uc...> wrote:
> > You're absolutely correct - I wrote the original patch against 91.2,
> > and forgot to test it against the new trunk. Below is a new patch
> > that HAS been tested against the trunk version. It includes another
> > fix for some API changes in the Rectangle object. Note that there's
> > also a fix in the RectangleSelector to prevent it from raising an
> > exception under the new API.
>
> OK, thanks Erik, I committed this to the trunk as svn r4956. It seems
> to be working fine, so thanks for the patch. I'm not sure right now
> wha the problem is with useblit=False that you are experiencing, but
> if you make any headway on this let us know.
>
> JDH
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
-- 
Erik Tollerud
Graduate Student
Center For Cosmology
Department of Physics and Astronomy
4155B Frederick Reines Hall
University of California, Irvine
Office Phone: (949)824-2996
Cell: (651)307-9409
eto...@uc...

On Feb 12, 2008 7:02 PM, Erik Tollerud <eto...@uc...> wrote:
> You're absolutely correct - I wrote the original patch against 91.2,
> and forgot to test it against the new trunk. Below is a new patch
> that HAS been tested against the trunk version. It includes another
> fix for some API changes in the Rectangle object. Note that there's
> also a fix in the RectangleSelector to prevent it from raising an
> exception under the new API.
OK, thanks Erik, I committed this to the trunk as svn r4956. It seems
to be working fine, so thanks for the patch. I'm not sure right now
wha the problem is with useblit=False that you are experiencing, but
if you make any headway on this let us know.
JDH

You're absolutely correct - I wrote the original patch against 91.2,
and forgot to test it against the new trunk. Below is a new patch
that HAS been tested against the trunk version. It includes another
fix for some API changes in the Rectangle object. Note that there's
also a fix in the RectangleSelector to prevent it from raising an
exception under the new API.
I've also noticed that both the SpanSelector and RectangleSelector
don't seem to draw the rectangle with useblit=False on my machine -
I'm only using useblit=True, though, and it works fine there with the
alterations in this patch.
Index: widgets.py
===================================================================
--- widgets.py	(revision 4953)
+++ widgets.py	(working copy)
@@ -827,16 +827,14 @@
 assert direction in ['horizontal', 'vertical'], 'Must choose
horizontal or vertical for direction'
 self.direction = direction
- self.ax = ax
+ self.ax = None
+ self.canvas = None
 self.visible = True
- self.canvas = ax.figure.canvas
- self.canvas.mpl_connect('motion_notify_event', self.onmove)
- self.canvas.mpl_connect('button_press_event', self.press)
- self.canvas.mpl_connect('button_release_event', self.release)
- self.canvas.mpl_connect('draw_event', self.update_background)
+ self.cids=[]
 self.rect = None
 self.background = None
+ self.pressv = None
 self.rectprops = rectprops
 self.onselect = onselect
@@ -847,8 +845,23 @@
 # Needed when dragging out of axes
 self.buttonDown = False
 self.prev = (0, 0)
-
- if self.direction == 'horizontal':
+
+ self.new_axes(ax)
+
+
+ def new_axes(self,ax):
+ self.ax = ax
+ if self.canvas is not ax.figure.canvas:
+ for cid in self.cids:
+ self.canvas.mpl_disconnect(cid)
+
+ self.canvas = ax.figure.canvas
+
+ self.cids.append(self.canvas.mpl_connect('motion_notify_event',
self.onmove))
+ self.cids.append(self.canvas.mpl_connect('button_press_event',
self.press))
+	 self.cids.append(self.canvas.mpl_connect('button_release_event',
self.release))
+	 self.cids.append(self.canvas.mpl_connect('draw_event',
self.update_background))
+	if self.direction == 'horizontal':
 trans = blended_transform_factory(self.ax.transData,
self.ax.transAxes)
 w,h = 0,1
 else:
@@ -859,9 +872,8 @@
 visible=False,
 **self.rectprops
 )
-
+
 if not self.useblit: self.ax.add_patch(self.rect)
- self.pressv = None
 def update_background(self, event):
 'force an update of the background'
@@ -931,10 +943,10 @@
 minv, maxv = v, self.pressv
 if minv>maxv: minv, maxv = maxv, minv
 if self.direction == 'horizontal':
- self.rect.xy[0] = minv
+ self.rect.set_x(minv)
 self.rect.set_width(maxv-minv)
 else:
- self.rect.xy[1] = minv
+ self.rect.set_y(minv)
 self.rect.set_height(maxv-minv)
 if self.onmove_callback is not None:
@@ -1155,8 +1167,8 @@
 miny, maxy = self.eventpress.ydata, y # click-y and actual mouse-y
 if minx>maxx: minx, maxx = maxx, minx # get them in the right order
 if miny>maxy: miny, maxy = maxy, miny
- self.to_draw.xy[0] = minx # set lower left of box
- self.to_draw.xy[1] = miny
+ self.to_draw.set_x(minx) # set lower left of box
+ self.to_draw.set_y(miny)
 self.to_draw.set_width(maxx-minx) # set width and height of box
 self.to_draw.set_height(maxy-miny)
 self.update()
On Feb 11, 2008 7:48 AM, John Hunter <jd...@gm...> wrote:
> On Feb 10, 2008 5:12 PM, Erik Tollerud <eri...@gm...> wrote:
> > I've been working on an application that uses matplotlib as its
> > plotting library, and I've been noticing a steady decrease in
>
> It looks like there is some confusion in your patch vis-a-vis the
> migration from the old matplotlib transformation architecture (no on a
> branch) to the new (now in the trunk). I'm attaching the migration
> document. For example, your patch removes
> blended_transform_factory lines (new transforms call on the trunk) and
> adds blend_xy_sep_transform lines (old transforms call on the 0.91
> maintenance branch).
>
> You can patch either the maintenance branch or the trunk or both, but
> I think the patch as submitted is a little mixed up if I am reading
> this correctly.
>
> JDH
>
-- 
Erik Tollerud
Graduate Student
Center For Cosmology
Department of Physics and Astronomy
4155B Frederick Reines Hall
University of California, Irvine
Office Phone: (949)824-2996
Cell: (651)307-9409
eto...@uc...