matplotlib-devel Mailing List for matplotlib (Page 4)

On Tue, Sep 14, 2010 at 8:59 AM, Michael Droettboom <md...@st...> wrote:
>
> This is now fixed in r8699.
>> - One produced an error:
>> http://matplotlib.sourceforge.net/examples/axes_grid/simple_axisline4.html
>>
>> ...
>>   ...: plt.draw()
>>   ...: plt.show()
>>   ...:
>> Received invalid plot data.
>>
> This is now fixed in r8700.
Great, many thanks for these fixes! It means that we're probably
capable now of running just about every pylab example out of the
box... We'll keep testing and will report if we see anything weird.
>> One small request: is it possible/easy to add to the MPL examples a
>> little 'copy to clipboard' button or link? Now that one can
>> copy/paste wholesale examples into an interactive session to explore
>> them, it feels annoying to have to highlight the whole text box and
>> then do Ctrl-C or menu->copy. It would be really nice to have a
>> one-click 'copy to clipboard'... But I have no idea if that's easy or
>> hard in HTML...
>>
> Good idea. I'll have a look at how hard this would be to add as a
> Sphinx extension.
Great, if it can be done it would be wonderful (Robert indicated it
may require flash, but others provided JS pointers; I'll leave it to
you to navigate those lovely waters :)
Cheers,
f

On 09/13/2010 04:58 PM, Fernando Perez wrote:
> Hi folks,
>
> [ sorry for the cross-post, but devs on both lists will care about this]
>
> I just went through the exercise of pasting 100 randomly chosen
> examples from the gallery into the new ipython console with inline
> graphics. Report:
>
> - 98 worked perfectly: the figures I got were identical to those on the website.
>
> - 1 had minor visual differences:
> http://matplotlib.sourceforge.net/examples/pylab_examples/quadmesh_demo.html:
> in the SVG render, the masked region
> appears black instead of transparent.
> 
This is now fixed in r8699.
> - One produced an error:
> http://matplotlib.sourceforge.net/examples/axes_grid/simple_axisline4.html
>
> ...
> ...: plt.draw()
> ...: plt.show()
> ...:
> Received invalid plot data.
> 
This is now fixed in r8700.
> But when I save the file and try to load it into firefox, it seems to
> indeed be bad SVG:
>
> XML Parsing Error: mismatched tag. Expected:</g>.
> Location: file:///home/fperez/ipython/ipython/bad.svg
> Line Number 287, Column 3:</svg>
> --^
>
> In summary: we can run pretty much any MPL example by straight
> copy/paste, and the only two glitches I see are in the SVG data
> itself. Once the other two buglets I reported earlier get fixed up,
> this will be a very nice way to interact with MPL.
>
> One small request: is it possible/easy to add to the MPL examples a
> little 'copy to clipboard' button or link? Now that one can
> copy/paste wholesale examples into an interactive session to explore
> them, it feels annoying to have to highlight the whole text box and
> then do Ctrl-C or menu->copy. It would be really nice to have a
> one-click 'copy to clipboard'... But I have no idea if that's easy or
> hard in HTML...
> 
Good idea. I'll have a look at how hard this would be to add as a 
Sphinx extension.
Cheers,
Mike
> Anyway, I think we're starting to be in pretty good shape!
>
> Cheers,
>
> f
>
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

On Tue, Sep 14, 2010 at 12:59 AM, Eric Firing <ef...@ha...> wrote:
> On 09/13/2010 05:46 PM, Brian Granger wrote:
>>
>> On Tue, Sep 7, 2010 at 1:31 PM, Eric Firing<ef...@ha...> wrote:
>>>
>>> On 09/03/2010 12:37 PM, Brian Granger wrote:
>>>>
>>>> Hello all,
>>>>
>>>> I would like to submit the following branch on github for review and
>>>> merging into matplotlib trunk:
>>>>
>>>> http://github.com/ellisonbg/matplotlib/commits/guisupport
>>>>
>>>> This branch implements the logic needed for the qt4 and wx backends to
>>>> fully work with the upcoming IPython 0.11 release. In our testing we
>>>> have run many of the mpl examples (including the new animation
>>>> examples) in both qt4/wx in both the terminal based IPython and the
>>>> new IPython Qt GUI. For background on these changes please see this
>>>> thread:
>>>>
>>>>
>>>> http://sourceforge.net/mailarchive/forum.php?thread_name=AANLkTik2SNtXMaezCc0UiMnCYg6LxwEL1eN9YASnmOua%40mail.gmail.com&forum_name=matplotlib-devel
>>>>
>>>> It is important to note that we have not updated the other matplotlib
>>>> backends (gtk, tk, etc.) to have this logic. This is mainly because
>>>> we know almost nothing about these toolkits and could really use some
>>>> help from folks who are experts at the respective toolkits. We have
>>>> done some minimal testing and these other backends do work for simple
>>>> examples in the terminal IPython, but they won't work in all cases and
>>>> will definitely not work in the new IPython Qt based GUI.
>>>>
>>>> We would love feedback and help testing as these changes are
>>>> significant (even though only a few lines of code). To test this
>>>> stuff you will need to grab the following IPython development branch:
>>>>
>>>> http://github.com/ipython/ipython/tree/newkernel
>>>>
>>>> You should be able to run the examples in regular ipython:
>>>>
>>>> ipython --pylab qt4|wx
>>>>
>>>> Or the new GUI
>>>>
>>>> ipythonqt --pylab qt4|wx
>>>
>>> Brian, Fernando,
>>>
>>> I have been doing a little testing with ipython 0.10 versus
>>> ipython-newkernel, both modes, and with mpl svn versus your guisupport.
>>> There are so many possible modes of operation and combinations of
>>> versions and backends that all this will take some time to sort out.
>>>
>>> Can you give me simple examples of what does *not* work correctly when
>>> you use mpl *svn* with ipython-newkernel, in either or both of the
>>> console or gui modes, but *does* work with your guisupport version?
>>
>> The problems are when matplotlib and enthought.traits/pyface/mayavi
>> stuff are used together. There are two types of problems:
>>
>> * Multiple apps are created. The enthought stuff used to not check
>> for existing apps, but that has been fixed.
>
> That one is easy.
>
>> * Event loop is started multiple times. This one is more subtle and
>> on some toolkits the error is not fatal. This problem shows up when
>> IPython is run in terminal mode and event loop integration is handled
>> through PyOS_InputHook. In these situations, if matplotlib or ets
>> start the event loop themselves, IPython will hang.
>
> So, this can be checked with nothing but IPython and mpl. I think I may have
> seen this with some combination of configurations, though not with what I
> typically use.
>
>>
>> Unfortunately, I am having trouble getting an install of both
>> matplotlib svn and ets svn on the same machine, so I can't reproduce
>> any of the failures ATM. I am trying to get things installed so I can
>> reproduce the problems.
>
> At least twice in the last couple of years I have tried to get mayavi
> compiled and running, without fouling up my development versions of numpy
> and mpl. I never succeeded. Granted, I didn't allocate much time and
> mental energy to it.
Yes, it can be a challenge, we will see how far I get...
> In any case, with the help of your recent explanations, I expect we can make
> mpl play by your suggested rules without sacrificing anything. Part of the
> change for mpl 1.0 was to factor all of the show logic out into
> backend_bases.py, leaving only the core mainloop call in the specific
> backends. I hope we can keep that aspect, retaining the ability to work
> with earlier ipython (0.10) and the ability for show to block or not
> depending on the interactivity state.
The refactored show logic does help a lot. I am pretty sure that my
branch already does all the things you want though. If there are
things that it is missing we can definitely add them. But when you
get a chance to look at this, let us know and we can continue the
discussion.
Cheers,
Brian
> Eric
>
>
>
-- 
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgr...@ca...
ell...@gm...

