Re: [matplotlib-devel] [Matplotlib-users] eggs or pythonmac packages on OS X?
At 10:03 AM -0800 2007-12-05, Christopher Barker wrote: >Russell E Owen wrote: >>At 10:08 AM -0500 2007-12-05, Stephen Uhlhorn wrote: >>>Just for my edification, why can't the egg version be linked >>>against/include a different Tcl/Tk? >> >>If you mean why can't it be built that way in the first place, I >>don't know. The guy who builds it apparently doesn't read this list, > >Sure he does (if you mean the matplotlib list), and he did ask about >it right before this release. Maybe that was asked on >matplotlib-devel though (I filter them to the same place). It was on matploblib-devel. I'll start skimming that newsgroup. >>I suspect the official egg can somehow be patched, but I find it >>easier to just build my own and put that on pythonmac. > >Ideally, there would be only one binary version, and it would work >with either Tcl/Tk. Is that possible? or is this like the old wx >situation, where it can only be run with the same version it is >built against. Arrggg! I hope not. The version I build *can* be used with the built in Tcl/Tk. The version Charlie Moad builds cannot be used with TkAgg and a 3rd party Tcl/Tk -- it not only won't use the library, but it also acts flaky. Older versions crashed. 0.91.1 doesn't crash, but import of pylab fails with a traceback. For some reason it seems to be necessary to have a 3rd party Tcl/Tk installed when building matplotlib. It seems a shame. Tkinter in Python 2.4 was the same way, but that got fixed in Python 2.5 (I don't whether the installer got fixed or whether whoever builds Mac Python 2.5 installed a 3rd party Tcl/Tk). >If there really do need to be two, then they should be labeled >somehow, and both be up on python mac. Since there don't need to be two versions this is not necessary. However, Charlie Moad appears to be willing to start building a version that works with 3rd party Tcl/Tk. I really hope that happens. -- Russell - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] canvas.print_svg()
I get this error when using canvas.print_svg(): In [27]: canvas.print_svg(buffer) --- Traceback (most recent call last) Z:\ in () C:\Python25\Lib\site-packages\matplotlib\backend_bases.py in print_svg(self, *ar gs, **kwargs) 1124 from backends.backend_svg import FigureCanvasSVG # lazy import 1125 svg = self.switch_backends(FigureCanvasSVG) -> 1126 return svg.print_svg(*args, **kwargs) 1127 1128 def print_svgz(self, *args, **kwargs): C:\Python25\Lib\site-packages\matplotlib\backends\backend_svg.py in print_svg(se lf, filename, *args, **kwargs) 463 if is_string_like(filename): 464 fh_to_close = svgwriter = codecs.open(filename, 'w', 'utf-8' ) --> 465 elif is_writable_file_like(filename): 466 svgwriter = codecs.EncodedFile(filename, 'utf-8') 467 fh_to_close = None C:\Python25\Lib\site-packages\matplotlib\cbook.py in is_writable_file_like(obj) 215 216 def is_writable_file_like(obj): --> 217 return hasattr(filename, 'write') and callable(filename.write) 218 219 def is_scalar(obj): : global name 'filename' is not defined In [28]: canvas Out[28]: It seems that def is_writable_file_like(obj): should be def is_writable_file_like(filename): - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] wx draw_idle
Hi,
The attached patch has a couple of changes to the wx backend that I
want people to test before I commit.
1) implement draw_idle. Rather than using the wx IdleEvent which seemed
to be triggered too often I used a timer which is delayed and possibly
reset if a new draw request comes within a certain time period (5 ms),
or if there are pending wx events. The scheme isn't perfect since wx
doesn't see all the native events, but it seems to work well enough.
2) Don't draw bitmap on the screen if the graph isn't shown. Otherwise
a plot inside of a wx aui notebook bleeds through even if the graph
notebook is not on top.
3) Don't regenerate entire plot for each PaintEvent. Instead, only
draw the graph if this is the first time the window is exposed, otherwise
work from the bitmap. I've only tested this for wxagg on the mac. I don't
know if it breaks wx, or if anyone cares about wx anymore.
Let me know if it works for you.
- Paul
Index: backend_wx.py
===
--- backend_wx.py (revision 4696)
+++ backend_wx.py (working copy)
@@ -753,6 +753,10 @@
self._isConfigured = False
self._printQued = []
+# Need to render the window properly if this is the first time
+# it is being shown since it has changed.
+self._isRendered = False
+
if wx.VERSION_STRING >= '2.5':
# Event handlers 2.5
self.Bind(wx.EVT_SIZE, self._onSize)
@@ -789,6 +793,13 @@
self.Printer_Init()
+# Create an timer for handling draw_idle requests
+# If there are events pending when the timer is
+# complete, reset the timer and continue. The
+# alternative approach, binding to wx.EVT_IDLE,
+# doesn't behave as nicely.
+self.idletimer = wx.CallLater(1,self._onDrawIdle)
+
def Destroy(self, *args, **kwargs):
wx.Panel.Destroy(self, *args, **kwargs)
@@ -943,17 +954,36 @@
self.gui_repaint()
-def draw(self, repaint=True):
+def draw_idle(self, *args, **kwargs):
"""
+Render after a delay if no other render requests have been made.
+"""
+DEBUG_MSG("draw_idle()", 1, self)
+self.idletimer.Restart(5, *args, **kwargs) # Delay by 5 ms
+
+def _onDrawIdle(self, *args, **kwargs):
+if False and wx.GetApp().Pending():
+self.idletimer.Restart(5, *args, **kwargs)
+else:
+self.draw(*args, **kwargs)
+
+def draw(self, drawDC=None):
+"""
Render the figure using RendererWx instance renderer, or using a
previously defined renderer if none is specified.
"""
DEBUG_MSG("draw()", 1, self)
-self.renderer = RendererWx(self.bitmap, self.figure.dpi)
-self.figure.draw(self.renderer)
-if repaint:
-self.gui_repaint()
+# Only draw if window is shown, otherwise graph will bleed through
+# on the notebook style AUI widgets.
+if self.IsShownOnScreen():
+self._isRendered = True
+self.renderer = RendererWx(self.bitmap, self.figure.dpi)
+self.figure.draw(self.renderer)
+self.gui_repaint(drawDC=drawDC)
+else:
+self._isRendered = False
+
def _get_imagesave_wildcards(self):
'return the wildcard string for the filesave dialog'
default_filetype = self.get_default_filetype()
@@ -1050,6 +1080,10 @@
# Restore everything to normal
self.bitmap = origBitmap
+# Note: draw is required here since bits of state about the
+# last renderer are strewn about the artist draw methods. Do
+# not remove the draw without first verifying that these have
+# been cleaned up.
self.draw()
self.Refresh()
@@ -1077,10 +,15 @@
DEBUG_MSG("_onPaint()", 1, self)
if not self._isRealized:
self.realize()
-# Render to the bitmap
-self.draw(repaint=False)
-# Update the display using a PaintDC
-self.gui_repaint(drawDC=wx.PaintDC(self))
+
+# Need to draw the graph the first time it is shown otherwise
+# it is a black canvas. After that we can use the rendered
+# bitmap for updates.
+if self._isRendered:
+self.gui_repaint(drawDC=wx.PaintDC(self))
+else:
+self.draw(drawDC=wx.PaintDC(self))
+
evt.Skip()
def _onSize(self, evt):
Index: backend_wxagg.py
===
--- backend_wxagg.py(revision 4696)
+++ backend_wxagg.py(working copy)
@@ -53,16 +53,21 @@
size.
"""
-def draw(self, repaint=True):
+def draw(self, drawDC=None):
"""
Render the figure using agg.
"""
DEBUG_MSG("draw()", 1, self)
-FigureCanvasAgg.draw(self)
-self.bitmap = _convert_agg_to_wx_b
Re: [matplotlib-devel] canvas.print_svg()
Thanks. This has already been fixed in SVN, and should make it into the 0.91.2 release shortly. Cheers, Mike Brandon Reno wrote: > I get this error when using canvas.print_svg(): > > In [27]: canvas.print_svg(buffer) > --- > Traceback (most recent call last) > > Z:\ in () > > C:\Python25\Lib\site-packages\matplotlib\backend_bases.py in > print_svg(self, *ar > gs, **kwargs) >1124 from backends.backend_svg import FigureCanvasSVG # lazy > import >1125 svg = self.switch_backends(FigureCanvasSVG) > -> 1126 return svg.print_svg(*args, **kwargs) >1127 >1128 def print_svgz(self, *args, **kwargs): > > C:\Python25\Lib\site-packages\matplotlib\backends\backend_svg.py in > print_svg(se > lf, filename, *args, **kwargs) > 463 if is_string_like(filename): > 464 fh_to_close = svgwriter = codecs.open(filename, 'w', > 'utf-8' > ) > --> 465 elif is_writable_file_like(filename): > 466 svgwriter = codecs.EncodedFile(filename, 'utf-8') > 467 fh_to_close = None > > C:\Python25\Lib\site-packages\matplotlib\cbook.py in > is_writable_file_like(obj) > 215 > 216 def is_writable_file_like(obj): > --> 217 return hasattr(filename, 'write') and callable(filename.write) > 218 > 219 def is_scalar(obj): > > : global name 'filename' is not defined > > In [28]: canvas > Out[28]: at 0x01CA > EDF0> > > It seems that > def is_writable_file_like(obj): > > should be > def is_writable_file_like(filename): > > > > > - > SF.Net email is sponsored by: > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > > > > > ___ > Matplotlib-devel mailing list > [email protected] > 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 - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] wx draw_idle
Paul Kienzle wrote: > 1) implement draw_idle. Rather than using the wx IdleEvent which seemed > to be triggered too often good idea -- the wx Idle event is triggered A LOT. I've never found a use for it. > I used a timer which is delayed and possibly > reset if a new draw request comes within a certain time period (5 ms), That's a common trick, and has always worked well for me. > or if there are pending wx events. The scheme isn't perfect since wx > doesn't see all the native events, but it seems to work well enough. I'm confused here -- what events are missed, and why? What do you mean by a "native" event? > 2) Don't draw bitmap on the screen if the graph isn't shown. Otherwise > a plot inside of a wx aui notebook bleeds through even if the graph > notebook is not on top. hmmm odd -- this does sound right, but shouldn't wx only be re-drawing in a Paint event anyway? > 3) Don't regenerate entire plot for each PaintEvent. Instead, only > draw the graph if this is the first time the window is exposed, otherwise > work from the bitmap. This is odd to me too -- I haven't dug into the wx back-end, but it seems the Paint Event should only trigger a blit of the bitmap to the screen anyway. > I've only tested this for wxagg on the mac. I don't > know if it breaks wx, or if anyone cares about wx anymore. You mean wx, rather then wxAgg? I now some folks have found it useful for remote X sessions -- but I don't know how important it is to support that. -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] - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] wx draw_idle
On Tue, Dec 11, 2007 at 10:22:12AM -0800, Christopher Barker wrote: > Paul Kienzle wrote: > > or if there are pending wx events. The scheme isn't perfect since wx > > doesn't see all the native events, but it seems to work well enough. > > I'm confused here -- what events are missed, and why? What do you mean > by a "native" event? Intermediate mouse positions, for example, seem to be consumed. Also, it doesn't seem to recognize pending resize events. Try an experiment such as resizing examples/pcolor_log.py, with N large enough to make redraws slow to see what I mean (N=200 does it for me). I tried changing the _onSize event handler to use draw_idle rather than draw to improve the resize experience but I shut it off because the drawing area turns black and I couldn't figure out how to set it to the figure background colour. It helped slow graphs a little since I could see what the resulting window would look like, but the black was jarring for quick graphs. Any thoughts on implementing preemptive plotting? This would mean putting tests like the following inside potentially expensive loops: if self.isabort(): break where isabort is a method in class artist which delegates to the canvas: return self.figure.canvas.isabort() if self.figure else False For the wx canvas, isabort() would be something like: wx.Yield() # Allow UI events to be processed return self._draw_idle_requested # abort drawing if UI triggered redraw > > 2) Don't draw bitmap on the screen if the graph isn't shown. Otherwise > > a plot inside of a wx aui notebook bleeds through even if the graph > > notebook is not on top. > > hmmm odd -- this does sound right, but shouldn't wx only be re-drawing > in a Paint event anyway? I haven't traced through the wx.aui code so I don't know what is going on. I do know that I have problems if I don't check IsWindowShown before blitting the bitmap onto the screen. > > 3) Don't regenerate entire plot for each PaintEvent. Instead, only > > draw the graph if this is the first time the window is exposed, otherwise > > work from the bitmap. > > This is odd to me too -- I haven't dug into the wx back-end, but it > seems the Paint Event should only trigger a blit of the bitmap to the > screen anyway. It should, but the bitmap may not be initialized when the paint event occurs. This happens when the window is first created (since there is no associated size event) and now when switching aui notebook windows (since I don't render the bitmap if the window isn't shown). - Paul - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Problem with Agg Ellipses
I have a working draft of something that may work for this problem on the transforms branch. I am happy to backport this to the trunk, but that will require some effort, as the implementation relies on many of the new geometric utilities on the branch that would also have to be brought over. It may be some time until the branch is ready for production use, but if you are able to use it to experiment with this approach to this specific problem, that would certainly make my life easier, so I don't have to do the backporting work more than once. Attached is a plot comparing the new approach (above) vs. a 750-edge polygonal approximation for the ellipses (based directly on James Evans' example). Here's a description of what it does: Ellipses are normally drawn using an approximation that uses eight cubic bezier splines. The error of this approximation is 1.89818e-6, according to this unverified source: Lancaster, Don. Approximating a Circle or an Ellipse Using Four Bezier Cubic Splines. http://www.tinaja.com/glib/ellipse4.pdf There is a use case where very large ellipses must be drawn with very high accuracy, and it is too expensive to render the entire ellipse with enough segments (either splines or line segments). Therefore, in the case where either radius of the ellipse is large enough that the error of the spline approximation will be visible (greater than one pixel offset from the ideal), a different technique is used. In that case, only the visible parts of the ellipse are drawn, with each visible arc using a fixed number of spline segments (8). The algorithm proceeds as follows: 1. The points where the ellipse intersects the axes bounding box are located. (This is done be performing an inverse transformation on the axes bbox such that it is relative to the unit circle -- this makes the intersection calculation much easier than doing rotated ellipse intersection directly). This uses the "line intersecting a circle" algorithm from: Vince, John. Geometry for Computer Graphics: Formulae, Examples & Proofs. London: Springer-Verlag, 2005. 2. The angles of each of the intersection points are calculated. 3. Proceeding counterclockwise starting in the positive x-direction, each of the visible arc-segments between the pairs of vertices are drawn using the bezier arc approximation technique implemented in Path.arc(). Cheers, Mike Ted Drain wrote: All of these sound like good ideas to me. Just for some history: the original reason we worked w/ John to get an Ellipse primitive in (vs a normal line plot of sampled points) were to: - improve ellipse plotting speeds (we plot a LOT of them at once) - improve post script output Ted At 08:53 AM 12/10/2007, Michael Droettboom wrote: John Hunter wrote: On Dec 10, 2007 10:25 AM, Ted Drain <[EMAIL PROTECTED]> wrote: I don't know if the current MPL architecture can support this but it would be nice if it worked that way. We have people making decisions based on what these plots show that affect spacecraft worth hundreds of millions of dollars so it's important that we're plotting things accurately. We can support this, but I think we would do this with an arc class rather than an ellipse class, and write a special case class that is viewlim aware. I agree -- I think there are two uses cases for ellipse that are in conflict here. One is these large ellipses, the other is for things like scatter plots, where speed and file size is more important than accuracy. My mind was probably stuck on the latter as I've worked along the transforms branch. A simple example of a line that has analogous behavior is examples/clippedline.py, which clips the points outside the viewport and draws in a different style according to the resolution of the viewlim. The reason I think it would be preferable to use an arc here is because we won't have to worry about filling the thing when we only approximate a section of it. You could feed in a 360 degree elliptical arc and then zoom into a portion of it. With the 8 point ellipse as is, and the addition of an arc class that does 4 or 8 point approximation within the zoom limits, should that serve your requirements? As a possible starting point, the transforms branch already has arc-approximation-by-cubic-bezier-spline code. It determines the number of splines to use based on the radians included in the arc, which is clearly not what we want here. But it should be reasonably straightforward to make that some fixed number and draw the arc between the edges of the axes. Or, alternatively, (and maybe this is what John is suggesting), the arc could be approximated by line segments (with the number of segments some
Re: [matplotlib-devel] Problem with Agg Ellipses
Michael, Thanks! That looks like a great solution. We'll take a look at it this week and try to beat on it w/ some more test cases. Ted At 12:46 PM 12/11/2007, Michael Droettboom wrote: Sorry -- correct attachment this time. Michael Droettboom wrote: I have a working draft of something that may work for this problem on the transforms branch. I am happy to backport this to the trunk, but that will require some effort, as the implementation relies on many of the new geometric utilities on the branch that would also have to be brought over. It may be some time until the branch is ready for production use, but if you are able to use it to experiment with this approach to this specific problem, that would certainly make my life easier, so I don't have to do the backporting work more than once. Attached is a plot comparing the new approach (above) vs. a 750-edge polygonal approximation for the ellipses (based directly on James Evans' example). Here's a description of what it does: Ellipses are normally drawn using an approximation that uses eight cubic bezier splines. The error of this approximation is 1.89818e-6, according to this unverified source: Lancaster, Don. Approximating a Circle or an Ellipse Using Four Bezier Cubic Splines. http://www.tinaja.com/glib/ellipse4.pdf There is a use case where very large ellipses must be drawn with very high accuracy, and it is too expensive to render the entire ellipse with enough segments (either splines or line segments). Therefore, in the case where either radius of the ellipse is large enough that the error of the spline approximation will be visible (greater than one pixel offset from the ideal), a different technique is used. In that case, only the visible parts of the ellipse are drawn, with each visible arc using a fixed number of spline segments (8). The algorithm proceeds as follows: 1. The points where the ellipse intersects the axes bounding box are located. (This is done be performing an inverse transformation on the axes bbox such that it is relative to the unit circle -- this makes the intersection calculation much easier than doing rotated ellipse intersection directly). This uses the "line intersecting a circle" algorithm from: Vince, John. Geometry for Computer Graphics: Formulae, Examples & Proofs. London: Springer-Verlag, 2005. 2. The angles of each of the intersection points are calculated. 3. Proceeding counterclockwise starting in the positive x-direction, each of the visible arc-segments between the pairs of vertices are drawn using the bezier arc approximation technique implemented in Path.arc(). Cheers, Mike Ted Drain wrote: All of these sound like good ideas to me. Just for some history: the original reason we worked w/ John to get an Ellipse primitive in (vs a normal line plot of sampled points) were to: - improve ellipse plotting speeds (we plot a LOT of them at once) - improve post script output Ted At 08:53 AM 12/10/2007, Michael Droettboom wrote: John Hunter wrote: On Dec 10, 2007 10:25 AM, Ted Drain <[EMAIL PROTECTED]> wrote: I don't know if the current MPL architecture can support this but it would be nice if it worked that way. We have people making decisions based on what these plots show that affect spacecraft worth hundreds of millions of dollars so it's important that we're plotting things accurately. We can support this, but I think we would do this with an arc class rather than an ellipse class, and write a special case class that is viewlim aware. I agree -- I think there are two uses cases for ellipse that are in conflict here. One is these large ellipses, the other is for things like scatter plots, where speed and file size is more important than accuracy. My mind was probably stuck on the latter as I've worked along the transforms branch. A simple example of a line that has analogous behavior is examples/clippedline.py, which clips the points outside the viewport and draws in a different style according to the resolution of the viewlim. The reason I think it would be preferable to use an arc here is because we won't have to worry about filling the thing when we only approximate a section of it. You could feed in a 360 degree elliptical arc and then zoom into a portion of it. With the 8 point ellipse as is, and the addition of an arc class that does 4 or 8 point approximation within the zoom limits, should that serve your requirements? As a possible starting point, the transforms branch already has arc-approximation-by-cubic-bezier-spline code. It determines the number of splines to use based on the radians included in the arc, which is clearly not what we want here. But it should be reaso
Re: [matplotlib-devel] Problem with Agg Ellipses
On Dec 11, 2007 3:24 PM, Ted Drain <[EMAIL PROTECTED]> wrote: > Thanks! That looks like a great solution. We'll take a look at it this > week and try to beat on it w/ some more test cases. Very nice work Michael -- I tried updating from your branch but it looks like maybe you haven't committed yet, as the last log entry I am seeing is: r4694 | mdboom | 2007-12-10 13:53:12 -0600 (Mon, 10 Dec 2007) | 2 lines Simplify even more JDH - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Insight on dealing with configuration
On Mon, Dec 10, 2007 at 08:23:57AM -0500, Darren Dale wrote: > Hi Gael, > On Monday 10 December 2007 3:58:48 am Gael Varoquaux wrote: > > I am about to start a configuration file for mayavi's mlab, and I am > > strongly considering mimicking matplotlib's way of doing things. > > I am almost sold to Fernando's TConfig, but I am not too sure how this > > fits with the current rcParams dictionnary. Is there some code that I > > could study to see how it's done? > Look in matplotlib/config/mplconfig.py, there is a class called > RcParamsWrapper that was designed to make the transition from rcParams to > TConfig easy for both developers and users. It should make the relationship > between the two pretty clear. OK, thanks. In the long run, what do you suggest I implement for mayavi2, an object oriented interface (pure TConfig) or an dictionnary-like interface (your RcParamsWrapper)? I am not too exited about your RcParamsWrapper because it is not generated from the configuration object, and thus the info is duplicated, but I guess you did this for backward compatibility reasons, and I could use a canonical mapping from one to the other and do this automatically. I would like to proivde an interface that feels familiar to the user, this is why I am looking closely at what MPL and ipython are doing. Cheers, Gaël - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Insight on dealing with configuration
On Tuesday 11 December 2007 7:03:57 pm Gael Varoquaux wrote: > On Mon, Dec 10, 2007 at 08:23:57AM -0500, Darren Dale wrote: > > Hi Gael, > > > > On Monday 10 December 2007 3:58:48 am Gael Varoquaux wrote: > > > I am about to start a configuration file for mayavi's mlab, and I am > > > strongly considering mimicking matplotlib's way of doing things. > > > > > > I am almost sold to Fernando's TConfig, but I am not too sure how this > > > fits with the current rcParams dictionnary. Is there some code that I > > > could study to see how it's done? > > > > Look in matplotlib/config/mplconfig.py, there is a class called > > RcParamsWrapper that was designed to make the transition from rcParams to > > TConfig easy for both developers and users. It should make the > > relationship between the two pretty clear. > > OK, thanks. > > In the long run, what do you suggest I implement for mayavi2, an object > oriented interface (pure TConfig) or an dictionnary-like interface > (your RcParamsWrapper)? > > I am not too exited about your RcParamsWrapper because it is not > generated from the configuration object, and thus the info is duplicated, > but I guess you did this for backward compatibility reasons, and I could > use a canonical mapping from one to the other and do this automatically. > > I would like to proivde an interface that feels familiar to the user, > this is why I am looking closely at what MPL and ipython are doing. RcParamsWrapper was created so we could get matplotlib working with the new config object without a massive rewrite of the entire library. The intention is to use the object-oriented interface internally, and to encourage users to do the same. RcParamsWrapper simply provides the upgrade path. Darren - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Problem with Agg Ellipses
Sorry. Try now. (I use psvn.el for doing svn checkins, and I mostly think it's great, but it's awfully quiet when something fails.) Cheers, Mike - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Insight on dealing with configuration
On Tue, Dec 11, 2007 at 07:14:11PM -0500, Darren Dale wrote: > RcParamsWrapper was created so we could get matplotlib working with the new > config object without a massive rewrite of the entire library. The intention > is to use the object-oriented interface internally, and to encourage users to > do the same. RcParamsWrapper simply provides the upgrade path. OK, Thanks a lot. I'll probably stick with pure objects, than, but I might modify the __repr__ of the object to make it more easily for the user to edit this interactively (ie making a representation more like to one you would get out of a dictionnary. The problem is that it would break your script, so I can't send you a patch. I'd like the codebase to stay similar, so maybe we can discuss this once I have some code. Gaël - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Insight on dealing with configuration
On Dec 11, 2007 5:32 PM, Gael Varoquaux <[EMAIL PROTECTED]> wrote: > On Tue, Dec 11, 2007 at 07:14:11PM -0500, Darren Dale wrote: > > RcParamsWrapper was created so we could get matplotlib working with the new > > config object without a massive rewrite of the entire library. The intention > > is to use the object-oriented interface internally, and to encourage users > > to > > do the same. RcParamsWrapper simply provides the upgrade path. > > OK, Thanks a lot. I'll probably stick with pure objects, than, but I > might modify the __repr__ of the object to make it more easily for the > user to edit this interactively (ie making a representation more like to > one you would get out of a dictionnary. The tconfig objects already have a very dict-like representation for dumping into a text file, the .ini format. Or do you mean something that's even closer to a dict, curly braces and all? > The problem is that it would break your script, so I can't send you a > patch. I'd like the codebase to stay similar, so maybe we can discuss > this once I have some code. Yup, it would be good not to have mpl-tconfig, ipython-tconfig and mayavi-tconfig :) Cheers, f - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Insight on dealing with configuration
On Tue, Dec 11, 2007 at 05:37:41PM -0700, Fernando Perez wrote: > The tconfig objects already have a very dict-like representation for > dumping into a text file, the .ini format. Or do you mean something > that's even closer to a dict, curly braces and all? No, I don't care about the curly brace. However, I don't want the comments. I haven't decided yet, but I am sure that I want something that a bit more compact than, eg "print MPLConfig()". > > The problem is that it would break your script, so I can't send you a > > patch. I'd like the codebase to stay similar, so maybe we can discuss > > this once I have some code. > Yup, it would be good not to have mpl-tconfig, ipython-tconfig and > mayavi-tconfig :) Yes, lets try to keep this united. I'll probably also work on a nice TraitsUI view. If all three projects can use the same model, view and controler for the configuration file, that will make it easier to, one day, present a unified configuration editor for a scientific IDE (:->). Gaël - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Insight on dealing with configuration
On Dec 11, 2007 5:42 PM, Gael Varoquaux <[EMAIL PROTECTED]> wrote: > On Tue, Dec 11, 2007 at 05:37:41PM -0700, Fernando Perez wrote: > > The tconfig objects already have a very dict-like representation for > > dumping into a text file, the .ini format. Or do you mean something > > that's even closer to a dict, curly braces and all? > > No, I don't care about the curly brace. However, I don't want the > comments. I haven't decided yet, but I am sure that I want something that > a bit more compact than, eg "print MPLConfig()". I see, makes sense. Hack away, I trust your judgment :) > > > The problem is that it would break your script, so I can't send you a > > > patch. I'd like the codebase to stay similar, so maybe we can discuss > > > this once I have some code. > > > Yup, it would be good not to have mpl-tconfig, ipython-tconfig and > > mayavi-tconfig :) > > Yes, lets try to keep this united. I'll probably also work on a nice > TraitsUI view. If all three projects can use the same model, view and > controler for the configuration file, that will make it easier to, one > day, present a unified configuration editor for a scientific IDE (:->). Indeed. Once we have the code in place, we'll worry about organizing things for easy reuse. Cheers, f - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] scroll wheel on wx
Hi,
I have a patch which implements the scroll wheel on wx using the
wx mouse wheel event.
Rather than a simple up/down mouse event wx uses:
delta: intervals per click
rotation: number of clicks
rate: number of lines per click
I convert this to:
step = rotation*delta/rate
I've added the step attribute to the mpl MouseEvent in addition to the
usual up/down button (up if step >= 0, down otherwise).
I removed the mpl_connect from the scroll event to pick. I don't know
why it was there.
I tested the patch on OS X WxAgg examples/image_slice_viewer.
Let me know if it is okay to post to svn, or if we are still in feature
freeze.
- Paul
Index: backend_bases.py
===
--- backend_bases.py(revision 4699)
+++ backend_bases.py(working copy)
@@ -776,6 +776,7 @@
inaxes = None # the Axes instance if mouse us over axes
xdata = None # x coord of mouse in data coords
ydata = None # y coord of mouse in data coords
+step = None # for scroll events, the number of steps
"""
x = None # x position - pixels from left of canvas
@@ -784,9 +785,10 @@
inaxes = None # the Axes instance if mouse us over axes
xdata = None # x coord of mouse in data coords
ydata = None # y coord of mouse in data coords
+step = None # for scroll events, the number of steps
def __init__(self, name, canvas, x, y, button=None, key=None,
- guiEvent=None):
+ step=None, guiEvent=None):
"""
x, y in figure coords, 0,0 = bottom, left
button pressed None, 1, 2, 3
@@ -794,6 +796,7 @@
LocationEvent.__init__(self, name, canvas, x, y, guiEvent=guiEvent)
self.button = button
self.key = key
+self.step = step
class PickEvent(Event):
"""
@@ -872,7 +875,7 @@
self._key= None # the key pressed
self._lastx, self._lasty = None, None
self.button_pick_id = self.mpl_connect('button_press_event',self.pick)
-self.scroll_pick_id = self.mpl_connect('scroll_event',self.pick)
+#self.scroll_pick_id = self.mpl_connect('scroll_event',self.pick)
if False:
## highlight the artists that are hit
@@ -1001,15 +1004,17 @@
event = PickEvent(s, self, mouseevent, artist, **kwargs)
self.callbacks.process(s, event)
-def scroll_event(self, x, y, button, guiEvent=None):
+def scroll_event(self, x, y, step, guiEvent=None):
"""
Backend derived classes should call this function on any
scroll wheel event. x,y are the canvas coords: 0,0 is lower,
left. button and key are as defined in MouseEvent
"""
+button = 'up' if step >= 0 else 'down'
self._button = button
s = 'scroll_event'
-mouseevent = MouseEvent(s, self, x, y, button, self._key,
guiEvent=guiEvent)
+mouseevent = MouseEvent(s, self, x, y, button, self._key,
+ step=step, guiEvent=guiEvent)
self.callbacks.process(s, mouseevent)
Index: backends/backend_gtk.py
===
--- backends/backend_gtk.py (revision 4699)
+++ backends/backend_gtk.py (working copy)
@@ -179,10 +179,10 @@
# flipy so y=0 is bottom of canvas
y = self.allocation.height - event.y
if event.direction==gdk.SCROLL_UP:
-direction = 'up'
+step = 1
else:
-direction = 'down'
-FigureCanvasBase.scroll_event(self, x, y, direction)
+step = -1
+FigureCanvasBase.scroll_event(self, x, y, step)
return False # finish event propagation?
def button_press_event(self, widget, event):
Index: backends/backend_wx.py
===
--- backends/backend_wx.py (revision 4699)
+++ backends/backend_wx.py (working copy)
@@ -1174,9 +1174,23 @@
FigureCanvasBase.button_release_event(self, x, y, 1, guiEvent=evt)
def _onMouseWheel(self, evt):
-# TODO: implement mouse wheel handler
-pass
+"""Translate mouse wheel events into matplotlib events"""
+# Determine mouse location
+x = evt.GetX()
+y = self.figure.bbox.height() - evt.GetY()
+# Convert delta/rotation/rate into a floating point step size
+delta = evt.GetWheelDelta()
+rotation = evt.GetWheelRotation()
+rate = evt.GetLinesPerAction()
+#print "delta,rotation,rate",delta,rotation,rate
+step = rate*float(rotation)/delta
+
+# Convert to mpl event
+# Note: If Skip(True) then OS X generates two events per click
+evt.Skip(False)
+self.scroll_event(x, y, step, guiEvent=evt)
+
def _onMotion(self, evt):
"""Start measuring o
Re: [matplotlib-devel] scroll wheel on wx
On Dec 11, 2007 6:51 PM, Paul Kienzle <[EMAIL PROTECTED]> wrote: > I removed the mpl_connect from the scroll event to pick. I don't know > why it was there. > > I tested the patch on OS X WxAgg examples/image_slice_viewer. > > Let me know if it is okay to post to svn, or if we are still in feature > freeze. As long as you are reasonably confident that this won't break existing code, go ahead and commit it. In the next day or two, if nothing else serious arises, I'd like to cut 0.91.2 if Charlie has time. JDH - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Adding a water mark to a plot
Hi all, Is it possible to add a water mark to a plot ? Nils - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
