Hi, We are in the process of getting our new Qt IPython GUI working with matplotlib. One problem we have found is that the matplotlib qt4 backend always creates a QApplication. This is problematic in situations where another part of an application has already created a QApplication. The fix is to have matplotlib first see if a QApplication already exists and then use that one. The attached patch implements this fix. If needed, Fernando can help test this, but I think the change is minor enough that it should be good to go. Cheers, Brian
On 08/26/2010 05:13 PM, Brian Granger wrote: > Hi, > > We are in the process of getting our new Qt IPython GUI working with > matplotlib. One problem we have found is that the matplotlib qt4 > backend always creates a QApplication. This is problematic in > situations where another part of an application has already created a > QApplication. The fix is to have matplotlib first see if a > QApplication already exists and then use that one. The attached patch > implements this fix. If needed, Fernando can help test this, but I > think the change is minor enough that it should be good to go. I committed it. I suspect the most recent changes to ipython may require changes to show, but they can wait until things settle down a bit. Eric > > Cheers, > > Brian
Eric, On Fri, Aug 27, 2010 at 12:15 AM, Eric Firing <ef...@ha...> wrote: > On 08/26/2010 05:13 PM, Brian Granger wrote: >> Hi, >> >> We are in the process of getting our new Qt IPython GUI working with >> matplotlib. One problem we have found is that the matplotlib qt4 >> backend always creates a QApplication. This is problematic in >> situations where another part of an application has already created a >> QApplication. The fix is to have matplotlib first see if a >> QApplication already exists and then use that one. The attached patch >> implements this fix. If needed, Fernando can help test this, but I >> think the change is minor enough that it should be good to go. > > I committed it. Thanks! I am going to post another msg soon about our thoughts on a new and consistent way of detecting existing apps and running event loops. > I suspect the most recent changes to ipython may require changes to > show, but they can wait until things settle down a bit. Very likely, we will be in touch. Brian > Eric > >> >> Cheers, >> >> Brian > > ------------------------------------------------------------------------------ > Sell apps to millions through the Intel(R) Atom(Tm) Developer Program > Be part of this innovative community and reach millions of netbook users > worldwide. Take advantage of special opportunities to increase revenue and > speed time-to-market. Join now, and jumpstart your future. > http://p.sf.net/sfu/intel-atom-d2d > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >
On Fri, Aug 27, 2010 at 12:15 AM, Eric Firing <ef...@ha...> wrote: > I committed it. > Many thanks Eric, for being so responsive! Some eye candy to give you an idea of what we're getting from this work: http://fperez.org/tmp/multiplot.png http://fperez.org/tmp/multiplot2.png The second is the MPL contours example, pasted straight into the new ipython frontend, and all plots are correctly rendered inline. All this should be ready for adventurous users to begin testing in a few weeks (it's still a bit alpha right now, so really 'hardhat-only'). But we're very happy with how things are progressing, and it's fabulous to have your rapid response rate on the MPL side. Best regards, f
On 08/28/2010 09:38 AM, Fernando Perez wrote: > On Fri, Aug 27, 2010 at 12:15 AM, Eric Firing<ef...@ha...> wrote: >> I committed it. >> > > Many thanks Eric, for being so responsive! Fernando, I'm glad to help; ipython is a crucial part of the tool set. > > Some eye candy to give you an idea of what we're getting from this work: > > http://fperez.org/tmp/multiplot.png > http://fperez.org/tmp/multiplot2.png > > The second is the MPL contours example, pasted straight into the new > ipython frontend, and all plots are correctly rendered inline. Impressive--but I don't think I understand why one would want plots rendered inline rather than in separate windows. Eric > > All this should be ready for adventurous users to begin testing in a > few weeks (it's still a bit alpha right now, so really > 'hardhat-only'). But we're very happy with how things are > progressing, and it's fabulous to have your rapid response rate on the > MPL side. > > Best regards, > > f
Hi Eric, On Sat, Aug 28, 2010 at 4:27 PM, Eric Firing <ef...@ha...> wrote: > > Impressive--but I don't think I understand why one would want plots rendered > inline rather than in separate windows. It's not 'rather than', it's 'in addition to' :) Imagine you and I are working on a problem together, you have IPython open and you get the plot windows on your desk. You'd like to discuss something about the data with me (I'm away in California, not at your desk), so I open an IPython client that connects to your kernel, and start getting on my frontend the static versions of all the plots. You have the full windows on your desktop which zoom and pan, but with a simple 'show()' I can get static snapshots of all the figures on my desk, while we both work with and control the same kernel. That could be useful, no? Regards, f
On Mon, Aug 30, 2010 at 2:21 AM, Fernando Perez <fpe...@gm...>wrote: > Hi Eric, > > On Sat, Aug 28, 2010 at 4:27 PM, Eric Firing <ef...@ha...> wrote: > > > > Impressive--but I don't think I understand why one would want plots > rendered > > inline rather than in separate windows. > > It's not 'rather than', it's 'in addition to' :) Imagine you and I > are working on a problem together, you have IPython open and you get > the plot windows on your desk. You'd like to discuss something about > the data with me (I'm away in California, not at your desk), so I open > an IPython client that connects to your kernel, and start getting on > my frontend the static versions of all the plots. You have the full > windows on your desktop which zoom and pan, but with a simple 'show()' > I can get static snapshots of all the figures on my desk, while we > both work with and control the same kernel. > > That could be useful, no? > > Regards, > > f > > Dude, that just blew my mind! Awesome idea! Ben Root
On Mon, Aug 30, 2010 at 7:24 AM, Benjamin Root <ben...@ou...> wrote: > Dude, that just blew my mind! > > Awesome idea! By the way, I don't know if it was clear, but this wasn't just an idea, it's already implemented: http://fperez.org/tmp/ip-multiclient.png The two windows are talking to the same kernel, the one at the top issues the plot command, and the one at the bottom then just does 'show()' and it gets the same figure. Notice how they share a global prompt counter, since that number lives kernel-side. They're both on the same computer, but it makes no difference if they run on different hosts. This isn't anywhere near production-quality yet, but it does work. We're busy finishing the core pieces so we can spend some time polishing it for user testing. Cheers, f
On Mon, Aug 30, 2010 at 7:24 AM, Benjamin Root <ben...@ou...> wrote: > Dude, that just blew my mind! > Glad you like it :) And needless to say, once the dust settles and someone is willing, the obvious thing to do is to put a zeromq-http bridge and make a web browser-based client, so you can use ipython/matplotlib from your android/iphone/netbook/whatever. We've been scrupulously careful not to introduce any python assumptions client-side, so that in principle frontends can be written in any language or toolkit (e.g. html/javascript), the entire system is specified by its messaging protocol: http://ipython.scipy.org/doc/nightly/html/development/messaging.html Regards, f
On Mon, Aug 30, 2010 at 9:59 PM, Fernando Perez <fpe...@gm...> wrote: > On Mon, Aug 30, 2010 at 7:24 AM, Benjamin Root <ben...@ou...> wrote: >> Dude, that just blew my mind! >> > > Glad you like it :) > > And needless to say, once the dust settles and someone is willing, the > obvious thing to do is to put a zeromq-http bridge and make a web > browser-based client, so you can use ipython/matplotlib from your > android/iphone/netbook/whatever. > > We've been scrupulously careful not to introduce any python > assumptions client-side, so that in principle frontends can be written > in any language or toolkit (e.g. html/javascript), the entire system > is specified by its messaging protocol: > > http://ipython.scipy.org/doc/nightly/html/development/messaging.html That'd be great. I think I either want to use regular terminal, or a worksheet in the browser. Ondrej
On Tue, Aug 31, 2010 at 1:21 PM, Ondrej Certik <on...@ce...> wrote: > > That'd be great. I think I either want to use regular terminal, or a > worksheet in the browser. You may change your mind when you start playing with the new Qt terminal :) It feels very much like a terminal, except with a ton of little useful touches that make it very effective. It still has a lot of rough edges, but Evan has done a phenomenal job there. I'm now using it as my regular ipython instead of the normal one, dogfooding enough that we hit all the key usability quirks quickly, and act on them. Cheers, f
On Tue, Aug 31, 2010 at 1:25 PM, Fernando Perez <fpe...@gm...> wrote: > On Tue, Aug 31, 2010 at 1:21 PM, Ondrej Certik <on...@ce...> wrote: >> >> That'd be great. I think I either want to use regular terminal, or a >> worksheet in the browser. > > You may change your mind when you start playing with the new Qt > terminal :) It feels very much like a terminal, except with a ton of > little useful touches that make it very effective. It still has a lot > of rough edges, but Evan has done a phenomenal job there. I'm now > using it as my regular ipython instead of the normal one, dogfooding > enough that we hit all the key usability quirks quickly, and act on > them. Ok, I'll give it a shot then. Ondrej
On Tue, Aug 31, 2010 at 1:55 PM, Ondrej Certik <on...@ce...> wrote: > Ok, I'll give it a shot then. As I mentioned elsewhere, getting it going is a bit rough right now. So unless you really want to play with real bleeding edge code, give us a couple of weeks. It will be much nicer then. Cheers, f
On 8/30/10 1:21 AM, Fernando Perez wrote: > Hi Eric, > > On Sat, Aug 28, 2010 at 4:27 PM, Eric Firing<ef...@ha...> wrote: >> Impressive--but I don't think I understand why one would want plots rendered >> inline rather than in separate windows. Fernando: I've got ipython-newkernal ipythonqt working on my mac - how do I tell it to switch between external plot windows and inline plots? External windows seems to be the default... -Jeff
Hi Jeff, On Sun, Sep 5, 2010 at 10:18 AM, Jeff Whitaker <js...@fa...> wrote: > > Fernando: I've got ipython-newkernal ipythonqt working on my mac - how do I > tell it to switch between external plot windows and inline plots? External > windows seems to be the default... if you start it with --rich, it will use inline plots. I'll try to improve the code so that *both* are possible simultaneously: interactive external windows for zooming and panning, and a function loaded into the user's namespace, similar to show(), that would instead embed them inline. Cheers, f
On 9/5/10 3:15 PM, Fernando Perez wrote: > Hi Jeff, > > On Sun, Sep 5, 2010 at 10:18 AM, Jeff Whitaker<js...@fa...> wrote: >> Fernando: I've got ipython-newkernal ipythonqt working on my mac - how do I >> tell it to switch between external plot windows and inline plots? External >> windows seems to be the default... > if you start it with --rich, it will use inline plots. I'll try to > improve the code so that *both* are possible simultaneously: > interactive external windows for zooming and panning, and a function > loaded into the user's namespace, similar to show(), that would > instead embed them inline. > > Cheers, > > f Fernando: That works, but it seems like I have to run show() to make the plot appear inline. draw() doesn't do it. Is this the expected behavior? -Jeff
Hi Jeff, On Sun, Sep 5, 2010 at 5:25 PM, Jeff Whitaker <js...@fa...> wrote: > Fernando: That works, but it seems like I have to run show() to make the > plot appear inline. draw() doesn't do it. Is this the expected behavior? > Yes, currently it is, because the show() you're running is actually *our* show() which we've overwritten to do the svg transport. The interface to all of this is very new and completely experimental, so we're more than happy to take suggestions/ideas/code on how to make it work better. Regards, f
On 9/5/10 6:32 PM, Fernando Perez wrote: > Hi Jeff, > > On Sun, Sep 5, 2010 at 5:25 PM, Jeff Whitaker<js...@fa...> wrote: >> Fernando: That works, but it seems like I have to run show() to make the >> plot appear inline. draw() doesn't do it. Is this the expected behavior? >> > Yes, currently it is, because the show() you're running is actually > *our* show() which we've overwritten to do the svg transport. > > The interface to all of this is very new and completely experimental, > so we're more than happy to take suggestions/ideas/code on how to make > it work better. > > Regards, > > f Fernando: Got it, thanks. Sounds reasonable to me. Just playing with it a bit, one thing I found myself looking for was a way to save the entire session (inline figures included) to html. -Jeff
Hi Jeff, On Mon, Sep 6, 2010 at 6:27 AM, Jeff Whitaker <js...@fa...> wrote: > Fernando: Got it, thanks. Sounds reasonable to me. Just playing with it a > bit, one thing I found myself looking for was a way to save the entire > session (inline figures included) to html. > Of course! When is the patch coming? ;) Yes, that will be the obvious first thing everybody will want. And it shouldn't be too hard to write, either. In fact, if we store the svg payloads in a dict keyed by input line number kernel-side, it would be pretty easy to write a little function that will take a session and will generate a reST document with figures and all, with .. image:: directives. BTW, in my branch (fperez/newkernel) it's already working with inline figures not needing a show() call at all, and a 'paste()' function to paste any figure inline if you use one of the gui backends. We should have it merged in a day or two. Cheers, f ps - tip: Ctrl-. restarts the kernel, and Ctrl-L clears the screen. So it's quick to get a fresh state, but keeping all your input history you've been typing client-side unmodified. We're starting to get the benefits of the two-process model...
On Wed, Sep 8, 2010 at 12:12 AM, Fernando Perez <fpe...@gm...> wrote: > ps - tip: Ctrl-. restarts the kernel Tangentially... please make this something that's a little harder to hit by accident, like Ctrl-Alt-. or a menu item or something? My ipython's regularly hold state that would take a few CPU-days to reconstruct. (Sorry for the off-topic.) -- Nathaniel
When you press Ctrl-., the client prompts you to make sure that you really want to restart the kernel. Your work is not at risk from a careless key press. Evan On Wed, Sep 8, 2010 at 9:58 AM, Nathaniel Smith <nj...@po...> wrote: > On Wed, Sep 8, 2010 at 12:12 AM, Fernando Perez <fpe...@gm...> wrote: >> ps - tip: Ctrl-. restarts the kernel > > Tangentially... please make this something that's a little harder to > hit by accident, like Ctrl-Alt-. or a menu item or something? My > ipython's regularly hold state that would take a few CPU-days to > reconstruct. > > (Sorry for the off-topic.) > > -- Nathaniel > > ------------------------------------------------------------------------------ > 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 >