On Mon, Sep 13, 2010 at 4:10 PM, Brian Granger <ell...@gm...> wrote:
>> One small request: is it possible/easy to add to the MPL examples a
>> little 'copy to clipboard' button or link? Now that one can
>> copy/paste wholesale examples into an interactive session to explore
>> them, it feels annoying to have to highlight the whole text box and
>> then do Ctrl-C or menu->copy. It would be really nice to have a
>> one-click 'copy to clipboard'... But I have no idea if that's easy or
>> hard in HTML...
>
> +1 to this!
On a quick googling, there are some IE only Javascript examples to do
this. Apparently you can enable them in firefox but it requires a
significant amount of about:config hackery
(http://www.febooti.com/support/website-help/website-javascript-copy-clipboard.html).
How about this as an alternative: on my box, I can drag the "source
code" link from the browser into my terminal, which by default pastes
the URL of the referenced *.py into the terminal. If "run" supported
a -w (web) option, or automatically detected that the URL starts with
http, it could do a web run of the file. Of course, you may want the
source code pasted in for illustrative purposes... To support this,
you could add a -u (url) option to "paste" which assumes the input is
a url, fetches it, and pastes the contents into ipython. So you could
type "paste -u" and then drag the link into the terminal, and it would
fetch it and paste the code into an input block.
JDH

On Mon, Sep 13, 2010 at 6:44 PM, Fernando Perez <fpe...@gm...>wrote:
> Thanks, that's good to know. But I'm mostly thinking of teaching
> situations, so it would be nice to have this in the source: it's not
> for my use but for the benefit of students who may be in a lab where
> they can't install extensions. But I don't know if that can even be
> done in html in the first place.
>
I think there might be a couple different approaches that might be useful
for educational purposes of IPython + matplotlib usage. For instance:
1-) When one downloads a script from the matplotlib gallery via an external
script (name it load_into_ipython or open_with_ipython) the contents of that
gallery script (or any python script) can be executed locally inside an
ipython session.
2-) Matplotlib gallery might turn to an interactive environment where you
can execute the script from right within your browser and change parameters
in the same browser window. As far as I know mpl figures can now be drawn on
html canvas. This might for sure boost the number of matplotlib audience.
-- 
Gökhan

On 09/13/2010 05:46 PM, Brian Granger wrote:
> On Tue, Sep 7, 2010 at 1:31 PM, Eric Firing<ef...@ha...> wrote:
>> On 09/03/2010 12:37 PM, Brian Granger wrote:
>>> Hello all,
>>>
>>> I would like to submit the following branch on github for review and
>>> merging into matplotlib trunk:
>>>
>>> http://github.com/ellisonbg/matplotlib/commits/guisupport
>>>
>>> This branch implements the logic needed for the qt4 and wx backends to
>>> fully work with the upcoming IPython 0.11 release. In our testing we
>>> have run many of the mpl examples (including the new animation
>>> examples) in both qt4/wx in both the terminal based IPython and the
>>> new IPython Qt GUI. For background on these changes please see this
>>> thread:
>>>
>>> http://sourceforge.net/mailarchive/forum.php?thread_name=AANLkTik2SNtXMaezCc0UiMnCYg6LxwEL1eN9YASnmOua%40mail.gmail.com&forum_name=matplotlib-devel
>>>
>>> It is important to note that we have not updated the other matplotlib
>>> backends (gtk, tk, etc.) to have this logic. This is mainly because
>>> we know almost nothing about these toolkits and could really use some
>>> help from folks who are experts at the respective toolkits. We have
>>> done some minimal testing and these other backends do work for simple
>>> examples in the terminal IPython, but they won't work in all cases and
>>> will definitely not work in the new IPython Qt based GUI.
>>>
>>> We would love feedback and help testing as these changes are
>>> significant (even though only a few lines of code). To test this
>>> stuff you will need to grab the following IPython development branch:
>>>
>>> http://github.com/ipython/ipython/tree/newkernel
>>>
>>> You should be able to run the examples in regular ipython:
>>>
>>> ipython --pylab qt4|wx
>>>
>>> Or the new GUI
>>>
>>> ipythonqt --pylab qt4|wx
>>
>> Brian, Fernando,
>>
>> I have been doing a little testing with ipython 0.10 versus
>> ipython-newkernel, both modes, and with mpl svn versus your guisupport.
>> There are so many possible modes of operation and combinations of
>> versions and backends that all this will take some time to sort out.
>>
>> Can you give me simple examples of what does *not* work correctly when
>> you use mpl *svn* with ipython-newkernel, in either or both of the
>> console or gui modes, but *does* work with your guisupport version?
>
> The problems are when matplotlib and enthought.traits/pyface/mayavi
> stuff are used together. There are two types of problems:
>
> * Multiple apps are created. The enthought stuff used to not check
> for existing apps, but that has been fixed.
That one is easy.
> * Event loop is started multiple times. This one is more subtle and
> on some toolkits the error is not fatal. This problem shows up when
> IPython is run in terminal mode and event loop integration is handled
> through PyOS_InputHook. In these situations, if matplotlib or ets
> start the event loop themselves, IPython will hang.
So, this can be checked with nothing but IPython and mpl. I think I may 
have seen this with some combination of configurations, though not with 
what I typically use.
>
> Unfortunately, I am having trouble getting an install of both
> matplotlib svn and ets svn on the same machine, so I can't reproduce
> any of the failures ATM. I am trying to get things installed so I can
> reproduce the problems.
At least twice in the last couple of years I have tried to get mayavi 
compiled and running, without fouling up my development versions of 
numpy and mpl. I never succeeded. Granted, I didn't allocate much time 
and mental energy to it.
In any case, with the help of your recent explanations, I expect we can 
make mpl play by your suggested rules without sacrificing anything. 
Part of the change for mpl 1.0 was to factor all of the show logic out 
into backend_bases.py, leaving only the core mainloop call in the 
specific backends. I hope we can keep that aspect, retaining the 
ability to work with earlier ipython (0.10) and the ability for show to 
block or not depending on the interactivity state.
Eric

