Re: [matplotlib-devel] ginput in nbagg backend to use in IPython Notebooks
Thanks, Tom.
I want to use ginput to draw a straight line on a graph.
The line is used to select a cross-section of a contour plot.
I was afraid it wasn't going to be easy.
Getting to it from the other side, is there a matplotlib widget in the
works where I can type text or numbers in a box? Like the FloatTextWidget
in IPython?
Problem is I want to make a small GUI that includes both a text widget
(which is available in IPython) and a 'select points in graph' widget like
ginput in matplotlib.
Mark
On Mon, Jan 26, 2015 at 11:47 PM, Thomas Caswell wrote:
> nbagg is always running in the IPython event loop (as I understand it), so
> I am not sure how to integrate that with the blocking.
>
> On the 1.4.x/master branch we have support for (almost, one PR still
> pending) all mouse and keyboard events so all of the mpl widgets should
> work (big thanks to Steven Silvester). T
>
> What do you want to use that relies on ginput?
>
> You can fake up a non-blocking version something like:
>
> from collections import deque
> ```
> class accumulator(object):
> def __init__(self, n=5):
> self.list_of_points = deque(maxlen=n)
>
> def on_event(self, event):
> self.list_of_points.append(event)
>
> import matplotlib
> import itertools
> import numpy as np
> matplotlib.use('nbagg')
> import matplotlib.pyplot as plt
> plt.close('all')
> fig, ax = plt.subplots()
> x = np.linspace(0,10,1)
> y = np.sin(x)
> ln, = ax.plot(x,y)
>
> dd = accumulator(15)
> fig.canvas.mpl_connect('button_press_event', dd.on_event)
> plt.show()
> ```
>
> and then get the points by
>
> ```
> dd.lest_of_points
> ```
>
> This code obviously needs lots of bells and whistles, but points in the
> right direction.
>
> Tom
>
> On Mon Jan 26 2015 at 2:45:45 PM Mark Bakker wrote:
>
>> Hello List,
>>
>> Are there any plans to make ginput work in the nbagg backend?
>>
>> It would be so cool if I could use that in an IPython Notebook together
>> with the other widgets.
>>
>> Thanks,
>>
>> Mark
>>
>> --
>>
>
--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] ginput in nbagg backend to use in IPython Notebooks
Hello List, Are there any plans to make ginput work in the nbagg backend? It would be so cool if I could use that in an IPython Notebook together with the other widgets. Thanks, Mark -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] xkcd doesn't seem to work in MacOSX backend
Like I said, it works fine when I select the QT backend. So I have a workaround. I was just wondering wether it was supposed to work with the MacOSX backend. Does anybody know? If so, I'll file a bug report. Mark On Tue, Nov 18, 2014 at 6:55 PM, Phil Elson wrote: > Isn't the XKCD stuff baked into the Agg backend. Is it even possible to > produce XKCD svg or PDFs? > > On 18 November 2014 17:01, Jens Nielsen wrote: > >> I can reproduce it with the following traceback. Can you please open a >> bug report on Github for this issue? >> >> ``` >> Traceback (most recent call last): >> File "/usr/local/lib/python2.7/site-packages/matplotlib/artist.py", >> line 59, in draw_wrapper >> draw(artist, renderer, *args, **kwargs) >> File "/usr/local/lib/python2.7/site-packages/matplotlib/figure.py", >> line 1079, in draw >> func(*args) >> File "/usr/local/lib/python2.7/site-packages/matplotlib/artist.py", >> line 59, in draw_wrapper >> draw(artist, renderer, *args, **kwargs) >> File "/usr/local/lib/python2.7/site-packages/matplotlib/axes/_base.py", >> line 2092, in draw >> a.draw(renderer) >> File "/usr/local/lib/python2.7/site-packages/matplotlib/artist.py", >> line 59, in draw_wrapper >> draw(artist, renderer, *args, **kwargs) >> File "/usr/local/lib/python2.7/site-packages/matplotlib/lines.py", line >> 712, in draw >> drawFunc(renderer, gc, tpath, affine.frozen()) >> File "/usr/local/lib/python2.7/site-packages/matplotlib/lines.py", line >> 1067, in _draw_lines >> self._lineFunc(renderer, gc, path, trans) >> File "/usr/local/lib/python2.7/site-packages/matplotlib/lines.py", line >> 1107, in _draw_solid >> renderer.draw_path(gc, path, trans) >> File >> "/usr/local/lib/python2.7/site-packages/matplotlib/patheffects.py", line >> 115, in draw_path >> rgbFace) >> File >> "/usr/local/lib/python2.7/site-packages/matplotlib/patheffects.py", line >> 217, in draw_path >> renderer.draw_path(gc, tpath, affine, rgbFace) >> File >> "/usr/local/lib/python2.7/site-packages/matplotlib/backends/backend_macosx.py", >> line 58, in draw_path >> gc.draw_path(path, transform, linewidth, rgbFace) >> AttributeError: GraphicsContextBase instance has no attribute 'draw_path' >> ``` >> >> best >> Jens >> >> On Tue, Nov 18, 2014 at 4:12 PM, Mark Bakker wrote: >> >>> Sorry, forgot to mention that: 1.4.0 >>> >>> On Tue, Nov 18, 2014 at 5:00 PM, Benjamin Root wrote: >>> >>>> Which version of matplotlib are you using? >>>> >>>> On Tue, Nov 18, 2014 at 10:55 AM, Mark Bakker >>>> wrote: >>>> >>>>> Hello list, >>>>> >>>>> I don't seem to get xkcd to work in the MacOSX backend. When I try to >>>>> make a plot I get a nice white figure with nothing on it. Here's what I >>>>> did: >>>>> >>>>> import matplotlib.pyplot as plt >>>>> %matplotlib # responds with Using matplotlib backend: MacOSX >>>>> plt.plot([1,2,3]) # gives white figure with nothing on it >>>>> >>>>> When I do a kernel restart and specify the qt backend it works fine >>>>> (so I have a workaround), but I presume it should work, right? >>>>> >>>>> Thanks, >>>>> >>>>> Mark >>>>> >>>>> >>>>> >>>>> -- >>>>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server >>>>> from Actuate! Instantly Supercharge Your Business Reports and >>>>> Dashboards >>>>> with Interactivity, Sharing, Native Excel Exports, App Integration & >>>>> more >>>>> Get technology previously reserved for billion-dollar corporations, >>>>> FREE >>>>> >>>>> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk >>>>> ___ >>>>> Matplotlib-devel mailing list >>>>> Matplotlib-devel@lists.sourceforge.net >>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >>>>> >>>>> >>>> >>> >>> >>>
Re: [matplotlib-devel] xkcd doesn't seem to work in MacOSX backend
Sorry, forgot to mention that: 1.4.0 On Tue, Nov 18, 2014 at 5:00 PM, Benjamin Root wrote: > Which version of matplotlib are you using? > > On Tue, Nov 18, 2014 at 10:55 AM, Mark Bakker wrote: > >> Hello list, >> >> I don't seem to get xkcd to work in the MacOSX backend. When I try to >> make a plot I get a nice white figure with nothing on it. Here's what I did: >> >> import matplotlib.pyplot as plt >> %matplotlib # responds with Using matplotlib backend: MacOSX >> plt.plot([1,2,3]) # gives white figure with nothing on it >> >> When I do a kernel restart and specify the qt backend it works fine (so I >> have a workaround), but I presume it should work, right? >> >> Thanks, >> >> Mark >> >> >> >> -- >> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server >> from Actuate! Instantly Supercharge Your Business Reports and Dashboards >> with Interactivity, Sharing, Native Excel Exports, App Integration & more >> Get technology previously reserved for billion-dollar corporations, FREE >> >> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk >> ___ >> Matplotlib-devel mailing list >> Matplotlib-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> >> > -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] xkcd doesn't seem to work in MacOSX backend
Hello list, I don't seem to get xkcd to work in the MacOSX backend. When I try to make a plot I get a nice white figure with nothing on it. Here's what I did: import matplotlib.pyplot as plt %matplotlib # responds with Using matplotlib backend: MacOSX plt.plot([1,2,3]) # gives white figure with nothing on it When I do a kernel restart and specify the qt backend it works fine (so I have a workaround), but I presume it should work, right? Thanks, Mark -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] problems with shared axis
Dang, I looked at it, but so much has changed since 0.98.3 release that I have little chance of getting any changes implemented. Any plans for a new release that you know of? Thanks, Mark On Mon, Oct 27, 2008 at 7:29 PM, Eric Firing <[EMAIL PROTECTED]> wrote: > Mark Bakker wrote: > >> I was gone for the weekend (sorry, but that 'life' thing gets in the way >> of getting things done sometimes). I don't have a way to build stuff at the >> moment. Can I just check out the axes.py and replace my current one, or are >> there too many changes? >> > > The changes were in ticker.py and axes.py. Whether plugging in the current > versions would work depends on the age of the other files you have. If you > have a fairly recent svn build, then updating those two files probably would > work. You could use svn to get the diffs specifically for my changes > related to shared axes. > > Eric > > >> Mark >> >> >> On Fri, Oct 24, 2008 at 7:57 AM, Eric Firing <[EMAIL PROTECTED] > [EMAIL PROTECTED]>> wrote: >> >>Mark Bakker wrote: >> >>Hello list (especially Erik, who can fix this I hope) - >> >>I have had problems with shared axes, especially when one of the >>axis has an aspect ratio that is set 'equal'. It has been >>discussed on the list before (mostly with Erik Firing), but it >>hasn't been fixed yet. What I want to do is have two plots. The >>top plot has an aspect ratio that is 'equal'. The idea is to >>have a contour plot in the top figure, while the bottom figure >>gives a cross-sectional picture of what I am plotting. This used >>to work well (quite some time ago), including zooming and such. >>But now I cannot plot it at all, let alone zoom. >> >>My first problem is when I add a subplot with a shared x-axis, >>it changes the limits on the original x-axis. That seems to be a >>bug: >>ax1 = subplot(211) >>plot([1,2,3]) # Now the limits of the x-axis go from 0 to 2. >>subplot(212,sharex=ax1) # Now the limits of both x-axis go from >>0 to 1. >> >>After all, the new subplot shares the axis with the existing >>subplot, so why doesn't it copy the axis limits from that subplot? >> >>But the bigger problem occurs when I want the aspect ratio of >>one of the first axis to be 'equal'. >> >>ax1 = subplot(211,aspect='equal') >>plot([1,2,3]) subplot(212,sharex=ax1) >> >> >>Mark, >> >>I made some more changes so that the above works by changing the >>adjustable to 'datalim'. Have I broken anything? Does this work >>for your applications? >> >>Eric >> >> >>The second subplot is added, but the length of the graph is not >>the same as for the first subplot. It also resets the xlimits to >>go from 0 to 1, as before, which means the first subplot becomes >>unreadable (it still enforces 'equal' in the first subplot by >>changing the limits of the y-axis). When I now change the limits >>on the x-axis, the aspect ratio is not equal anymore >> >>ax1.set_xlim(0,2) >>draw() >> >>Thanks for your help. I am willing to help in testing any changes. >> >>Best regards, Mark >> >> >> >> >> >> >> >> - >>This SF.Net email is sponsored by the Moblin Your Move >>Developer's challenge >>Build the coolest Linux based applications with Moblin SDK & win >>great prizes >>Grand prize is a trip for two to an Open Source event anywhere >>in the world >>http://moblin-contest.org/redirect.php?banner_id=100&url=/ >><http://moblin-contest.org/redirect.php?banner_id=100&url=/> >> >> >> >> >> >>___ >>Matplotlib-devel mailing list >>Matplotlib-devel@lists.sourceforge.net >><mailto:Matplotlib-devel@lists.sourceforge.net> >>https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> >> >> >> > - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] problems with shared axis
I was gone for the weekend (sorry, but that 'life' thing gets in the way of getting things done sometimes). I don't have a way to build stuff at the moment. Can I just check out the axes.py and replace my current one, or are there too many changes? Mark On Fri, Oct 24, 2008 at 7:57 AM, Eric Firing <[EMAIL PROTECTED]> wrote: > Mark Bakker wrote: > >> Hello list (especially Erik, who can fix this I hope) - >> >> I have had problems with shared axes, especially when one of the axis has >> an aspect ratio that is set 'equal'. It has been discussed on the list >> before (mostly with Erik Firing), but it hasn't been fixed yet. What I want >> to do is have two plots. The top plot has an aspect ratio that is 'equal'. >> The idea is to have a contour plot in the top figure, while the bottom >> figure gives a cross-sectional picture of what I am plotting. This used to >> work well (quite some time ago), including zooming and such. But now I >> cannot plot it at all, let alone zoom. >> >> My first problem is when I add a subplot with a shared x-axis, it changes >> the limits on the original x-axis. That seems to be a bug: >> ax1 = subplot(211) >> plot([1,2,3]) # Now the limits of the x-axis go from 0 to 2. >> subplot(212,sharex=ax1) # Now the limits of both x-axis go from 0 to 1. >> >> After all, the new subplot shares the axis with the existing subplot, so >> why doesn't it copy the axis limits from that subplot? >> >> But the bigger problem occurs when I want the aspect ratio of one of the >> first axis to be 'equal'. >> >> ax1 = subplot(211,aspect='equal') >> plot([1,2,3]) subplot(212,sharex=ax1) >> > > Mark, > > I made some more changes so that the above works by changing the adjustable > to 'datalim'. Have I broken anything? Does this work for your > applications? > > Eric > > >> The second subplot is added, but the length of the graph is not the same >> as for the first subplot. It also resets the xlimits to go from 0 to 1, as >> before, which means the first subplot becomes unreadable (it still enforces >> 'equal' in the first subplot by changing the limits of the y-axis). When I >> now change the limits on the x-axis, the aspect ratio is not equal anymore >> >> ax1.set_xlim(0,2) >> draw() >> >> Thanks for your help. I am willing to help in testing any changes. >> >> Best regards, Mark >> >> >> >> >> >> - >> This SF.Net email is sponsored by the Moblin Your Move Developer's >> challenge >> Build the coolest Linux based applications with Moblin SDK & win great >> prizes >> Grand prize is a trip for two to an Open Source event anywhere in the >> world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> >> >> >> >> ___ >> Matplotlib-devel mailing list >> Matplotlib-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> > > - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] problems with shared axis
Thanks Eric. You know that this has been on my wish list for a long time. Let me know if I can test anything or help in any other way, Mark On Wed, Oct 22, 2008 at 10:54 AM, Eric Firing <[EMAIL PROTECTED]> wrote: > Mark Bakker wrote: > >> Hello list (especially Erik, who can fix this I hope) - >> >> I have had problems with shared axes, especially when one of the axis has >> an aspect ratio that is set 'equal'. It has been discussed on the list >> before (mostly with Erik Firing), but it hasn't been fixed yet. What I want >> to do is have two plots. The top plot has an aspect ratio that is 'equal'. >> The idea is to have a contour plot in the top figure, while the bottom >> figure gives a cross-sectional picture of what I am plotting. This used to >> work well (quite some time ago), including zooming and such. But now I >> cannot plot it at all, let alone zoom. >> >> My first problem is when I add a subplot with a shared x-axis, it changes >> the limits on the original x-axis. That seems to be a bug: >> ax1 = subplot(211) >> plot([1,2,3]) # Now the limits of the x-axis go from 0 to 2. >> subplot(212,sharex=ax1) # Now the limits of both x-axis go from 0 to 1. >> >> After all, the new subplot shares the axis with the existing subplot, so >> why doesn't it copy the axis limits from that subplot? >> > > I may have the fix for this, but I need more time to check and refine > it--and try to make sure that I don't break anything else in the process. > > >> But the bigger problem occurs when I want the aspect ratio of one of the >> first axis to be 'equal'. >> >> ax1 = subplot(211,aspect='equal') >> plot([1,2,3]) subplot(212,sharex=ax1) >> >> The second subplot is added, but the length of the graph is not the same >> as for the first subplot. It also resets the xlimits to go from 0 to 1, as >> before, which means the first subplot becomes unreadable (it still enforces >> 'equal' in the first subplot by changing the limits of the y-axis). When I >> now change the limits on the x-axis, the aspect ratio is not equal anymore >> >> > I will see what I can do. There are definitely some bugs that need to be > squashed. > > Eric > > > ax1.set_xlim(0,2) >> draw() >> >> Thanks for your help. I am willing to help in testing any changes. >> >> Best regards, Mark >> > - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] problems with shared axis
Hello list (especially Erik, who can fix this I hope) - I have had problems with shared axes, especially when one of the axis has an aspect ratio that is set 'equal'. It has been discussed on the list before (mostly with Erik Firing), but it hasn't been fixed yet. What I want to do is have two plots. The top plot has an aspect ratio that is 'equal'. The idea is to have a contour plot in the top figure, while the bottom figure gives a cross-sectional picture of what I am plotting. This used to work well (quite some time ago), including zooming and such. But now I cannot plot it at all, let alone zoom. My first problem is when I add a subplot with a shared x-axis, it changes the limits on the original x-axis. That seems to be a bug: ax1 = subplot(211) plot([1,2,3]) # Now the limits of the x-axis go from 0 to 2. subplot(212,sharex=ax1) # Now the limits of both x-axis go from 0 to 1. After all, the new subplot shares the axis with the existing subplot, so why doesn't it copy the axis limits from that subplot? But the bigger problem occurs when I want the aspect ratio of one of the first axis to be 'equal'. ax1 = subplot(211,aspect='equal') plot([1,2,3]) subplot(212,sharex=ax1) The second subplot is added, but the length of the graph is not the same as for the first subplot. It also resets the xlimits to go from 0 to 1, as before, which means the first subplot becomes unreadable (it still enforces 'equal' in the first subplot by changing the limits of the y-axis). When I now change the limits on the x-axis, the aspect ratio is not equal anymore ax1.set_xlim(0,2) draw() Thanks for your help. I am willing to help in testing any changes. Best regards, Mark - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] problems with labeling contour lines in 0.98.3
Hello David - Sorry for the late reply. I am back from vacation. Any luck on solving the problem of the disappearing contour lines when labelling? It works fine when you don't use the 'inline', but the picture is of course not as nice, as the labels are not in-line anymore. Maybe that gives a clue to what goes wrong? Thanks, Mark On Wed, Sep 3, 2008 at 12:47 PM, David M. Kaplan <[EMAIL PROTECTED]>wrote: > Hi, > > Back from vacation. The problem with not being able to end point > selection is easy to fix - allow keyboard clicks to also select points > and enter to also exit (this is the solution matlab uses). This is easy > to add and I will try to work on it sometime over the next couple of > weeks. > > I will try your example sometime soon and see what happens. It sounds > like the problem has something to do with what happens when the label > covers the entire contour - currently the contour gets deleted entirely, > but this seems to be doing something strange in your case. > > Cheers, > David > > > On Thu, 2008-08-21 at 16:02 +0200, Mark Bakker wrote: > > David - > > > > Enjoy your vacation. > > > > I tried the contour_label_demo and it works fine, but my problem > > remains. > > > > I suggest you try the example I provided below, and notice the > > difference between labeling with inline=True and inline=False. When > > inline=True the contours in the middle part (which don't get labeled, > > presumably because there isn't enough room) get erased. > > > > I figured out the manual input problem. The trick is that you require > > to press the middle button to end (I'll do a post to the user's list). > > Many laptops don't have a middle button. Although suggestions are > > found on the web that pushing both buttons simultaneously works, I > > have never seen it work. What you have to do is configure your > > touchpad such that a corner acts as the middle button. Once I figured > > that out, I could end manually selecting the labels. Very nice. If I > > may, I strongly recommend you change the code such that pushing the > > right button ends the manual input. Is there any reason not to use the > > right button for that? > > > > I hope you can fix the inline problem. Thanks for all the other new > > cool features, > > > > Mark > > > > On Tue, Aug 19, 2008 at 4:06 PM, <[EMAIL PROTECTED]> wrote: > > Hi, > > > > I am currently on vacation, so I can´t be of much help - back > > beginning of next month. It would be useful if > > you could try the clabel and ginput demo scripts and send > > images of the resulting figures so that we can determine > > exactly what things work and don´t work. > > > > Thanks, > > David > > > > > > > > Mark Bakker <[EMAIL PROTECTED]> ha escrito: > > > > > > > > Hello David and the developers list- > > > > I have had little luck on the mailing list, so sorry > > for writing you > > directly (David may be on vacation). > > > > I have two problems labeling contour lines in 0.98.3. > > > > First, when I call clabel, it removes all contours > > that are not labeled > > (because the label doesn't fit on the section of > > contour, I presume). > > This seems like a bug to me (or a really odd feature). > > It doesn't do this > > when inline = False, but I don't think it should do it > > either when inline = > > True > > Easy example: > > > > x,y = > > meshgrid( linspace(-10,10,50), > > linspace(-10,10,50) ) > > z = log(x**2 + y**2) > > cobj = contour(x,y,z) # Note > > that there are 8 contours > > levels (11 > > contour sections in all) > > cobj.clabel() > > > > draw() # Now only 5 contours > > are drawn; the ones in the > >
Re: [matplotlib-devel] problems with labeling contour lines in 0.98.3
David - Enjoy your vacation. I tried the contour_label_demo and it works fine, but my problem remains. I suggest you try the example I provided below, and notice the difference between labeling with inline=True and inline=False. When inline=True the contours in the middle part (which don't get labeled, presumably because there isn't enough room) get erased. I figured out the manual input problem. The trick is that you require to press the middle button to end (I'll do a post to the user's list). Many laptops don't have a middle button. Although suggestions are found on the web that pushing both buttons simultaneously works, I have never seen it work. What you have to do is configure your touchpad such that a corner acts as the middle button. Once I figured that out, I could end manually selecting the labels. Very nice. If I may, I strongly recommend you change the code such that pushing the right button ends the manual input. Is there any reason not to use the right button for that? I hope you can fix the inline problem. Thanks for all the other new cool features, Mark On Tue, Aug 19, 2008 at 4:06 PM, <[EMAIL PROTECTED]> wrote: > Hi, > > I am currently on vacation, so I can´t be of much help - back beginning of > next month. It would be useful if > you could try the clabel and ginput demo scripts and send images of the > resulting figures so that we can determine exactly what things work and > don´t work. > > Thanks, > David > > > > Mark Bakker <[EMAIL PROTECTED]> ha escrito: > > > Hello David and the developers list- >> >> I have had little luck on the mailing list, so sorry for writing you >> directly (David may be on vacation). >> >> I have two problems labeling contour lines in 0.98.3. >> >> First, when I call clabel, it removes all contours that are not labeled >> (because the label doesn't fit on the section of contour, I presume). >> This seems like a bug to me (or a really odd feature). It doesn't do this >> when inline = False, but I don't think it should do it either when inline >> = >> True >> Easy example: >> >> x,y = meshgrid( linspace(-10,10,50), linspace(-10,10,50) ) >>>>> z = log(x**2 + y**2) >>>>> cobj = contour(x,y,z) # Note that there are 8 contours levels (11 >>>>> >>>> contour sections in all) >> >>> cobj.clabel() >>>>> >>>> >> >>> draw() # Now only 5 contours are drawn; the ones in the middle are >>>>> >>>> removed. >> >> Second, when using the new manual labeling of contour labels (which is >> pretty neat!), how do I end this feature? >> The doc string says: right click, or potentially click both mouse buttons >> together (which already worries me). >> Neither works for me on win32, mpl 0.98.3, TkAgg backend, interactive >> mode. >> Does anybody have a solution? >> >> Thanks, Mark >> >> > > > > This message was sent using IMP, the Internet Messaging Program. > > - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] problems with labeling contour lines in 0.98.3
Hello David and the developers list- I have had little luck on the mailing list, so sorry for writing you directly (David may be on vacation). I have two problems labeling contour lines in 0.98.3. First, when I call clabel, it removes all contours that are not labeled (because the label doesn't fit on the section of contour, I presume). This seems like a bug to me (or a really odd feature). It doesn't do this when inline = False, but I don't think it should do it either when inline = True Easy example: >>> x,y = meshgrid( linspace(-10,10,50), linspace(-10,10,50) ) >>> z = log(x**2 + y**2) >>> cobj = contour(x,y,z) # Note that there are 8 contours levels (11 contour sections in all) >>> cobj.clabel() >>> draw() # Now only 5 contours are drawn; the ones in the middle are removed. Second, when using the new manual labeling of contour labels (which is pretty neat!), how do I end this feature? The doc string says: right click, or potentially click both mouse buttons together (which already worries me). Neither works for me on win32, mpl 0.98.3, TkAgg backend, interactive mode. Does anybody have a solution? Thanks, Mark - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] The new logo (was: future of mpl documentation)
I agree that the new logo looks nice, but I also think that Rob is right: When you see the logo you wouldn't know that we are talking about a general purpose plotting package. So the question is: are we going for looks over meaning? I guess the other way around would be terrible: choosing meaning over looks you are stuck with an ugly logo that carries the right message. So to me, looks it is, Mark > On Jun 1, 2008, at 9:47 AM, Rob Hetland wrote: > > > > 2. I like the figure to the side (and agree that there should be > > only one), but it seems that polar plots are more rarely used than > > normal x-y plots. Perhaps an x-y plot (the histogram, for example) > > would be better advertising. > > I was the one who originally chose the polar plot. I admit, it was > mainly for aesthetics. Here are a few reasons: > > * I think a circular plot works better on the logo than a rectangular > plot would. > * The polar plot is one of the more attractive plots in the examples. > * It's a plotting featuring that most plotting software wouldn't have > so it seems to differentiate matplotlib from other plotting software. > > Originally, it wasn't a big deal because there were other plots in the > logo. Still, I'd be in favor of keeping the polar plot for aesthetic > reasons. > > Great, now I'm that guy who's arguing for looks over practicality. :( > > -Tony > - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] new release?
That fixes it on my machine.
Except that the function GetRealpathAndStat is in cbook.py (I don't even
have a mplutil.py file).
Thanks,
Mark
On Tue, May 13, 2008 at 7:21 PM, Michael Droettboom <[EMAIL PROTECTED]> wrote:
> I suspect on Windows it is safe enough (in most cases) to use the realpath
> as the key, in lieu of anything better. But that would require testing on
> Windows to make sure. Can you try replacing the GetRealpathAndStat in
> mplutil.py with the following?
>
> class GetRealpathAndStat:
> def __init__(self):
> self._cache = {}
>
> def __call__(self, path):
> result = self._cache.get(path)
> if result is None:
> realpath = os.path.realpath(path)
> if sys.platform == "win32":
> stat_key = realpath
> else:
> stat = os.stat(realpath)
> stat_key = (stat.st_ino, stat.st_dev)
> result = realpath, stat_key
> self._cache[path] = result
> return result
> get_realpath_and_stat = GetRealpathAndStat()
>
>
> Cheers,
> Mike
>
> Mark Bakker wrote:
>
> > John, Michael -
> >
> > Now that we are talking about a new release, did you guys ever manage to
> > fix the bug described below. It had to do with greek symbols not showing up
> > in postscript files on windows. John seemed to have tracked down the source
> > of the problem, but I never heard of a solution.
> >
> > Thanks,
> >
> > Mark
> >
> > On Tue, Mar 25, 2008 at 7:50 PM, John Hunter <[EMAIL PROTECTED] > [EMAIL PROTECTED]>> wrote:
> >
> >On Tue, Mar 25, 2008 at 12:02 PM, Michael Droettboom
> ><[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
> >
> >> The *intention* is that the fonts *should* be included (with the
> >> exception of ps.useafm == True). That was definitely not a
> >deliberate
> >> change.
> >>
> >> However, as one of the ones who hasn't been able to reproduce this
> >> problem, I'm afraid I'm not of much help. From reading the
> >code, I'm
> >> still completely stumped as to why the font is not embedded.
> > Someone
> >> will have to step through with a debugger on one of the broken
> >systems
> >> to figure this out, I'm afraid.
> >
> >I was able to replicate the bug and find the source of the problem.
> > I
> >am not 100% sure how to fix it, but someone who knows os.stat better
> >might. The problem is that matplotlib.cbook.get_realpath_and_stat
> >
> >class GetRealpathAndStat:
> > def __init__(self):
> > self._cache = {}
> >
> > def __call__(self, path):
> > result = self._cache.get(path)
> > if result is None:
> > realpath = os.path.realpath(path)
> > stat = os.stat(realpath)
> > stat_key = (stat.st_ino, stat.st_dev)
> > result = realpath, stat_key
> > self._cache[path] = result
> > return result
> >get_realpath_and_stat = GetRealpathAndStat()
> >
> >
> >is returning the same stat ino and dev for all the font files, and
> >thus the renderer.used_characters dictionary is getting improper keys
> >-- always (0,0). So the first font in the gate, in this case Vera,
> > is
> >getting a place in the dict and subsequent fonts (the cm* ones) are
> >not. The basic problem is that the inode and dev appear to be unix
> >only.
> >
> >Michael: if you let me know better what this key is supposed to be
> >doing (can we not simply use the filename for windows?) then I can
> >attempt or test some fixes.
> >
> >JDH
> >
> >
> >
> --
> Michael Droettboom
> Science Software Branch
> Operations and Engineering Division
> Space Telescope Science Institute
> Operated by AURA for NASA
>
>
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] new release?
John, Michael -
Now that we are talking about a new release, did you guys ever manage to fix
the bug described below. It had to do with greek symbols not showing up in
postscript files on windows. John seemed to have tracked down the source of
the problem, but I never heard of a solution.
Thanks,
Mark
On Tue, Mar 25, 2008 at 7:50 PM, John Hunter <[EMAIL PROTECTED]> wrote:
> On Tue, Mar 25, 2008 at 12:02 PM, Michael Droettboom <[EMAIL PROTECTED]>
> wrote:
>
> > The *intention* is that the fonts *should* be included (with the
> > exception of ps.useafm == True). That was definitely not a deliberate
> > change.
> >
> > However, as one of the ones who hasn't been able to reproduce this
> > problem, I'm afraid I'm not of much help. From reading the code, I'm
> > still completely stumped as to why the font is not embedded. Someone
> > will have to step through with a debugger on one of the broken systems
> > to figure this out, I'm afraid.
>
> I was able to replicate the bug and find the source of the problem. I
> am not 100% sure how to fix it, but someone who knows os.stat better
> might. The problem is that matplotlib.cbook.get_realpath_and_stat
>
> class GetRealpathAndStat:
>def __init__(self):
>self._cache = {}
>
>def __call__(self, path):
>result = self._cache.get(path)
>if result is None:
>realpath = os.path.realpath(path)
>stat = os.stat(realpath)
>stat_key = (stat.st_ino, stat.st_dev)
>result = realpath, stat_key
>self._cache[path] = result
>return result
> get_realpath_and_stat = GetRealpathAndStat()
>
>
> is returning the same stat ino and dev for all the font files, and
> thus the renderer.used_characters dictionary is getting improper keys
> -- always (0,0). So the first font in the gate, in this case Vera, is
> getting a place in the dict and subsequent fonts (the cm* ones) are
> not. The basic problem is that the inode and dev appear to be unix
> only.
>
> Michael: if you let me know better what this key is supposed to be
> doing (can we not simply use the filename for windows?) then I can
> attempt or test some fixes.
>
> JDH
>
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] bug in mathtext eps output
I am trying this problem on the developer's list. Whenever I type a greek symbol in mathtext and save the figure as eps, the greek symbols don't show up in the eps file. Confirmed on several windows machines. Python 2.4. mpl 0.91.2. (but it worked fine under 0.90.1). Does anybody else have this problem? It worked for mpl 0.90.1. Has something changed in mathtext that causes this? Mark Bakker - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Problem with Agg Ellipses
Tedd, Michael - Sorry to join this discussion late, but wouldn't it be easier to use a representation of an ellipse in complex variables? That's what I have been using and it seems pretty quick to me. Have you guys tried this? Any experience you want to share? Mark - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] new location of home.ppm
Hello - It seems that in the latest version (0.9.1) the location of the images, such as home.ppm, has moved to a new directory. It used to be in ...\mpl-data and now it is in ...\mpl-data\images This totally breaks my code, as I use my own toolbar that uses these images, with a hardcoded location of the ppm files. I know, I should from now on distribute these ppm files with the distribution of my own program, but there may be others that have this problem. Not sure what the best solution is. WIll it remain in this new images directory from now on? Thanks, Mark ps. Cross-posted on the users and development list ps2. Sorry, it sounds like I am bitching, but I really like matplotlib. Just needed to point out this backwards incompatibility, which may just be ugly coding on my part - 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://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Inches?
Just to clarify: the OFFICIAL definition of an inch is 2.54 cm. So rounding errors shouldn't be much of a problem. > Date: Mon, 29 Oct 2007 09:37:06 -0400 > From: Michael Droettboom <[EMAIL PROTECTED]> > > I agree that we have to remain in inches internally. Non-metric units > are pretty ingrained in the printing world (not just in matplotlib) -- > Postscript, for example, always does page sizes in inches, even if > you're using a "metric" page size like A4. The current definition of a > point as 1/72 of a modern inch is also fairly standard worldwide. Even > printers in France, for example, are spec'd in points par pouce (ppp), > which is exactly equivalent to dots per inch (dpi). > > However, that's just an implementation detail we have to stick with. > Matplotlib has Figure.get/set_size_inches now. What's to stop us from > adding get/set_size_cm, and doing the conversion right there? There > might be some rounding error, but I don't think it matters in this > particular case. We would probably also want to add a "figsize_cm" > kwarg to the Figure constructor (which would be mutually exclusive to > "figsize"). What do you think? > > Cheers, > Mike > > - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] SaveFig bug in TkAgg backend
Excellent, Perry. Thanks for your help, Mark On 5/18/07, Perry Greenfield <[EMAIL PROTECTED]> wrote: We don't have anyone at the moment that can work on it, but I think on the order of a month or two we can. We see similar issues too. So if someone can deal with it before then, that would be great, but we'll tackle it before very long if not. Perry On May 18, 2007, at 7:21 AM, Mark Bakker wrote: > This is a well known problem, reported about a year or so ago. > John Hunter tried to get some help on the (TK?) mailinglist, but I > don't think anybody responded. I looked into it too, but couldn't find > a solution (that doesn't mean much, except for that it is not > blatently obvious). > It would be great if somebody would know how to fix this. > Strangely enough I have written a GUI myself where I use the toolbar, > and the save button works fine there. > Mark - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] SaveFig bug in TkAgg backend
This is a well known problem, reported about a year or so ago. John Hunter tried to get some help on the (TK?) mailinglist, but I don't think anybody responded. I looked into it too, but couldn't find a solution (that doesn't mean much, except for that it is not blatently obvious). It would be great if somebody would know how to fix this. Strangely enough I have written a GUI myself where I use the toolbar, and the save button works fine there. Mark > Date: Thu, 10 May 2007 13:31:18 -0600 > From: "Urvashi R.V." <[EMAIL PROTECTED]> > > Hi, > > When the "save" button is used on the matplotlib tkagg toolbar, it > uses the "Tk" "asksavefilename" object from the "tkFileDialog" class, > to pop up a little window that allows you to select the name and type > of file to save.This function internally calls "figure.destroy()". > and the currently active figure gets destroyed (but it is still visible > and memory is not freed). The next plot then creates a new figure > window with the same figure._num as the previous. > > see... > backend_tkagg.py : line 621 > -> class NavigationToolbar2TkAgg :: def save_figure(...) > (callback for the toolbar.bsave button) > > The "asksavefilename" function call, triggers Gcf.destroy(). This can > be seen by placing a print statement in > _pylab_helpers.py : line 16 > -> class Gcf :: def destroy(num) - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Bug(?) in FancyArrow overhang
Hello list - I tried this on the user's list, but didn't get a response. I am afraid it is a bug. I am trying to use FancyArrow to draw an arrow with given length. The length I use is from 0 to 100. I specify length_includes_head=True. This works fine when I specify a width and length. But when I specify an overhang, the length of the arrow becomes much longer than 100. Am I using overhang incorrectly? Here's a script with the problem: from pylab import * from matplotlib.patches import FancyArrow axis([0,120,0,100]) ax = gca() a = FancyArrow( 0, 40, 100, 0, length_includes_head=True, head_width=5, head_length=5) ax.add_patch(a) b = FancyArrow( 0, 60, 100, 0, length_includes_head=True, head_width=5, head_length=5, overhang=5) ax.add_patch(b) draw_if_interactive() Thanks, Mark - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Interactive save still broken in Tkinter
Sorry to bug you about this again. This is an old problem that hasn't been fixed yet. I don't know how to fix it, but I hope somebody does. Using Tkinter, in interactive mode, using pylab, after saving by clicking on the save button on Toolbar2, any reference to the figure will have disappeared (although the figure window remains open). So the next plot command will create an entirely new figure. This bug was started, we think, when we switched to the *much* nicer filedialog that we are using right now. I would like to keep using the nicer filedialog, but I also would like the bug to be fixed. Anybody any ideas? Thanks, Mark - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] subplots adjust
Darren -Although I agree with your on some level, the advantage of the current toolbar is that it is easy to incorporate in a GUI, where the user can define his own drop down menu. So I vote for a backend native slider, but keep the button on the toolbar. I have been thinking about an easier way to have user-defined toolbars (and I am sure others have much better ideas). I would rather put energy towards modifyable toolbars than a dropdown menu,Mark --Message: 4Date: Mon, 7 Aug 2006 09:34:57 -0400 From: Darren Dale <[EMAIL PROTECTED]>Subject: [matplotlib-devel] subplots adjustTo: matplotlib-devel@lists.sourceforge.net Message-ID: <[EMAIL PROTECTED]>Content-Type: text/plain; charset="us-ascii"I am writing to ask about the subplots adjust widget. I think the gui would be better implimented by each backend using the native widgets rather than bythe existing set of backend-neutral sliders, which are somewhat unbecoming.The proposed backend-specific widgets could call the generic subplot resize routines, and really shouldn't be that difficult to impliment. Also, I wasthinking that subplot_adjust should be selectable from a standarddropdown "File, Edit, View..." menubar instead of on the main toolbar. The save button could also be moved to the drop down menu bar.Darren-- - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] open bug: losing focus after saving in interactive mode
John, Others -I tried the old style saveas dialogue and it works fine. But the dialogue is so ugly that I am very hesitant to suggest to switch to the old saveas. I looked on the web and didn't see any reply to John's post on the python list. John - you want te repost? I think Clovis submitted the patch with the new, good looking saveas dialogue. Do you have any idea Clovis?Also, I have a Tkinter GUI I wrote that has mpl plots in it, and when I use saveas from the menubar in that application I don't get this problem. Very strange MarkOn 7/9/06, John Hunter <[EMAIL PROTECTED]> wrote: >>>>> "Mark" == Mark Bakker <[EMAIL PROTECTED]> writes:Mark> The weird thing is that this used to work fine in the past.Mark> At least, I am pretty sure it did. Then again, I am Mark> watching the Worlcup final at this time. So a significantMark> part of my brain is doing something else, MarkAt some point, we upgraded our tk filesave dialog to use the moremodern one. We could always revert to the old one, which would likely fix this but let's give it a day and see if we can't have thebest of both worlds. Hopefully, the effbot will pick up on my c.l.pypost...JDH - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] bug introduced in 0.87.3: subprocess error while saving eps
Sorry to bother you again, but I recently upgraded from 0.87.2 to 0.87.3, and cannot save eps files anymore. I get a 'subprocess' error.I am running Python 2.3, mpl 0.87.3, and TkAgg (although that shouldn't matter).
Error occurs whether using toolbar or savefig to save.Here's the script and the errror. Has this been fixed in svn?>>> from pylab import *>>> plot([1,2,3])[]>>> savefig('c:/temp/test.eps')Traceback (most recent call last): File "", line 1, in ? savefig('c:/temp/test.eps') File "C:\Python23\Lib\site-packages\matplotlib\pylab.py", line 811, in savefig
return fig.savefig(*args, **kwargs) File "C:\Python23\Lib\site-packages\matplotlib\figure.py", line 660, in savefig self.canvas.print_figure(*args, **kwargs) File "C:\Python23\Lib\site-packages\matplotlib\backends\backend_tkagg.py", line 184, in print_figure
agg.print_figure(filename, dpi, facecolor, edgecolor, orientation, File "C:\Python23\Lib\site-packages\matplotlib\backends\backend_agg.py", line 481, in print_figure from backend_ps import FigureCanvasPS # lazy import
File "C:\Python23\Lib\site-packages\matplotlib\backends\backend_ps.py", line 10, in ? from subprocess import Popen, STDOUT, PIPEImportError: No module named subprocess
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] open bug: losing focus after saving in interactive mode
The weird thing is that this used to work fine in the past.At least, I am pretty sure it did.Then again, I am watching the Worlcup final at this time. So a significant part of my brain is doing something else,
MarkOn 7/9/06, John Hunter <[EMAIL PROTECTED]> wrote:
>>>>> "Mark" == Mark Bakker <[EMAIL PROTECTED]> writes:Mark> John was asking whether there was something left to be fixedMark> befor
0.88. In 0.87.3, there is still a bug left that hasMark> been reported several times I think.Interesting. the tk ask file dialog seems to be triggering a destgroyevent on the main window, which removes it from mpl figure
management. Here is a minimal Tk script which exposes the problem.When you press the mouse button, you get a file dialog that when youclose it triggers a destroy event and calls the callback functionI don't know if this is a tk bug or if we are misusing the Tk code.
Tk experts?I'll post on python-list.JDHimport Tkinter as Tkfrom tkFileDialog import asksaveasfilenamedef button(event):fname = asksaveasfilename(title='Save the figure'
)window = Tk.Tk()frame = Tk.Frame(window, width=500,height=500)frame.bind('', button)frame.pack()def callback(*args):print 'called callback'
window.bind("", callback)window.mainloop()
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] open bug: losing focus after saving in interactive mode
John was asking whether there was something left to be fixed befor 0.88.In 0.87.3, there is still a bug left that has been reported several times I think.In interactive mode on TkAgg, after solving by clicking on the 'save' button in toolbar2, mpl loses its knowledge of the figure. Any plotting statement given after thatcreates a new figure, rather than add to the existing one. I wish I knew how to fix this.I am (still, but not much longer) running Python 2.3, but I think Fernando reportedthe bug in Python 2.4 as well.Thanks,Mark - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
