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
0001-Qt4-backend-now-checks-for-preexisting-QApplication.patch (1.7 KB)
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
···
On 08/26/2010 05:13 PM, Brian Granger wrote:
Cheers,
Brian
Eric,
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
···
On Fri, Aug 27, 2010 at 12:15 AM, Eric Firing <efiring@...229...> wrote:
On 08/26/2010 05:13 PM, Brian Granger wrote:
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
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options
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 Fri, Aug 27, 2010 at 12:15 AM, Eric Firing <efiring@...229...> wrote:
I committed it.
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:
Conference - FP Conference
Conference - FP Conference
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
···
On 08/28/2010 09:38 AM, Fernando Perez wrote:
On Fri, Aug 27, 2010 at 12:15 AM, Eric Firing<efiring@...229...> wrote:
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,
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 Sat, Aug 28, 2010 at 4:27 PM, Eric Firing <efiring@...229...> wrote:
Dude, that just blew my mind!
Awesome idea!
Ben Root
···
On Mon, Aug 30, 2010 at 2:21 AM, Fernando Perez <fperez.net@gmail.com> wrote:
Hi Eric,
On Sat, Aug 28, 2010 at 4:27 PM, Eric Firing <efiring@…229…> 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
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 7:24 AM, Benjamin Root <ben.root@...553...> wrote:
Dude, that just blew my mind!
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.root@...553...> wrote:
Dude, that just blew my mind!
Awesome idea!
That'd be great. I think I either want to use regular terminal, or a
worksheet in the browser.
Ondrej
···
On Mon, Aug 30, 2010 at 9:59 PM, Fernando Perez <fperez.net@...149...> wrote:
On Mon, Aug 30, 2010 at 7:24 AM, Benjamin Root <ben.root@...553...> 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
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:21 PM, Ondrej Certik <ondrej@...583...> wrote:
That'd be great. I think I either want to use regular terminal, or a
worksheet in the browser.
Ok, I'll give it a shot then.
Ondrej
···
On Tue, Aug 31, 2010 at 1:25 PM, Fernando Perez <fperez.net@...149...> wrote:
On Tue, Aug 31, 2010 at 1:21 PM, Ondrej Certik <ondrej@...583...> 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.
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 Tue, Aug 31, 2010 at 1:55 PM, Ondrej Certik <ondrej@...583...> wrote:
Ok, I'll give it a shot then.
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
···
On 8/30/10 1:21 AM, Fernando Perez wrote:
Hi Eric,
On Sat, Aug 28, 2010 at 4:27 PM, Eric Firing<efiring@...229...> wrote:
Impressive--but I don't think I understand why one would want plots rendered
inline rather than in separate windows.
Hi Jeff,
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 Sun, Sep 5, 2010 at 10:18 AM, Jeff Whitaker <jswhit@...196...> 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?
-Jeff
···
On 9/5/10 3:15 PM, Fernando Perez wrote:
Hi Jeff,
On Sun, Sep 5, 2010 at 10:18 AM, Jeff Whitaker<jswhit@...196...> 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
Hi Jeff,
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 Sun, Sep 5, 2010 at 5:25 PM, Jeff Whitaker <jswhit@...196...> 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.
-Jeff
···
On 9/5/10 6:32 PM, Fernando Perez wrote:
Hi Jeff,
On Sun, Sep 5, 2010 at 5:25 PM, Jeff Whitaker<jswhit@...196...> 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
Hi Jeff,
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 Mon, Sep 6, 2010 at 6:27 AM, Jeff Whitaker <jswhit@...196...> wrote:
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
···
On Wed, Sep 8, 2010 at 12:12 AM, Fernando Perez <fperez.net@...149...> wrote:
ps - tip: Ctrl-. restarts the kernel