On 09/13/2010 08:54 AM, Brian Granger wrote:
> Eric,
>
> Sorry about the delay, I was on vacation last week...comments inline below...
>
> On Tue, Sep 7, 2010 at 2:26 PM, Eric Firing<ef...@ha...> wrote:
>> On 09/07/2010 11:07 AM, Fernando Perez wrote:
>>> Hi Eric,
>>>
>>> On Tue, Sep 7, 2010 at 1:31 PM, Eric Firing<ef...@ha...> wrote:
>>>>
>>>> I have been doing a little testing with ipython 0.10 versus
>>>> ipython-newkernel, both modes, and with mpl svn versus your guisupport.
>>>> There are so many possible modes of operation and combinations of
>>>> versions and backends that all this will take some time to sort out.
>>>>
>>>> Can you give me simple examples of what does *not* work correctly when
>>>> you use mpl *svn* with ipython-newkernel, in either or both of the
>>>> console or gui modes, but *does* work with your guisupport version?
>>>
>>> Thanks for your testing, Eric.
>>>
>>> With matplotlib *alone*, I can't find a way to crash/lock/whatever the
>>> combo of matplotlib(svn)+ipython-newkernel.
>>>
>>> The reason, i believe, is that guisupport.py is available in ipython
>>> itself, and it goes out of its way to avoid creating a second main qt
>>> app, letting matplotlib create it. Since that main app is alive all
>>> the time, there's only one app and one event loop and life is good.
>>> But if I were to open another library that uses Qt and makes a new
>>> main qApp unconditionally, we'd have problems.
>>>
>>> Brian and Evan have recently just added the guisupport.py patch to
>>> Enthought's ETS, so that now it probably will be pretty hard to
>>> actually see the problem: if both ipython and ets go out of their way
>>> to avoid the nested main app issue, mpl can get away with making one
>>> unconditionally and things will probably work OK.
>>>
>>> But the idea is for all of us (ipython, ets, mpl, etc) to agree on a
>>> collaborative protocol with a simple api: check for one special
>>> '_in_event_loop' flag in the main toolkit before making one. That
>>> will make it easier to have interactive code that uses Wx or Qt from
>>> more than one library coexisting in the same process.
>>
>> Fernando,
>
>
>> There are two parts to guisupport: ensure a single main app, and ensure
>> no more than one call to the mainloop.
>
> Yes, that is a good summary.
>
>> The first makes perfect sense,
>> and cannot cause any problems that I can see. The second one is the one
>> that I think may be both unnecessary and undesirable. The reason is
>> that the gui toolkit mainloop functions or methods are designed for
>> nested calls. This permits blocking within a running mainloop, and
>> allows show() to block when pyplot is not in interactive mode. This is
>> what is lost with the guisupport mods. Some changes to mainloop logic
>> may well be needed, but I don't think that prohibiting nested calls to
>> the underlying toolkit mainloop function is necessary or desirable.
>
> This is a very good point and is something that we have thought
> carefully about. You are very correct, that the functions in
> guisupport cannot be used to do a nested mainloop. Nested calls to
> the mainloop should be done in the usual manner by simply calling the
> appropriate gui toolkit method for doing so. We probably need to
> clarify this point, but the focus of the functions in guisupport are
> *only* the first and main invocation of the event loop. Basically, we
> want to ensure that:
>
> * Projects don't accidentally do nested mainloops because there were
> not aware that the outermost eventloop was already running.
> * Projects start the outermost eventloop in a manner that other
> projects will be able to reliably detect.
>
> I should mention the other approach that we have tried, but that failed:
>
> * Have IPython startup, create an app and start the main loop.
> * Then monkeypatch the gui toolkit so that the mainloop calls are no-ops.
> * Further monkeypatch the gui toolkit so that it appears that the
> mainloop is running (even when it may not be because of PyOS_InputHook
> magic).
>
> This allowed us to do everything, BUT obviously, nested mainloops
> failed. Thus, making sure that nested mainloops still work was the
> main reason we have created guisupport. We should better document
> these details though.
Brian,
Thanks for the clarification. Your basic approach sounds fine. I need 
to think a little more about how to handle this in mpl. The proposed 
modification is not quite right yet. I probably can't work on it until 
the weekend.
Eric
>
> Cheers,
>
> Brian
>
>> Eric
>>
>>>
>>> I'll let Brian fill in with more details when he has some
>>> availability, but I think that's the gist of it.
>>>
>>> Regards,
>>>
>>> f
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net Dev2Dev email is sponsored by:
>>
>> Show off your parallel programming skills.
>> Enter the Intel(R) Threading Challenge 2010.
>> http://p.sf.net/sfu/intel-thread-sfd
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>
>
>

