You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
(12) |
Sep
(12) |
Oct
(56) |
Nov
(65) |
Dec
(37) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(59) |
Feb
(78) |
Mar
(153) |
Apr
(205) |
May
(184) |
Jun
(123) |
Jul
(171) |
Aug
(156) |
Sep
(190) |
Oct
(120) |
Nov
(154) |
Dec
(223) |
2005 |
Jan
(184) |
Feb
(267) |
Mar
(214) |
Apr
(286) |
May
(320) |
Jun
(299) |
Jul
(348) |
Aug
(283) |
Sep
(355) |
Oct
(293) |
Nov
(232) |
Dec
(203) |
2006 |
Jan
(352) |
Feb
(358) |
Mar
(403) |
Apr
(313) |
May
(165) |
Jun
(281) |
Jul
(316) |
Aug
(228) |
Sep
(279) |
Oct
(243) |
Nov
(315) |
Dec
(345) |
2007 |
Jan
(260) |
Feb
(323) |
Mar
(340) |
Apr
(319) |
May
(290) |
Jun
(296) |
Jul
(221) |
Aug
(292) |
Sep
(242) |
Oct
(248) |
Nov
(242) |
Dec
(332) |
2008 |
Jan
(312) |
Feb
(359) |
Mar
(454) |
Apr
(287) |
May
(340) |
Jun
(450) |
Jul
(403) |
Aug
(324) |
Sep
(349) |
Oct
(385) |
Nov
(363) |
Dec
(437) |
2009 |
Jan
(500) |
Feb
(301) |
Mar
(409) |
Apr
(486) |
May
(545) |
Jun
(391) |
Jul
(518) |
Aug
(497) |
Sep
(492) |
Oct
(429) |
Nov
(357) |
Dec
(310) |
2010 |
Jan
(371) |
Feb
(657) |
Mar
(519) |
Apr
(432) |
May
(312) |
Jun
(416) |
Jul
(477) |
Aug
(386) |
Sep
(419) |
Oct
(435) |
Nov
(320) |
Dec
(202) |
2011 |
Jan
(321) |
Feb
(413) |
Mar
(299) |
Apr
(215) |
May
(284) |
Jun
(203) |
Jul
(207) |
Aug
(314) |
Sep
(321) |
Oct
(259) |
Nov
(347) |
Dec
(209) |
2012 |
Jan
(322) |
Feb
(414) |
Mar
(377) |
Apr
(179) |
May
(173) |
Jun
(234) |
Jul
(295) |
Aug
(239) |
Sep
(276) |
Oct
(355) |
Nov
(144) |
Dec
(108) |
2013 |
Jan
(170) |
Feb
(89) |
Mar
(204) |
Apr
(133) |
May
(142) |
Jun
(89) |
Jul
(160) |
Aug
(180) |
Sep
(69) |
Oct
(136) |
Nov
(83) |
Dec
(32) |
2014 |
Jan
(71) |
Feb
(90) |
Mar
(161) |
Apr
(117) |
May
(78) |
Jun
(94) |
Jul
(60) |
Aug
(83) |
Sep
(102) |
Oct
(132) |
Nov
(154) |
Dec
(96) |
2015 |
Jan
(45) |
Feb
(138) |
Mar
(176) |
Apr
(132) |
May
(119) |
Jun
(124) |
Jul
(77) |
Aug
(31) |
Sep
(34) |
Oct
(22) |
Nov
(23) |
Dec
(9) |
2016 |
Jan
(26) |
Feb
(17) |
Mar
(10) |
Apr
(8) |
May
(4) |
Jun
(8) |
Jul
(6) |
Aug
(5) |
Sep
(9) |
Oct
(4) |
Nov
|
Dec
|
2017 |
Jan
(5) |
Feb
(7) |
Mar
(1) |
Apr
(5) |
May
|
Jun
(3) |
Jul
(6) |
Aug
(1) |
Sep
|
Oct
(2) |
Nov
(1) |
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2025 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
S | M | T | W | T | F | S |
---|---|---|---|---|---|---|
|
|
|
1
(14) |
2
(31) |
3
(20) |
4
(4) |
5
(2) |
6
(10) |
7
(25) |
8
(13) |
9
(3) |
10
(5) |
11
(2) |
12
(1) |
13
(19) |
14
(16) |
15
(18) |
16
(7) |
17
(17) |
18
|
19
(2) |
20
(7) |
21
(12) |
22
(14) |
23
(8) |
24
(6) |
25
(3) |
26
|
27
(21) |
28
(8) |
29
(5) |
30
(6) |
|
|
On Jun 6, 2005, at 9:10 AM, Arnd Baecker wrote: > However, the additional lines, plotted inside > the on_press event handler, are not shown > (only after clicking on the "home" button, or zoom, they > appear). This is with matplotlib 0.80, debian, GTKAgg frontend. You either need to turn on interactive plotting (`ion()', I think), or add a call to `draw()' to redraw the plot: def on_press(event): """Draw on button press events.""" print "Event:",event.x,event.y,event.xdata,event.ydata,event.inaxes if event.inaxes==ax2: ax1.plot(phi, event.ydata*x, 'r--') draw() I hope this helps. Ken
Hi, I would like to react on mouse-clicks by adding lines to a plot (see the example at the end of this mail). However, the additional lines, plotted inside the on_press event handler, are not shown (only after clicking on the "home" button, or zoom, they appear). This is with matplotlib 0.80, debian, GTKAgg frontend. Is there a simple trick to make them visible? Many thanks in advance, Arnd # --------------------------------- from pylab import * phi=arange(0.0,2.0*pi+0.05,0.1) x=cos(phi) y=sin(phi) w,h=12,6 fig=figure(figsize=(w, h), dpi=100) ax1 = fig.add_axes([0.1, 0.55, 0.8, 0.4]) plot(phi,x) ax2 = fig.add_axes([0.1, 0.1, 0.35*h/w, 0.35]) plot(x,y,linewidth=5) title ("circular circle?") xlim(-1.1,1.1 ) ylim(-1.1,1.1 ) xlabel("click in this plot window") def on_press(event): """Draw on button press events.""" print "Event:",event.x,event.y,event.xdata,event.ydata,event.inaxes if event.inaxes==ax2: ax1.plot(phi, event.ydata*x, 'r--') # QUESTION: How can I force to show this line in ax1? connect('button_press_event', on_press) show()
John Hunter schrieb: > [...] > >Yes, the object_picker demo is very old and deprecated. It is around >from before the days of GUI neutral picking. > >I wrote a little demo showing you how to pick the text (title, xlabel, >ylabel, ticklabels). Press "p" over a text instance outside the axes >bounding box and it will turn blue. If you think this is a reasonable >interface, I can make this the basis of a figure pick function. The >question is, what should such a function return. Eg, if you are >outside the axes and click over a text instance, it should return the >text instance. Clear enough. But if you are over an axes and click >on a line, what should it return? The Axes instance, The Line2D >instance, both in a tuple? > > > John, thanks for the nice example. I agree with you that one needs to think carefully about what pick() should actually return. I will experiment a little bit and will reply to the mailing list once I have made up my mind ;-) Regards, Niklas.
Ken McIvor wrote: > All of the aforementioned plot_XZY() functions accept a Figure as > their only argument and draw their plots onto the figure, so they're > already backend independent. I have attached a script which uses > `pylab.figure()' to handle the creation of the Figure and associated > FigureCanvas. Run it from the command line, and it will present you > with a list of demos. Very handy, and thanks for the work. I'm still getting used to OO style.
Hi, That seems to have helped a fair bit, thanks for the tips. Mark On Fri, 2005年06月03日 at 22:34 -0500, John Hunter wrote: > >>>>> "Mark" == Mark Saward <ms...@bi...> writes: > > Mark> Hi, It looks good thanks, but I'm having a couple of > Mark> problems (being a python and matplotlib newbie). > > You can use the "GUI neutral" pylab interface to do animation, but I > don't recommend it. This is mainly for teaching, demonstration and > testing purposes. For real work, I would settle on a GUI toolkit and > use their event loop (idle handling or timer) to do the animation. If > you are able to choose, I recommend GTKAgg as a backend for animation > because it is fastest (fltk is close, I haven't profiled qtagg; wxagg > and tkagg are significantly slower). > > See, for example, examples/dynamic_image_gtkagg.py for an example of > how to use the gtk idle handler to do animation. > > Mark> 2. It flashes between the specified axis and just fitting the > Mark> graph to the boundaries defined by the actual data. I want it > Mark> to stay using the specified axis all the time > > I suspect this is because you are not properly controlling when > drawing is done. For example, if interactive mode is on and you do > > for frame in myloop: > axis(*rect) > plot(blah) > > your figure will be drawn twice. Once when axis is called and once > when plot is called. plot calls autoscale and may change the axis. > What you want is to turn interaction off and explicitly control the > time of the drawing with a call to canvas.draw() or pylab.draw() > When interaction is on, all pylab commands (including axis and draw in > this example) trigger a call to draw, > which is not you want. What you want is something like > > # turn interaction off > for frame in myloop: > plot(something) # or set your line data, whatever.... > axis(*rect) > draw() > > Here you only draw after the axis limits have been set. > > Actually, in animation you rarely want to call plot for every frame. > It is much more efficient to save an object and set its data, as in > dynamic_image_gtkagg and anim.py. Calling plot in every frame creates > a new Line2D object on each iteration of the loop and is slow. > > Hope this helps, > JDH
On Fri, 2005年06月03日 at 08:00 -0500, John Hunter wrote: > >>>>> "Steve" == Steve Chaplin <ste...@ya...> writes: > > Steve> Why do we have self.set_double_buffered(False)? Its been > Steve> that way for as long as I can remember, I think John wrote > Steve> the original code, he may remember the actual reasons. > > The original motivation can be found in this thread > > http://www.daa.com.au/pipermail/pygtk/2003-May/005229.html > > The basic idea, if I recall correctly, was that since I was already > drawing to a pixmap, I was duplicating some effort by turning on > double buffering. Perhaps this reasoning wasn't correct, since we > were clearly doing something wrong as evidenced by the bug report that > started this discussion. The bug report highlights a GTK+ 2.6 bug (in my opinion) - GTK should redraw a widgets background after each expose event, it does for 2.4 but forgets to do it for 2.6. It looks like the gdk.Pixmap was used to solve the screen flicker problem. However, if you arrange for all drawing to go through the expose_event function (instead of a custom 'draw' function), GTK should ensure there is no flicker (at least thats what the gtk_widget_set_double_buffered documentation suggests). But using a Pixmap has the advantage that you can quickly redraw a part of the window that has been obscured and then exposed without needing to redraw the entire Figure. Regards Steve Send instant messages to your online friends http://au.messenger.yahoo.com
>>>>> "Mark" == Mark Saward <ms...@bi...> writes: Mark> Hi, It looks good thanks, but I'm having a couple of Mark> problems (being a python and matplotlib newbie). You can use the "GUI neutral" pylab interface to do animation, but I don't recommend it. This is mainly for teaching, demonstration and testing purposes. For real work, I would settle on a GUI toolkit and use their event loop (idle handling or timer) to do the animation. If you are able to choose, I recommend GTKAgg as a backend for animation because it is fastest (fltk is close, I haven't profiled qtagg; wxagg and tkagg are significantly slower). See, for example, examples/dynamic_image_gtkagg.py for an example of how to use the gtk idle handler to do animation. Mark> 2. It flashes between the specified axis and just fitting the Mark> graph to the boundaries defined by the actual data. I want it Mark> to stay using the specified axis all the time I suspect this is because you are not properly controlling when drawing is done. For example, if interactive mode is on and you do for frame in myloop: axis(*rect) plot(blah) your figure will be drawn twice. Once when axis is called and once when plot is called. plot calls autoscale and may change the axis. What you want is to turn interaction off and explicitly control the time of the drawing with a call to canvas.draw() or pylab.draw() When interaction is on, all pylab commands (including axis and draw in this example) trigger a call to draw, which is not you want. What you want is something like # turn interaction off for frame in myloop: plot(something) # or set your line data, whatever.... axis(*rect) draw() Here you only draw after the axis limits have been set. Actually, in animation you rarely want to call plot for every frame. It is much more efficient to save an object and set its data, as in dynamic_image_gtkagg and anim.py. Calling plot in every frame creates a new Line2D object on each iteration of the loop and is slow. Hope this helps, JDH
Hi, It looks good thanks, but I'm having a couple of problems (being a python and matplotlib newbie). Specifically: 1. When I don't have the sleep bit in the attached file, sometimes/often the graph will stop displaying onscreen halfway through until it is finished. I don't want it to disappear - I want to be able to reliably watch the graph as it forms 2. It flashes between the specified axis and just fitting the graph to the boundaries defined by the actual data. I want it to stay using the specified axis all the time Any help appreciated. Sorry if I shouldn't be attaching files to this list. Tim Leslie wrote: >On 2005年5月30日, Mark Saward <ms...@bi...> wrote... > > > >>Hi, >> >>I need to make a small application that will do real time graphs. >>Basically, it will receive data, and then: >>* store that data in a database >>* display it on a graph >>The graph will be Time vs Input so that a user can watch the graph >>grow. Updates may be needed as quickly as 5 times per second. >> >>Can matplotlib do this, or should I be looking at using something else? >>If it can, how? I've taken a browse through the website but can't find >>relevant information. >> >> > >Have a look at anim.py in the examples directory of source distribution. >This should give you an idea of how to attack the problem. Feel free to >get back to us if you have any problems. > >Cheers, > >Tim > > > >>Mark >> >> >>------------------------------------------------------- >>This SF.Net email is sponsored by Yahoo. >>Introducing Yahoo! Search Developer Network - Create apps using Yahoo! >>Search APIs Find out how you can build Yahoo! directly into your own >>Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 >>_______________________________________________ >>Matplotlib-users mailing list >>Mat...@li... >>https://lists.sourceforge.net/lists/listinfo/matplotlib-users >> >> >> >`- > > >------------------------------------------------------- >This SF.Net email is sponsored by Yahoo. >Introducing Yahoo! Search Developer Network - Create apps using Yahoo! >Search APIs Find out how you can build Yahoo! directly into your own >Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 >_______________________________________________ >Matplotlib-users mailing list >Mat...@li... >https://lists.sourceforge.net/lists/listinfo/matplotlib-users > > >
Perfect! Thanks! Jeff -----Original Message----- From: Matt Newville [mailto:new...@ca...] Sent: Friday, June 03, 2005 11:47 AM To: Jeff Peery Cc: mat...@li... Subject: Re: [Matplotlib-users] RE: Matplotlib-users digest, Vol 1 #632 - 14 msgs Jeff, > Hello, I'm using wx.Agg as a backend for wxpython. I would like to put > a plot inside a splitter window. Something that looks like this: > > #adjust figure size > self.figure = Figure(figsize=(0.5,1), dpi=100) > > #create the canvas > self.canvas = FigureCanvas(self, -1, self.figure) > > #add canvas to splitter window > self.splitterWindow2.SplitVertically(self.window1,self.canvas,4) > > #create a plot instance > self.axes = self.figure.add_subplot(111) It's definitely no problem to put a FigureCanvasWxAgg on a wx.Window or wx.Panel as in: class Plotter(wx.Window): def __init__(self,parent=None): wx.Window.__init__(self,parent,-1) self.fig = Figure((5,4), 75) self.canvas = FigureCanvasWxAgg(self,-1,self.fig) self.axes = self.fig.add_axes([0.12,0.12,0.76,0.76]) sizer = wx.BoxSizer(wx.VERTICAL) sizer.Add(self.canvas,1, wx.LEFT|wx.TOP) self.SetSizer(sizer) self.Fit() def plot(self,x,y,*args,**kwds): "very simple plot !!" self.axes.cla() self.axes.plot(x,y,*args,**kwds) (and wx.Window can be replaced by wx.Panel). A more complete example is below, though not with a splitter window, it shows that the Plotter can be placed anywhere. Hope that helps, --Matt #!/usr/bin/env python import wx import matplotlib.numerix as nx from matplotlib.figure import Figure from matplotlib.backends.backend_wxagg import FigureCanvasWxAgg class Plotter(wx.Window): def __init__(self,parent=None): wx.Window.__init__(self,parent,-1) self.fig = Figure((5,4), 75) self.canvas = FigureCanvasWxAgg(self,-1,self.fig) self.axes = self.fig.add_axes([0.12,0.12,0.76,0.76]) sizer = wx.BoxSizer(wx.VERTICAL) sizer.Add(self.canvas,1, wx.LEFT|wx.TOP) self.SetSizer(sizer) self.Fit() def plot(self,x,y,*args,**kwds): "very simple plot !!" self.axes.cla() self.axes.plot(x,y,*args,**kwds) class PlotFrame(wx.Frame): def __init__(self,parent=None): wx.Frame.__init__(self,parent,-1,'Frame') self.plotwin = Plotter(self) sizer = wx.BoxSizer(wx.VERTICAL) sizer.Add(wx.StaticText(self, -1 , ' WX Matplotlib example ') ,0, wx.LEFT|wx.TOP) sizer.Add(self.plotwin,1, wx.LEFT|wx.TOP) self.SetSizer(sizer) self.Fit() def plot(self,x,y,*args,**kwds): self.plotwin.plot(x,y,*args,**kwds) if __name__ == '__main__': app = wx.PySimpleApp() frame = PlotFrame() x = nx.arange(0,10.0,0.05) y = nx.sin(x*nx.pi/3) frame.plot(x,y,'ro') frame.Show() app.MainLoop() #####################
Hi Jeff, As you are using Boa this might be helpful to you (Matt, no I can't read minds but Jeff posted another problem to the Boa list). I use a splitter to have on the left side some selection criteria and on the right side the figure or multiple figures. You can not directly use matplotlib in the Boa Frame designer, but you can do the following. Anywhere after: def __init__(self, parent): self._init_ctrls(parent) I do this: self.figure = Figure() self.canvas = FigureCanvas(self.splitter, -1, self.figure) old = self.splitter.GetWindow2() if old == None: self.splitter.SplitVertically(self.selectionPanel, self.canvas, 350) else: self.splitter.ReplaceWindow(old, self.canvas) Hope this helps Werner Jeff Peery wrote: > Hello, I'm using wx.Agg as a backend for wxpython. I would like to put > a plot inside a splitter window. Something that looks like this: > > #adjust figure size > self.figure = Figure(figsize=(0.5,1), dpi=100) > > #create the canvas > self.canvas = FigureCanvas(self, -1, self.figure) > > #add canvas to splitter window > self.splitterWindow2.SplitVertically(self.window1,self.canvas,4) > > #create a plot instance > self.axes = self.figure.add_subplot(111) > > > Alternatively, how would it look if I wanted to add the plot to a > wx.window? This might be a more simple case... either way I'm not sure > how to do this? I appreciate the help! Thanks. > > Jeff > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput > a projector? How fast can you ride your desk chair down the office luge track? > If you want to score the big prize, get to know the little guy. > Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
>>>>> "N" == N Volbers <mit...@we...> writes: N> BTW, is it possible to detect double-clicks? Not currently -- we could add this to the GUI neutral event handling mechanism. Probably the easiest way would be to do this at the level of backend_bases, and check for double clicks ourselves, rather than trying to wrap double click events for all 5 GUIs. JDH
>>>>> "N" == N Volbers <mit...@we...> writes: N> Hello everyone, I am trying to implement object picking in my N> matplotlib-based plotting application. I found two examples. N> The 'picker_demo.py' demo is very nice and looks a lot simpler N> than the 'object_picker.py' which requires you to use your own N> Canvas object. But since object_picker needs to have the N> event.inaxes object, it seems impossible to catch any events N> outside the axes' bounding box, like 'click on axes title', or N> 'click on ticks' or 'click on xlabel'. Yes, the object_picker demo is very old and deprecated. It is around from before the days of GUI neutral picking. I wrote a little demo showing you how to pick the text (title, xlabel, ylabel, ticklabels). Press "p" over a text instance outside the axes bounding box and it will turn blue. If you think this is a reasonable interface, I can make this the basis of a figure pick function. The question is, what should such a function return. Eg, if you are outside the axes and click over a text instance, it should return the text instance. Clear enough. But if you are over an axes and click on a line, what should it return? The Axes instance, The Line2D instance, both in a tuple? from pylab import subplot, title, connect, text, plot, rand, \ show, gcf, draw from matplotlib.text import Text from matplotlib.lines import Line2D from matplotlib.patches import Patch, Circle def overtext(t, event): 'return true if event is over text' bbox = t.get_window_extent() return bbox.contains(event.x, event.y) def pick(event): if event.key!='p': return if event.inaxes is not None: # axes pick ax = event.inaxes a = ax.pick(event.x, event.y) if isinstance(a, Text): a.set_color('r') elif isinstance(a, Line2D): a.set_markerfacecolor('r') elif isinstance(a, Patch): a.set_facecolor('r') draw() else: # figure pick fig = gcf() texts = [] for ax in fig.axes: texts.extend([ax.xaxis.label, ax.yaxis.label, ax.title]) texts.extend(ax.xaxis.get_ticklabels()) texts.extend(ax.yaxis.get_ticklabels()) for t in texts: if overtext(t, event): t.set_color('blue') draw() return connect('key_press_event', pick) ax = subplot(111) title('Put mouse over object and press "p" to pick it') for i in range(20): x, y = rand(2) text(x,y,'hi!') for i in range(5): x = rand(10) y = rand(10) plot(x,y,'go') for i in range(5): x = rand() y = rand() center = x,y p = Circle(center, radius=.1) ax.add_patch(p) show()
Jeff, > Hello, I'm using wx.Agg as a backend for wxpython. I would like to put > a plot inside a splitter window. Something that looks like this: > > #adjust figure size > self.figure = Figure(figsize=(0.5,1), dpi=100) > > #create the canvas > self.canvas = FigureCanvas(self, -1, self.figure) > > #add canvas to splitter window > self.splitterWindow2.SplitVertically(self.window1,self.canvas,4) > > #create a plot instance > self.axes = self.figure.add_subplot(111) It's definitely no problem to put a FigureCanvasWxAgg on a wx.Window or wx.Panel as in: class Plotter(wx.Window): def __init__(self,parent=None): wx.Window.__init__(self,parent,-1) self.fig = Figure((5,4), 75) self.canvas = FigureCanvasWxAgg(self,-1,self.fig) self.axes = self.fig.add_axes([0.12,0.12,0.76,0.76]) sizer = wx.BoxSizer(wx.VERTICAL) sizer.Add(self.canvas,1, wx.LEFT|wx.TOP) self.SetSizer(sizer) self.Fit() def plot(self,x,y,*args,**kwds): "very simple plot !!" self.axes.cla() self.axes.plot(x,y,*args,**kwds) (and wx.Window can be replaced by wx.Panel). A more complete example is below, though not with a splitter window, it shows that the Plotter can be placed anywhere. Hope that helps, --Matt #!/usr/bin/env python import wx import matplotlib.numerix as nx from matplotlib.figure import Figure from matplotlib.backends.backend_wxagg import FigureCanvasWxAgg class Plotter(wx.Window): def __init__(self,parent=None): wx.Window.__init__(self,parent,-1) self.fig = Figure((5,4), 75) self.canvas = FigureCanvasWxAgg(self,-1,self.fig) self.axes = self.fig.add_axes([0.12,0.12,0.76,0.76]) sizer = wx.BoxSizer(wx.VERTICAL) sizer.Add(self.canvas,1, wx.LEFT|wx.TOP) self.SetSizer(sizer) self.Fit() def plot(self,x,y,*args,**kwds): "very simple plot !!" self.axes.cla() self.axes.plot(x,y,*args,**kwds) class PlotFrame(wx.Frame): def __init__(self,parent=None): wx.Frame.__init__(self,parent,-1,'Frame') self.plotwin = Plotter(self) sizer = wx.BoxSizer(wx.VERTICAL) sizer.Add(wx.StaticText(self, -1 , ' WX Matplotlib example ') ,0, wx.LEFT|wx.TOP) sizer.Add(self.plotwin,1, wx.LEFT|wx.TOP) self.SetSizer(sizer) self.Fit() def plot(self,x,y,*args,**kwds): self.plotwin.plot(x,y,*args,**kwds) if __name__ == '__main__': app = wx.PySimpleApp() frame = PlotFrame() x = nx.arange(0,10.0,0.05) y = nx.sin(x*nx.pi/3) frame.plot(x,y,'ro') frame.Show() app.MainLoop() #####################
Hello, I'm using wx.Agg as a backend for wxpython. I would like to put a plot inside a splitter window. Something that looks like this: #adjust figure size self.figure = Figure(figsize=(0.5,1), dpi=100) #create the canvas self.canvas = FigureCanvas(self, -1, self.figure) #add canvas to splitter window self.splitterWindow2.SplitVertically(self.window1,self.canvas,4) #create a plot instance self.axes = self.figure.add_subplot(111) Alternatively, how would it look if I wanted to add the plot to a wx.window? This might be a more simple case... either way I'm not sure how to do this? I appreciate the help! Thanks. Jeff
On Friday 03 June 2005 10:46 am, Nicolas Girard wrote: > On Friday 03 June 2005 16:34, John Hunter wrote: > > OK, now I am getting the ZeroDivisionError as well. These were caused > > by recent changes to ticker.py. We'll get it cleared up shortly. > > Well, that's a great news ! I had remorses because I didn't have the time > yet today to upgrade my copy of Numeric and give another try as you advic= ed > me yesterday... I think I was able to fix this. pcolor_demo.py works for me now, and I also= =20 checked with backend_driver.py. Changes in CVS.=20 Darren
Hi Darren On Fri, 2005年06月03日 at 09:48 -0400, Darren Dale wrote: > > Since I also have limited time, I could use epswrite for now. The resulting > > figures are not fantastic on screen, (I already had smooth line art enabled > > in Adobe Reader), but marginal improvements can be had by increasing the > > viewer's resolution. > > I have some good news! This morning I discovered the ability to set the > resolution during the creation of an eps file with epswrite: > > gs -dBATCH -dNOPAUSE -dSAFER -q -r6000 -sDEVICE=epswrite -dLanguageLevel=3 \ > -dEPSFitPage -sOutputFile=foo.eps foo.ps > > This file can be embedded in a new latex document and it has no font > information so the text is rendered properly. The final output looks great > when printed or viewed with Adobe Reader. I think this is the way to go. As > for file size, the eps output from examples/tex_demo.py is about 50KB. > Hmm, very strange. I'd been getting all the same results without bothering with the ghostscript resolution switch. I can't honestly see why the resolution should have much to do with it since I thought it only affected any vector->raster conversions, whereas epswrite should be keeping everything as vector, albeit flattened. I am using GNU Ghostscript 7.07 (2003年05月17日). My files look fine on-screen in ghostview et al. When converted to PDF they look godawful in xpdf and kpdf but fine in acroread with "Smooth Line Art" enabled. Cheers Will -- Dr William Henney, Centro de Radioastronomía y Astrofísica, Universidad Nacional Autónoma de México, Campus Morelia
On Thu, 2005年06月02日 at 22:46 -0400, Darren Dale wrote: > Since I also have limited time, I could use epswrite for now. The resulting > figures are not fantastic on screen, (I already had smooth line art enabled > in Adobe Reader), but marginal improvements can be had by increasing the > viewer's resolution. The print version is still good. Since epswrite > basically converts the fonts to an image anyway, I would like to propose one > last time that if text.usetex is true, we draw the text as an image in eps, > just until the better solution becomes available. That way the screen version > would still look good, the entire picture would open in Adobe illustrator, > how big would the files be? > I think this is a good idea, at least to have as an available option. If you convert the text into an anti-aliased grayscale (or color) image, then you could probably get away with 150 ppi and the images would not be large at all (I assume you use something like Flate or RLE compression). After all, the fraction of the page covered by text will be small in most instances. It may actually reduce the file size since you wouldn't need all the font headers. The only problem I see is that I'm not sure how well PS supports transparent images - so I can envisage situations in which the text box might occlude other parts of the graph. > I am going to add an option to use LaTeX instead of TeX to render the text. > TeX is about 30% faster than LaTeX, but ever since John pointed out how much > the bitstream fonts suck, I cant help but notice how much the bitstream fonts > suck. Right now I am using the pslatex package, and these fonts are quite an > improvement. The txfonts package is also nice. How do people feel about two > more rc options: one to select tex or latex, and another to choose the font > package? > Yes please! I would strongly prefer LaTeX over TeX. Also, I think you really want a mechanism for the user to specify preamble commands (loading optional packages, defining macros, etc). This would obviate the need for a special command to choose the fonts. As an aside, I think mathptmx is better than txfonts if you want a Times Roman math font. The problem with txfonts is that the kernings are terrible, particularly for superscripts on brackets and the like. On the other hand, txfonts does have the "varg" option, which replaces the pointy-bottomed "v", "y" and "g" with round-bottomed versions. The pointy bottomed "v" is almost indistinguishable from a "nu", which is rather unfortunate in a formula for the Doppler shift like $\delta v / c = \delta \nu / \nu$ :) One final point. I don't understand why you are including ps2epsi in your toolchain. I thought that the "i" in "epsi" fell by the wayside over a decade ago. Are there really still any applications out there that use the %%BeginPreview ... %%EndPreview bitmap? It just seems like useless and unnecessary bloat to me. It makes tex_demo.eps from the examples/ directory 5 times larger than it need be! Best Wishes Will > -- Dr William Henney, Centro de Radioastronomía y Astrofísica, Universidad Nacional Autónoma de México, Campus Morelia
On Friday 03 June 2005 16:34, John Hunter wrote: > OK, now I am getting the ZeroDivisionError as well. These were caused > by recent changes to ticker.py. We'll get it cleared up shortly. > Well, that's a great news ! I had remorses because I didn't have the time yet today to upgrade my copy of Numeric and give another try as you adviced me yesterday... cheers, nicolas
>>>>> "Nicolas" == Nicolas Girard <nic...@ne...> writes: >> Nicolas> OK, here you are : I just ran the contour_demo.py from Nicolas> the examples directory as follows: Nicolas> $ python contour_demo.py --verbose-helpful >& Nicolas> contour.log Nicolas> You'll find the contour.log file attached to this mail. Nicolas> I'm afraid I'll have to leave you, as it's quite late Nicolas> here in France... Nicolas> Bonne nuit ! OK, now I am getting the ZeroDivisionError as well. These were caused by recent changes to ticker.py. We'll get it cleared up shortly. Thanks for letting us know... JDH
Hi, there are sometimes I change a little bit the function load to extend it a little bit and increase the speed, John didn't like it but that can be useful for some other people like you: http://sourceforge.net/mailarchive/message.php?msg_id=10836085 Regards, N. William Henney wrote: >Hi Chris > >On Thu, 2005年06月02日 at 12:28 -0400, Darren Dale wrote: > > >>>One thing you need to bear in mind if you are using TeX to >>>generate PS output is that the resultant files will probably be >>>unacceptable to many scientific journals without further processing. The >>>production staff generally try to open the PS files in Adobe Illustrator >>>and this causes multiple problems with files generated both by PyX and >>>by dvips. >>> >>> >>Why is this? >> >> >> > >The main problem was the fonts. The first thing they do as a matter of >policy is to open the file in Adobe Illustrator. This requires that the >full font be present in the file apparently (I only have this second >hand) because Illustrator allows you to edit the text of the labels. A >little bit like running a PS file through pstoedit and then editing it >with xfig I guess - that doesn't work with TeX fonts either. > >Here is the thread from when I raised the issue with the helpful folk on >comp.text.tex > >http://groups-beta.google.com/group/comp.text.tex/browse_frm/thread/d19575460c561d6b/d447807bb7813dba > >There may be a solution that does not involve converting all fonts to >paths but that was the easiest way out since I was under time-pressure >and dealing with production staff who seemed to be working from a very >limited script :) > > > >>>The solution is to convert all fonts to outlines before >>>submission (and also make sure all bbox coords are +ve). You can do this >>>with recent versions of ghostscript: >>> >>> gs -dBATCH -dNOPAUSE -dSAFER -q -sDEVICE=epswrite -dEPSFitPage \ >>> -sOutputFile=new.eps old.eps >>> >>> >>Coincidentally, I was just addressing the use of gs's epswrite this morning on >>the matplotlib-devel list. Unfortunately, epswrite will yield a file that >>does not render well on screen. Given the increasing popularity of online >>publication, it seems this approach for generating eps files would not be >>acceptable to scientific journals either. >> >> >> > >I think it looks fine so long as you turn on the "Smooth line art" >option in your PDF viewer. Unfortunately, this is not on by default in >acroread, presumably because it increases rendering times. > >If someone can come up with a foolproof way to make figures containing >TeX fonts that are acceptable to scientific journals, I, for one, would >be very grateful. > > > > >>>1. Good, flexible support for reading data from files >>> >>> >>Could you give an example? In my experience, datafiles tend to get so >>complicated that all of Matlabs tools were useless. I end up writing code >>specific to every type that isnt as simple as a few comment lines that are >>ignored followed by a delimited array of data >> >> >> > >Yes, I wasn't thinking of specialized data formats. Python already has >fine support for reading, e.g., FITS files. I was thinking more along >the lines of gnuplot's support for simple ascii data tables. E.g., easy >selection of columns to plot, single blank line indicating a gap in the >plot, double blank line indicating a new dataset, etc. This is all >trivial stuff that I can easily write myself but it would be nice if it >were a part of the plotting package (PyX does this well). It's not >really a sticking point though. > >Cheers > >Will > > > >------------------------------------------------------- >This SF.Net email is sponsored by Yahoo. >Introducing Yahoo! Search Developer Network - Create apps using Yahoo! >Search APIs Find out how you can build Yahoo! directly into your own >Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 >_______________________________________________ >Matplotlib-users mailing list >Mat...@li... >https://lists.sourceforge.net/lists/listinfo/matplotlib-users > > >
On Thursday 02 June 2005 10:46 pm, Darren Dale wrote: > > > > If someone can come up with a foolproof way to make figures containing > > TeX fonts that are acceptable to scientific journals, I, for one, would > > be very grateful. > > John has gotten us most of the way there. I think the problem I am having > embedding these LaTeX-generated eps files is related to the fact that the > postscript constructs in the image are not isolated from the main documen= t, > dvips is not creative in naming them, and therefore the font properties (= or > encoding, or something) are being corrupted. > > Since I also have limited time, I could use epswrite for now. The resulti= ng > figures are not fantastic on screen, (I already had smooth line art enabl= ed > in Adobe Reader), but marginal improvements can be had by increasing the > viewer's resolution.=20 I have some good news! This morning I discovered the ability to set the=20 resolution during the creation of an eps file with epswrite: gs -dBATCH -dNOPAUSE -dSAFER -q -r6000 -sDEVICE=3Depswrite -dLanguageLevel= =3D3 \=20 =2DdEPSFitPage -sOutputFile=3Dfoo.eps foo.ps This file can be embedded in a new latex document and it has no font=20 information so the text is rendered properly. The final output looks great= =20 when printed or viewed with Adobe Reader. I think this is the way to go. As= =20 for file size, the eps output from examples/tex_demo.py is about 50KB.=20 Sorry for all the recent noise (this discussion seems to have wandered thro= ugh=20 several threads), but I was really starting to get worried about meeting my= =20 deadlines! I'll try to commit the changes today. Darren
>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes: Steve> Why do we have self.set_double_buffered(False)? Its been Steve> that way for as long as I can remember, I think John wrote Steve> the original code, he may remember the actual reasons. The original motivation can be found in this thread http://www.daa.com.au/pipermail/pygtk/2003-May/005229.html The basic idea, if I recall correctly, was that since I was already drawing to a pixmap, I was duplicating some effort by turning on double buffering. Perhaps this reasoning wasn't correct, since we were clearly doing something wrong as evidenced by the bug report that started this discussion. JDH
John, Jeff, The attached patch for contour.py includes several minor cleanups plus one change of substance--it may require a slight change in some invocations of contourf. The change is in the handling of contour levels for contourf. Old version: a list of levels as one of the positional arguments specified the lower bound of each filled region; the upper bound of the last region was taken as a very large number. Hence, it was not possible to specify that z values between 0 and 1, for example, be filled, and that values outside that range remain unfilled. New version: a list of N levels is taken as specifying the boundaries of N-1 z ranges. Now the user has more control over what is colored and what is not. Repeated calls to contourf (with different colormaps or color specifications, for example) can be used to color different ranges of z. Values of z outside an expected range are left uncolored. Example: Old: contourf(z, [0, 1, 2]) would yield 3 regions: 0-1, 1-2, and >2. New: it would yield 2 regions: 0-1, 1-2. If the same 3 regions were desired, the equivalent list of levels would be [0, 1, 2, 1e38]. Color mapping is still based on the lower limits of the regions. Eric
On Thu, 2 Jun 2005, William Henney wrote: > On Wed, 2005年06月01日 at 13:25 -0500, John Hunter wrote: [...] > > For *Agg, we use tex + dvipng and load the output as a transparent, > > anti-aliased raster, caching the dvipng output in ~/.tex.cache for > > efficiency. For PS, we use tex + dvips + psfrag + latex + a patched > > ps2epsi. The latter is cumbersome, but it works. In an ideal world, > > we would simply use tex + dvips but embedding the postscript fragments > > generated by dvips in arbitrary locations on the figure, but this has > > proved challenging. > > Have you looked at how PyX (http://pyx.sourceforge.net/) handles things? > They have excellent support for tex/latex labels and it seems to be > implemented in a much "cleaner" way than you describe above. As far as I > can see, they run a single TeX job containing all the strings from the > current plot (see the texrunner class in pyx/text.py) and then parse the > dvi output themselves (see pyx/dvifile.py) just comment/question, which might be irrelevant, but still: would a PyX backend make sense? One approach could be to write out a python script with the PyX commands corresponding to the present graphics. (For example, one then could tweak the resulting script until the result is fine for publication...) > The big advantages matplotlib has over PyX in my opinion are a more > intuitive API and a larger/more-active developer pool and user base. Creating plots using PyX tends to need more code than with matplotlib. On the other hand PyX is *very* flexible which is reflected in its design. OTOH, the quality of PyX generated graphics exceeds anything else I have looked at in more detail. Also, it is easily possible to change the fonts and their size (+ linewidths, colors etc.) depending on whether one needs a graphics for inclusion into a publication (e.g. computer modern roman font) or a presentation (e.g. cmbright family) so that graphics and the text around it match nicely. The wish of a "front-end" to PyX did come up on the PyX mailing list, if I remember correctly. So maybe using a matplotlib+PyX-backend combination would be something useful. Best wishes, Arnd
Steve, thanks for your long reply. I think I know understand the way it works. Steve Chaplin schrieb: > [...] > expose-events: > If the window is resized or draw() is called self._draw_pixmap is set to > True and the whole figure is redrawn to the Pixmap. > self.window.set_back_pixmap() is then called to set the window > background to the Pixmap. Then if an expose event occurs, without the > window being resized or draw() being called, matplotlib does not need to > do anything. GTK+ handles it for us by automatically filling an exposed > window with its background, which is our plot. > > This is how it works for GTK+/PyGTK 2.4. However, something changed in > 2.6 and it no longer always draws the widgets background. I think this > is a bug, however after rereading the gdk_window_set_back_pixmap() > manual page I notice it says: > "The windowing system will normally fill a window with its background > when the window is obscured then exposed, and when you call > gdk_window_clear()" I read that part too, but didn not quite understand it before you explained the part about set_back_pixmap(). > What is "normally" supposed to mean? It not something you can rely on, > so it may just as well be "never". I think that the documentation is > unclear and opened a documentation bug report > http://bugzilla.gnome.org/show_bug.cgi?id=306214 > > I also found a bug report very similar to the problem experienced in > matplotlib > http://bugzilla.gnome.org/show_bug.cgi?id=161561 > its been resolved as 'fixed', so GTK+ 2.6.1 (with the fix applied) may > work OK, and it may just have been a 2.6.0 problem. Hmmm. The buggy behaviour I noticed was on a machine running pygtk 2.6.1 and gtk+-2.6.4, so I am not so sure if it was a 2.6.0 problem. Niklas Volbers.