On Tue, Sep 7, 2010 at 1:31 PM, Eric Firing <ef...@ha...> wrote:
> On 09/03/2010 12:37 PM, Brian Granger wrote:
>> Hello all,
>>
>> I would like to submit the following branch on github for review and
>> merging into matplotlib trunk:
>>
>> http://github.com/ellisonbg/matplotlib/commits/guisupport
>>
>> This branch implements the logic needed for the qt4 and wx backends to
>> fully work with the upcoming IPython 0.11 release. In our testing we
>> have run many of the mpl examples (including the new animation
>> examples) in both qt4/wx in both the terminal based IPython and the
>> new IPython Qt GUI. For background on these changes please see this
>> thread:
>>
>> http://sourceforge.net/mailarchive/forum.php?thread_name=AANLkTik2SNtXMaezCc0UiMnCYg6LxwEL1eN9YASnmOua%40mail.gmail.com&forum_name=matplotlib-devel
>>
>> It is important to note that we have not updated the other matplotlib
>> backends (gtk, tk, etc.) to have this logic. This is mainly because
>> we know almost nothing about these toolkits and could really use some
>> help from folks who are experts at the respective toolkits. We have
>> done some minimal testing and these other backends do work for simple
>> examples in the terminal IPython, but they won't work in all cases and
>> will definitely not work in the new IPython Qt based GUI.
>>
>> We would love feedback and help testing as these changes are
>> significant (even though only a few lines of code). To test this
>> stuff you will need to grab the following IPython development branch:
>>
>> http://github.com/ipython/ipython/tree/newkernel
>>
>> You should be able to run the examples in regular ipython:
>>
>> ipython --pylab qt4|wx
>>
>> Or the new GUI
>>
>> ipythonqt --pylab qt4|wx
>
> Brian, Fernando,
>
> I have been doing a little testing with ipython 0.10 versus
> ipython-newkernel, both modes, and with mpl svn versus your guisupport.
> There are so many possible modes of operation and combinations of
> versions and backends that all this will take some time to sort out.
>
> Can you give me simple examples of what does *not* work correctly when
> you use mpl *svn* with ipython-newkernel, in either or both of the
> console or gui modes, but *does* work with your guisupport version?
The problems are when matplotlib and enthought.traits/pyface/mayavi
stuff are used together. There are two types of problems:
* Multiple apps are created. The enthought stuff used to not check
for existing apps, but that has been fixed.
* Event loop is started multiple times. This one is more subtle and
on some toolkits the error is not fatal. This problem shows up when
IPython is run in terminal mode and event loop integration is handled
through PyOS_InputHook. In these situations, if matplotlib or ets
start the event loop themselves, IPython will hang.
Unfortunately, I am having trouble getting an install of both
matplotlib svn and ets svn on the same machine, so I can't reproduce
any of the failures ATM. I am trying to get things installed so I can
reproduce the problems.
Cheers,
Brian
> Thanks.
>
> Eric
>
>>
>> Cheers,
>>
>> Brian
>>
>
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
-- 
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgr...@ca...
ell...@gm...

On 2010年09月13日, at 7:44 PM, Fernando Perez wrote:
> Thanks, that's good to know. But I'm mostly thinking of teaching
> situations, so it would be nice to have this in the source: it's not
> for my use but for the benefit of students who may be in a lab where
> they can't install extensions. But I don't know if that can even be
> done in html in the first place.
You can definitely hijack copies with JavaScript:
http://stackoverflow.com/questions/400212/how-to-copy-to-clipboard-in-javascript
Nice work IPython people! I haven't been following too closely but this looks exciting.
David

On Mon, Sep 13, 2010 at 6:44 PM, Fernando Perez <fpe...@gm...>wrote:
> On Mon, Sep 13, 2010 at 2:22 PM, Gökhan Sever <gok...@gm...>
> wrote:
> >
> > Either in Firefox or Chrome you could use extensions [Auto Copy] to copy
> > text selections into clipboard.
>
> Thanks, that's good to know. But I'm mostly thinking of teaching
> situations, so it would be nice to have this in the source: it's not
> for my use but for the benefit of students who may be in a lab where
> they can't install extensions. But I don't know if that can even be
> done in html in the first place.
>
> Cheers,
>
> f
>
In github, there is something like this for copying the address of someone's
git repo, but it might be done using Flash, I am not sure.
Ben Root

On Mon, Sep 13, 2010 at 2:22 PM, Gökhan Sever <gok...@gm...> wrote:
>
> Either in Firefox or Chrome you could use extensions [Auto Copy] to copy
> text selections into clipboard.
Thanks, that's good to know. But I'm mostly thinking of teaching
situations, so it would be nice to have this in the source: it's not
for my use but for the benefit of students who may be in a lab where
they can't install extensions. But I don't know if that can even be
done in html in the first place.
Cheers,
f

On Tue, Aug 31, 2010 at 9:08 PM, Benjamin Root <ben...@ou...> wrote:
> Hello,
>
> I have been working on a couple of interesting concoctions for matplotlib.
> The first is a wrapper class called "ThinWrap" that, essentially, provides a
> way to create objects that are linked to a given object. These objects can
> then be subclassed for some very interesting behaviors. Which leads me to
> my ReMap class.
>
> The ReMap class is designed to be a wrapper around a Colormap object, and
> the __call__ function is overloaded so that some other defined function can
> modify the rgba values that comes from a call to the original colormap
> object. All of this is done without modifying the original colormap. In
> addition, a ReMap object can wrap another ReMap object, allowing for
> stacking. As an example, I have created a ToGrayscale() ReMap class.
>
> For your reviewing pleasure, there are two patch files. The first,
> thinwrap.patch, adds the ThinWrap class to cbook.py. The second,
> remap.patch, creates a new file "remap.py" that holds the ReMap class and
> the ToGrayscale class. In addition, in order for things to work, a few
> changes had to be made to other code:
>
> cm.py: get_cmap() could finish the function without returning anything. I
> modified it to remove the "isinstance" check that would cause
> non-Colormap/non-string objects to fall into a black hole. We are gonna
> have to follow duck-typing here...
> colors.py: The Colormap class needs to be a new-style class for ReMap to
> work properly
> contour.py: Commented out code that did a isinstance() check on the cmap
> that would cause ReMaps on contours to fail.
>
> I have also included an example script to demonstrate how this wrapper
> class works and the ToGrayscale() class works.
>
> Let me know what you think!
> Ben Root
>
Just reping-ing this. I haven't heard anything negative and got a few
positive comments off-list. I haven't committed this yet because I am
concerned about the implications of my changes to cm.py, colors.py and
contour.py. However, if I don't hear any concerns over the next couple of
days, shall I assume that it is ok to go ahead and commit?
Ben Root

Hi Fernando,
On Mon, Sep 13, 2010 at 3:58 PM, Fernando Perez <fpe...@gm...>wrote:
> Hi folks,
>
> One small request: is it possible/easy to add to the MPL examples a
> little 'copy to clipboard' button or link? Now that one can
> copy/paste wholesale examples into an interactive session to explore
> them, it feels annoying to have to highlight the whole text box and
> then do Ctrl-C or menu->copy. It would be really nice to have a
> one-click 'copy to clipboard'... But I have no idea if that's easy or
> hard in HTML...
>
Either in Firefox or Chrome you could use extensions [Auto Copy] to copy
text selections into clipboard.
-- 
Gökhan

Fernando,
On Mon, Sep 13, 2010 at 1:58 PM, Fernando Perez <fpe...@gm...> wrote:
> Hi folks,
>
> [ sorry for the cross-post, but devs on both lists will care about this]
>
> I just went through the exercise of pasting 100 randomly chosen
> examples from the gallery into the new ipython console with inline
> graphics. Report:
>
> - 98 worked perfectly: the figures I got were identical to those on the website.
That is a pretty significant test of the new console....100 is a lot
of copying and pasting.
> - 1 had minor visual differences:
> http://matplotlib.sourceforge.net/examples/pylab_examples/quadmesh_demo.html:
> in the SVG render, the masked region
> appears black instead of transparent.
>
> - One produced an error:
> http://matplotlib.sourceforge.net/examples/axes_grid/simple_axisline4.html
>
> ...
>  ...: plt.draw()
>  ...: plt.show()
>  ...:
> Received invalid plot data.
>
> But when I save the file and try to load it into firefox, it seems to
> indeed be bad SVG:
>
> XML Parsing Error: mismatched tag. Expected: </g>.
> Location: file:///home/fperez/ipython/ipython/bad.svg
> Line Number 287, Column 3:</svg>
> --^
>
> In summary: we can run pretty much any MPL example by straight
> copy/paste, and the only two glitches I see are in the SVG data
> itself. Once the other two buglets I reported earlier get fixed up,
> this will be a very nice way to interact with MPL.
>
> One small request: is it possible/easy to add to the MPL examples a
> little 'copy to clipboard' button or link? Now that one can
> copy/paste wholesale examples into an interactive session to explore
> them, it feels annoying to have to highlight the whole text box and
> then do Ctrl-C or menu->copy. It would be really nice to have a
> one-click 'copy to clipboard'... But I have no idea if that's easy or
> hard in HTML...
+1 to this!
Cheers,
Brian
> Anyway, I think we're starting to be in pretty good shape!
>
> Cheers,
>
> f
> _______________________________________________
> IPython-dev mailing list
> IPy...@sc...
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-- 
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgr...@ca...
ell...@gm...

Hi folks,
[ sorry for the cross-post, but devs on both lists will care about this]
I just went through the exercise of pasting 100 randomly chosen
examples from the gallery into the new ipython console with inline
graphics. Report:
- 98 worked perfectly: the figures I got were identical to those on the website.
- 1 had minor visual differences:
http://matplotlib.sourceforge.net/examples/pylab_examples/quadmesh_demo.html:
in the SVG render, the masked region
appears black instead of transparent.
- One produced an error:
http://matplotlib.sourceforge.net/examples/axes_grid/simple_axisline4.html
...
 ...: plt.draw()
 ...: plt.show()
 ...:
Received invalid plot data.
But when I save the file and try to load it into firefox, it seems to
indeed be bad SVG:
XML Parsing Error: mismatched tag. Expected: </g>.
Location: file:///home/fperez/ipython/ipython/bad.svg
Line Number 287, Column 3:</svg>
--^
In summary: we can run pretty much any MPL example by straight
copy/paste, and the only two glitches I see are in the SVG data
itself. Once the other two buglets I reported earlier get fixed up,
this will be a very nice way to interact with MPL.
One small request: is it possible/easy to add to the MPL examples a
little 'copy to clipboard' button or link? Now that one can
copy/paste wholesale examples into an interactive session to explore
them, it feels annoying to have to highlight the whole text box and
then do Ctrl-C or menu->copy. It would be really nice to have a
one-click 'copy to clipboard'... But I have no idea if that's easy or
hard in HTML...
Anyway, I think we're starting to be in pretty good shape!
Cheers,
f

Eric,
Sorry about the delay, I was on vacation last week...comments inline below...
On Tue, Sep 7, 2010 at 2:26 PM, Eric Firing <ef...@ha...> wrote:
> On 09/07/2010 11:07 AM, Fernando Perez wrote:
>> Hi Eric,
>>
>> On Tue, Sep 7, 2010 at 1:31 PM, Eric Firing<ef...@ha...> wrote:
>>>
>>> I have been doing a little testing with ipython 0.10 versus
>>> ipython-newkernel, both modes, and with mpl svn versus your guisupport.
>>> There are so many possible modes of operation and combinations of
>>> versions and backends that all this will take some time to sort out.
>>>
>>> Can you give me simple examples of what does *not* work correctly when
>>> you use mpl *svn* with ipython-newkernel, in either or both of the
>>> console or gui modes, but *does* work with your guisupport version?
>>
>> Thanks for your testing, Eric.
>>
>> With matplotlib *alone*, I can't find a way to crash/lock/whatever the
>> combo of matplotlib(svn)+ipython-newkernel.
>>
>> The reason, i believe, is that guisupport.py is available in ipython
>> itself, and it goes out of its way to avoid creating a second main qt
>> app, letting matplotlib create it. Since that main app is alive all
>> the time, there's only one app and one event loop and life is good.
>> But if I were to open another library that uses Qt and makes a new
>> main qApp unconditionally, we'd have problems.
>>
>> Brian and Evan have recently just added the guisupport.py patch to
>> Enthought's ETS, so that now it probably will be pretty hard to
>> actually see the problem: if both ipython and ets go out of their way
>> to avoid the nested main app issue, mpl can get away with making one
>> unconditionally and things will probably work OK.
>>
>> But the idea is for all of us (ipython, ets, mpl, etc) to agree on a
>> collaborative protocol with a simple api: check for one special
>> '_in_event_loop' flag in the main toolkit before making one. That
>> will make it easier to have interactive code that uses Wx or Qt from
>> more than one library coexisting in the same process.
>
> Fernando,
> There are two parts to guisupport: ensure a single main app, and ensure
> no more than one call to the mainloop.
Yes, that is a good summary.
> The first makes perfect sense,
> and cannot cause any problems that I can see. The second one is the one
> that I think may be both unnecessary and undesirable. The reason is
> that the gui toolkit mainloop functions or methods are designed for
> nested calls. This permits blocking within a running mainloop, and
> allows show() to block when pyplot is not in interactive mode. This is
> what is lost with the guisupport mods. Some changes to mainloop logic
> may well be needed, but I don't think that prohibiting nested calls to
> the underlying toolkit mainloop function is necessary or desirable.
This is a very good point and is something that we have thought
carefully about. You are very correct, that the functions in
guisupport cannot be used to do a nested mainloop. Nested calls to
the mainloop should be done in the usual manner by simply calling the
appropriate gui toolkit method for doing so. We probably need to
clarify this point, but the focus of the functions in guisupport are
*only* the first and main invocation of the event loop. Basically, we
want to ensure that:
* Projects don't accidentally do nested mainloops because there were
not aware that the outermost eventloop was already running.
* Projects start the outermost eventloop in a manner that other
projects will be able to reliably detect.
I should mention the other approach that we have tried, but that failed:
* Have IPython startup, create an app and start the main loop.
* Then monkeypatch the gui toolkit so that the mainloop calls are no-ops.
* Further monkeypatch the gui toolkit so that it appears that the
mainloop is running (even when it may not be because of PyOS_InputHook
magic).
This allowed us to do everything, BUT obviously, nested mainloops
failed. Thus, making sure that nested mainloops still work was the
main reason we have created guisupport. We should better document
these details though.
Cheers,
Brian
> Eric
>
>>
>> I'll let Brian fill in with more details when he has some
>> availability, but I think that's the gist of it.
>>
>> Regards,
>>
>> f
>
>
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
-- 
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgr...@ca...
ell...@gm...

Andrew Straw <str...@as...> writes:
>> 3. To make this work, agree that sample data files are immutable: if a
>> new version is needed, it needs to have a new name (and thus the
>> examples using it need to be updated). The files have not been
>> changed a lot [2], so I don't think this is very much of a burden.
>>
> I don't like #3 -- for the same reasons as we want to separate the rest 
> of the sample data (smaller download, smaller repository, and separation 
> of code and non-essential data), I think the test comparison images 
> should be with the sample data. Having to deal with renames in the tests 
> would be annoying. 
If the test data is moved there, I agree that renaming won't work. 
But it seems to me that test data is different from sample data used by
examples: when running the tests for a given revision of matplotlib, you
don't want the absolute latest comparison images but the images that
correspond to that particular code revision. You also typically want to
get all of the comparison images for that revision at the same time,
since you're likely to be running the whole test suite. Also, if you are
running the test suite, I think we can assume you can get a checkout of
the test-data repository.
(A git submodule would seem to be a good fit: the main repository would
have a pointer to the appropriate revision of the test-images
repository, and people interested in running the test suite would have
to run "git submodule update" to check it out.)
> Two alternative ideas to handle for the versioning 
> issue: A) Add a .py file in the main source repository with is a list of 
> sample data filenames and checksums. If a sample data file doesn't 
> exist, or its checksum is wrong, it can be downloaded.
Sounds complicated, and makes older versions unable to run newer
examples.
> B) The source file could simply have the same data version number
> required and the sample data itself could be versioned.
That might work. If I understand this correctly, the example code would
call get_sample_data("foo.dat") to get the latest revision or
get_sample_data("foo.dat", 1234) to get a specific one. These would
retrieve URLs like
http://example.com/sample-data/raw/master/foo.dat
http://example.com/sample-data/raw/1234/foo.dat
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Le 12 sept. 2010 18:08, Benjamin Root <ben...@ou...> a écrit :
> That would be a neat feature. Which other backends have you tested? I 
> presume that numbers still work as usual?
> Ben Root
I've tested it on TkAgg and Qt4Agg which are the only backends I use. 
Numbers should be working just as before.
The patch is very short but probably needs someone who knows the code to 
have a look it.

On Sun, Sep 12, 2010 at 6:54 AM, Peter Butterworth <bu...@gm...>wrote:
> I am considering a patch to support named figures.
>
> >>
> http://sourceforge.net/tracker/?func=detail&aid=3057301&group_id=80706&atid=560723
> Tracker: Feature Requests
> pls support named figures - ID: 3057301
>
> instead of only:
> plt.figure(1)
> the following:
> plt.figure('today')
> would open a figure called 'today' instead of 'figure 1'
>
> Example usage: when opening a lot of tabbed figures (in Spyder) it
> would help if the tabs have meaningful names.
> >>
>
> I have been successful at modifying pyplot.figure to handle string
> arguments. For this I store the figure name in the _label attribute of
> the figure in addition to setting the expected plot number value. My
> hack seems to works on qt4agg backend (it does requires adding an
> optional label argument to the FigureManagerQT constructor).
>
> Is there interest in including such a patch in matplotlib ? Is it
> likely to break things elsewhere ?
>
> --
> thanks,
> peter butterworth
>
>
That would be a neat feature. Which other backends have you tested? I
presume that numbers still work as usual?
Ben Root

On Sun, Sep 12, 2010 at 10:30 AM, Andrew Straw <str...@as...> wrote:
> #1 and #2 seem reasonable to me.
>
> I don't like #3 -- for the same reasons as we want to separate the rest
I agree with Andrew here -- we don't want to hamstring our ability to
change the data just because some people would rather take a version
in place of the latest version. If we have an rc option
 sampledata.fetch : False
then the sampledata function would only look in the sample data dir,
get the file if available, raise otherwise. If fetch is True, it
would always go the web first and check for the latest, get it and
cache it. Then the packagers could download the tarball, unpack it,
and not worry about mpl trying to check for a more recent version.
JDH

On 09/12/2010 07:10 AM, Jouni K. Seppänen wrote:
> A while ago there was a discussion [1] about how using the
> get_sample_data function in building the documentation is a problem for
> Debian packagers. Let me see if I understand the goals of
> get_sample_data correctly:
>
> * we want to enable users to run examples they find in the gallery
> without downloading extra files;
>
> * we don't want to package all the sample data with matplotlib, either
> because it is too large, or because it changes more often than we
> release new versions.
> 
* Also, we want to have the sample data not to be in the same version 
control repository as MPL proper so that when we download the MPL source 
code itself, we don't get the sample data. (This is one of the sticking 
points for a move to git.)
> Here's what I suggest:
>
> 1. Package the sample data in a separate zip file that users can
> download and expand in e.g. ~/.matplotlib/sample_data if they like.
> This file could be released more often than matplotlib, if needed.
> Debian can use this as one source file and package it as a separate
> deb file.
>
> 2. Make get_sample_data look first in the place where the zip file could
> have been expanded, and only if the required file is not found, try
> to obtain it from the web. Add an option to disable the network
> access. This is different from what we do now, because now
> get_sample_data always tries to check if there is a newer version
> available, which apparently doesn't work reliably on unconnected
> computers.
>
> 3. To make this work, agree that sample data files are immutable: if a
> new version is needed, it needs to have a new name (and thus the
> examples using it need to be updated). The files have not been
> changed a lot [2], so I don't think this is very much of a burden.
>
> What do you think?
>
> 
#1 and #2 seem reasonable to me.
I don't like #3 -- for the same reasons as we want to separate the rest 
of the sample data (smaller download, smaller repository, and separation 
of code and non-essential data), I think the test comparison images 
should be with the sample data. Having to deal with renames in the tests 
would be annoying. Two alternative ideas to handle for the versioning 
issue: A) Add a .py file in the main source repository with is a list of 
sample data filenames and checksums. If a sample data file doesn't 
exist, or its checksum is wrong, it can be downloaded. B) The source 
file could simply have the same data version number required and the 
sample data itself could be versioned.

A while ago there was a discussion [1] about how using the
get_sample_data function in building the documentation is a problem for
Debian packagers. Let me see if I understand the goals of
get_sample_data correctly:
* we want to enable users to run examples they find in the gallery
 without downloading extra files;
* we don't want to package all the sample data with matplotlib, either
 because it is too large, or because it changes more often than we
 release new versions.
The current sample data takes about 2.5 megabytes uncompressed, so the
size doesn't look like a real problem, but of course it is desirable
that new examples are usable with old versions unless they need new
features.
The problem that the Debian packagers have with the current system is 
(I suppose) that building the documentation requires network access and 
is not guaranteed to be repeatable.
Here's what I suggest:
1. Package the sample data in a separate zip file that users can
 download and expand in e.g. ~/.matplotlib/sample_data if they like.
 This file could be released more often than matplotlib, if needed.
 Debian can use this as one source file and package it as a separate
 deb file.
2. Make get_sample_data look first in the place where the zip file could
 have been expanded, and only if the required file is not found, try
 to obtain it from the web. Add an option to disable the network
 access. This is different from what we do now, because now
 get_sample_data always tries to check if there is a newer version
 available, which apparently doesn't work reliably on unconnected
 computers.
3. To make this work, agree that sample data files are immutable: if a
 new version is needed, it needs to have a new name (and thus the
 examples using it need to be updated). The files have not been
 changed a lot [2], so I don't think this is very much of a burden.
What do you think?
Jouni
[1] http://thread.gmane.org/gmane.comp.python.matplotlib.devel/8865
[2] Here is a summary of the changes to each file in sample_data:
=== ./aapl.csv ===
------------------------------------------------------------------------
r7379 | jdh2358 | 2009年08月05日 18:57:31 +0300 (2009年8月05日)
------------------------------------------------------------------------
r6202 | jdh2358 | 2008年10月15日 15:43:41 +0300 (2008年10月15日)
------------------------------------------------------------------------
r4975 | jdh2358 | 2008年02月16日 22:58:37 +0200 (2008年2月16日)
------------------------------------------------------------------------
=== ./AAPL.dat ===
------------------------------------------------------------------------
r7388 | jdh2358 | 2009年08月05日 20:16:50 +0300 (2009年8月05日)
------------------------------------------------------------------------
=== ./aapl.npy ===
------------------------------------------------------------------------
r7377 | jdh2358 | 2009年08月05日 18:52:29 +0300 (2009年8月05日)
------------------------------------------------------------------------
r6203 | jdh2358 | 2008年10月15日 18:39:44 +0300 (2008年10月15日)
------------------------------------------------------------------------
=== ./axes_grid/bivariate_normal.npy ===
------------------------------------------------------------------------
r7436 | leejjoon | 2009年08月09日 07:34:08 +0300 (2009年8月09日)
------------------------------------------------------------------------
=== ./ct.raw ===
------------------------------------------------------------------------
r7382 | jdh2358 | 2009年08月05日 19:21:23 +0300 (2009年8月05日)
------------------------------------------------------------------------
r177 | jdh2358 | 2004年03月13日 01:00:12 +0200 (2004年3月13日)
------------------------------------------------------------------------
=== ./data_x_x2_x3.csv ===
------------------------------------------------------------------------
r7382 | jdh2358 | 2009年08月05日 19:21:23 +0300 (2009年8月05日)
------------------------------------------------------------------------
r7078 | efiring | 2009年05月03日 03:09:06 +0300 (2009年5月03日)
------------------------------------------------------------------------
=== ./demodata.csv ===
------------------------------------------------------------------------
r7382 | jdh2358 | 2009年08月05日 19:21:23 +0300 (2009年8月05日)
------------------------------------------------------------------------
r5100 | jdh2358 | 2008年04月30日 22:53:10 +0300 (2008年4月30日)
------------------------------------------------------------------------
=== ./eeg.dat ===
------------------------------------------------------------------------
r7382 | jdh2358 | 2009年08月05日 19:21:23 +0300 (2009年8月05日)
------------------------------------------------------------------------
r52 | jdh2358 | 2003年11月02日 23:23:21 +0200 (2003年11月02日)
------------------------------------------------------------------------
=== ./embedding_in_wx3.xrc ===
------------------------------------------------------------------------
r7382 | jdh2358 | 2009年08月05日 19:21:23 +0300 (2009年8月05日)
------------------------------------------------------------------------
r397 | astraw | 2004年07月10日 21:39:48 +0300 (2004年7月10日)
------------------------------------------------------------------------
=== ./goog.npy ===
------------------------------------------------------------------------
r7377 | jdh2358 | 2009年08月05日 18:52:29 +0300 (2009年8月05日)
------------------------------------------------------------------------
r6203 | jdh2358 | 2008年10月15日 18:39:44 +0300 (2008年10月15日)
------------------------------------------------------------------------
=== ./INTC.dat ===
------------------------------------------------------------------------
r7387 | jdh2358 | 2009年08月05日 20:16:00 +0300 (2009年8月05日)
------------------------------------------------------------------------
=== ./lena.jpg ===
------------------------------------------------------------------------
r7382 | jdh2358 | 2009年08月05日 19:21:23 +0300 (2009年8月05日)
------------------------------------------------------------------------
r2557 | astraw | 2006年07月12日 02:32:31 +0300 (2006年7月12日)
------------------------------------------------------------------------
r2556 | astraw | 2006年07月12日 02:28:46 +0300 (2006年7月12日)
------------------------------------------------------------------------
r603 | astraw | 2004年10月19日 20:50:03 +0300 (2004年10月19日)
------------------------------------------------------------------------
=== ./lena.png ===
------------------------------------------------------------------------
r7364 | jdh2358 | 2009年08月05日 17:36:27 +0300 (2009年8月05日)
------------------------------------------------------------------------
r7327 | jdh2358 | 2009年07月31日 21:55:17 +0300 (2009年7月31日)
------------------------------------------------------------------------
=== ./logo2.png ===
------------------------------------------------------------------------
r7382 | jdh2358 | 2009年08月05日 19:21:23 +0300 (2009年8月05日)
------------------------------------------------------------------------
r5669 | jdh2358 | 2008年06月24日 21:58:41 +0300 (2008年6月24日)
------------------------------------------------------------------------
=== ./membrane.dat ===
------------------------------------------------------------------------
r7382 | jdh2358 | 2009年08月05日 19:21:23 +0300 (2009年8月05日)
------------------------------------------------------------------------
r64 | jdh2358 | 2003年11月15日 19:05:37 +0200 (2003年11月15日)
------------------------------------------------------------------------
=== ./Minduka_Present_Blue_Pack.png ===
------------------------------------------------------------------------
r7421 | leejjoon | 2009年08月08日 04:40:31 +0300 (2009年8月08日)
------------------------------------------------------------------------
=== ./msft.csv ===
------------------------------------------------------------------------
r7382 | jdh2358 | 2009年08月05日 19:21:23 +0300 (2009年8月05日)
------------------------------------------------------------------------
r2144 | jdh2358 | 2006年03月14日 03:28:43 +0200 (2006年3月14日)
------------------------------------------------------------------------
r86 | jdh2358 | 2003年11月21日 19:50:00 +0200 (2003年11月21日)
------------------------------------------------------------------------
=== ./msft_nasdaq.npy ===
------------------------------------------------------------------------
r7377 | jdh2358 | 2009年08月05日 18:52:29 +0300 (2009年8月05日)
------------------------------------------------------------------------
r6203 | jdh2358 | 2008年10月15日 18:39:44 +0300 (2008年10月15日)
------------------------------------------------------------------------
=== ./s1045.ima ===
------------------------------------------------------------------------
r7382 | jdh2358 | 2009年08月05日 19:21:23 +0300 (2009年8月05日)
------------------------------------------------------------------------
r48 | jdh2358 | 2003年11月02日 21:43:30 +0200 (2003年11月02日)
------------------------------------------------------------------------
=== ./testdata.csv ===
------------------------------------------------------------------------
r7364 | jdh2358 | 2009年08月05日 17:36:27 +0300 (2009年8月05日)
------------------------------------------------------------------------
r7361 | jdh2358 | 2009年08月05日 14:39:37 +0300 (2009年8月05日)
------------------------------------------------------------------------
r7360 | jdh2358 | 2009年08月05日 14:34:43 +0300 (2009年8月05日)
------------------------------------------------------------------------
=== ./testdir/subdir/testsub.csv ===
------------------------------------------------------------------------
r7368 | jdh2358 | 2009年08月05日 17:54:01 +0300 (2009年8月05日)
------------------------------------------------------------------------
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

I am considering a patch to support named figures.
>> http://sourceforge.net/tracker/?func=detail&aid=3057301&group_id=80706&atid=560723
Tracker: Feature Requests
pls support named figures - ID: 3057301
instead of only:
plt.figure(1)
the following:
plt.figure('today')
would open a figure called 'today' instead of 'figure 1'
Example usage: when opening a lot of tabbed figures (in Spyder) it
would help if the tabs have meaningful names.
>>
I have been successful at modifying pyplot.figure to handle string
arguments. For this I store the figure name in the _label attribute of
the figure in addition to setting the expected plot number value. My
hack seems to works on qt4agg backend (it does requires adding an
optional label argument to the FigureManagerQT constructor).
Is there interest in including such a patch in matplotlib ? Is it
likely to break things elsewhere ?
-- 
thanks,
peter butterworth

From: ben...@gm... [mailto:ben...@gm...] On Behalf Of Benjamin
Root
Sent: Thursday, September 02, 2010 14:39
 
Thanks for the insightful analysis. Could you file a bug report with some of
this information (at the very least, reference your message on the mailing
list)?
It took me a while to get back to it, but I'm happy to file a report. The
tracker ID is 3062773.

On Wed, Sep 8, 2010 at 8:06 PM, Eric Firing <ef...@ha...> wrote:
> JJ,
>
>
> I just wanted to raise a question of whether we let Axes3D add itself
>> to its parent (although this is not a bug anymore). If you and others
>> feel okay about it, then that's completely fine with me also.
>>
>
> It sounds like a valid point, worth addressing, but it is one I will leave
> to you, Ben, and Reinier to sort out.
>
> Eric
>
I agree that Axes3D should not add itself to the Figure object anymore. The
original implementation made sense, but now, it is merely legacy cruft that
will need to be eliminated appropriately over time.
There are probably a few minor issues I have before moving forward with a
complete deprecation of the old method of creating a 3d axes (namely the
subplot margins might be too big), but I will leave that to another thread.
Thanks for the patches!
Ben Root