Re: [matplotlib-devel] Patch for Qt4 backend for IPython GUI
Hi Eric, On Sat, Aug 28, 2010 at 4:27 PM, Eric Firing 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 -- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Uniform GUI support across matplotlib, ets and ipython
Hi Brian, Thanks for your reply. I agree that integrating multiple event loops is not essential for most users. But if you are not integrating multiple event loops, then why do you need poll? Best, --Michiel. --- On Sun, 8/29/10, Brian Granger wrote: > From: Brian Granger > Subject: Re: [matplotlib-devel] Uniform GUI support across matplotlib, ets > and ipython > To: "Michiel de Hoon" > Cc: [email protected], "IPython Development list" > , [email protected], "Evan Patterson" > > Date: Sunday, August 29, 2010, 3:24 PM > On Sat, Aug 28, 2010 at 8:12 PM, > Michiel de Hoon > wrote: > > I implemented an event loop in the MacOSX backend and > the PyOS_ImportHook event loop in PyGTK, so I've been > interested in this topic. > > Yes, and you were quite helpful last summer when i was > trying to > understand the PyOS_InputHook logic. I appreciated that > greatly! > > > If I understand guisupport.py correctly, IPython runs > the backend-specific event loop. Have you considered to > implement an event loop in IPython and to run that instead > of a backend-specific event loop? Then you won't have to > iterate the event loop, and you can run multiple GUI > backends (PyGTK, PyQT, Tkinter, ...) at the same time. The > latter may work with the current guisupport.py, but is > fragile, because running one of the backend-specific event > loops may inadvertently run code from a different backend. > > Yes, we do run the native event loops of the GUI toolkit > requested. > There are a few reasons we haven't gone the direction you > are > mentioning (although it has crossed our minds): > > 1. We are not *that* passionate about GUI event > loops. I would say > our philosophy with event loops is "the simplest solution > possible > that is robust." > 2. While it might be nice to be able to run multiple > event loops, in > most cases users can survive fine without this > feature. This is > especially true with more and more people migrating to Qt > because of > the license change. > 3. We are just barely at the point of getting the new > PyOS_InputHook > and two process kernel GUI support working robustly with > matplotlib/traits/mayavi/etc. It is an 2xNxMxP > testing nightmare with > 2 ways IPython can run the event loop x N toolkits x M > projects x P > platforms. Simply installing all possible > combinations would probably > take a couple of weeks time, let alone debugging it > all. I envy > matlab developers that simple have to test their plotting > on a few > platforms. We will be lucky to cover > matplotlib/traits/mayavi on just > qt4/wx on Mac/Linux/windows for the 0.11 release. > 4. Integrating multiple event loops is either 1) > super subtle and > difficult (if you actually start all the event loops > involved) or 2) > tends to create solutions that busy poll or consume > non-trivial CPU > power. The wx based PyOS_Inputhook and our two > process GUI support > are already great examples of this. We have to work > pretty hard to > create things that are responsive but that don't consume > 100% of the > CPU. To reduce the CPU usage of the wx PyOS_InputHook > we actually > dynamically scale back the polling time depending on how > often the > user is triggering GUI events. > 5. It is not just about integrating GUI event > loops. We also have > multiple other event loops in our apps that handle > networking. > > Cheers, > > Brian > > > > --Michiel. > > > > --- On Sat, 8/28/10, Brian Granger > wrote: > > > >> From: Brian Granger > >> Subject: [matplotlib-devel] Uniform GUI support > across matplotlib, ets and ipython > >> To: [email protected], > "IPython Development list" , > [email protected], > "Evan Patterson" > >> Date: Saturday, August 28, 2010, 3:42 PM > >> Hi all, > >> > >> As you may know, this summer we have been > working on > >> a new two > >> process IPython that has a beautiful Qt frontend > GUI and a > >> ZMQ based > >> messaging layer between that GUI and the new > IPython > >> kernel. Many > >> thanks to Enthought for funding this effort! > >> > >> We are currently in the process of adding GUI > event loop > >> integration > >> to the ipython kernel so users can do interactive > plotting > >> like they > >> can with the regular ipython. You may also > remember > >> that last summer > >> we implemented a new PyOs_InputHook based GUI > integration > >> for the > >> regular ipython. This has not been released yet, > but > >> all of this will > >> be released in the upcoming 0.11 release. > >> > >> I am emailing everyone because we see that there > is a need > >> for all of > >> us to agree on two things: > >> > >> 1. How to detect if a GUI application object has > been > >> created by someone else. > >> 2. How to detect if a GUI event loop is > running. > >> > >> Currently there is code in both ETS and matplotlib > that > >> fails to > >> handle these things properly in certain cases. > With > >> IPython 0.10
Re: [matplotlib-devel] Patch for Qt4 backend for IPython GUI
On Mon, Aug 30, 2010 at 2:21 AM, Fernando Perez wrote: > Hi Eric, > > On Sat, Aug 28, 2010 at 4:27 PM, Eric Firing 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 -- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Uniform GUI support across matplotlib, ets and ipython
On Mon, Aug 30, 2010 at 7:10 AM, Michiel de Hoon wrote: > Hi Brian, > Thanks for your reply. I agree that integrating multiple event loops is not > essential for most users. But if you are not integrating multiple event > loops, then why do you need poll? In the two process kernel we do currently integrate two event loops: 1. Our networking event loop that is based on zeromq/pyzmq 2. A single GUI event loop from wx, qt4, etc. We do this by triggering an iteration of our networking event loop on a periodic GUI timer. So we definitely have to face multiple event loop integration, but it is much simpler when you only have 1 GUi event loop involved. Cheers, Brian > Best, > --Michiel. > > > --- On Sun, 8/29/10, Brian Granger wrote: > >> From: Brian Granger >> Subject: Re: [matplotlib-devel] Uniform GUI support across matplotlib, ets >> and ipython >> To: "Michiel de Hoon" >> Cc: [email protected], "IPython Development list" >> , [email protected], "Evan Patterson" >> >> Date: Sunday, August 29, 2010, 3:24 PM >> On Sat, Aug 28, 2010 at 8:12 PM, >> Michiel de Hoon >> wrote: >> > I implemented an event loop in the MacOSX backend and >> the PyOS_ImportHook event loop in PyGTK, so I've been >> interested in this topic. >> >> Yes, and you were quite helpful last summer when i was >> trying to >> understand the PyOS_InputHook logic. I appreciated that >> greatly! >> >> > If I understand guisupport.py correctly, IPython runs >> the backend-specific event loop. Have you considered to >> implement an event loop in IPython and to run that instead >> of a backend-specific event loop? Then you won't have to >> iterate the event loop, and you can run multiple GUI >> backends (PyGTK, PyQT, Tkinter, ...) at the same time. The >> latter may work with the current guisupport.py, but is >> fragile, because running one of the backend-specific event >> loops may inadvertently run code from a different backend. >> >> Yes, we do run the native event loops of the GUI toolkit >> requested. >> There are a few reasons we haven't gone the direction you >> are >> mentioning (although it has crossed our minds): >> >> 1. We are not *that* passionate about GUI event >> loops. I would say >> our philosophy with event loops is "the simplest solution >> possible >> that is robust." >> 2. While it might be nice to be able to run multiple >> event loops, in >> most cases users can survive fine without this >> feature. This is >> especially true with more and more people migrating to Qt >> because of >> the license change. >> 3. We are just barely at the point of getting the new >> PyOS_InputHook >> and two process kernel GUI support working robustly with >> matplotlib/traits/mayavi/etc. It is an 2xNxMxP >> testing nightmare with >> 2 ways IPython can run the event loop x N toolkits x M >> projects x P >> platforms. Simply installing all possible >> combinations would probably >> take a couple of weeks time, let alone debugging it >> all. I envy >> matlab developers that simple have to test their plotting >> on a few >> platforms. We will be lucky to cover >> matplotlib/traits/mayavi on just >> qt4/wx on Mac/Linux/windows for the 0.11 release. >> 4. Integrating multiple event loops is either 1) >> super subtle and >> difficult (if you actually start all the event loops >> involved) or 2) >> tends to create solutions that busy poll or consume >> non-trivial CPU >> power. The wx based PyOS_Inputhook and our two >> process GUI support >> are already great examples of this. We have to work >> pretty hard to >> create things that are responsive but that don't consume >> 100% of the >> CPU. To reduce the CPU usage of the wx PyOS_InputHook >> we actually >> dynamically scale back the polling time depending on how >> often the >> user is triggering GUI events. >> 5. It is not just about integrating GUI event >> loops. We also have >> multiple other event loops in our apps that handle >> networking. >> >> Cheers, >> >> Brian >> >> >> > --Michiel. >> > >> > --- On Sat, 8/28/10, Brian Granger >> wrote: >> > >> >> From: Brian Granger >> >> Subject: [matplotlib-devel] Uniform GUI support >> across matplotlib, ets and ipython >> >> To: [email protected], >> "IPython Development list" , >> [email protected], >> "Evan Patterson" >> >> Date: Saturday, August 28, 2010, 3:42 PM >> >> Hi all, >> >> >> >> As you may know, this summer we have been >> working on >> >> a new two >> >> process IPython that has a beautiful Qt frontend >> GUI and a >> >> ZMQ based >> >> messaging layer between that GUI and the new >> IPython >> >> kernel. Many >> >> thanks to Enthought for funding this effort! >> >> >> >> We are currently in the process of adding GUI >> event loop >> >> integration >> >> to the ipython kernel so users can do interactive >> plotting >> >> like they >> >> can with the regular ipython. You may also >> remember >> >> that last summer >> >> we implemented a new PyO
[matplotlib-devel] Apparent bug with EPS files using Liberation fonts
Greetings. The attached script saves three EPS files (also attached) of a
figure containing a text object using the Liberation Sans font. In the three
EPS files, the text object contains no spaces, a normal space, and a
non-breaking space, respectively. Ghostscript handles the first and third
files but not the second, for which it gives the message "Error: /undefined in
--get--" at the Postscript "show" instruction for the text. I noticed that the
second file embeds a character for the non-breaking space "uni00A0" but not
the normal space, so I suppose that's why the error is occurring. I tried a
few other fonts and did not see any problems. I have matplotlib v. 1.0.0,
Python 2.6.5, and Liberation fonts 1.06.0.20100721. Would someone kindly look
into whether this might be a bug with matplotlib or the Liberation fonts? Many
thanks!
import matplotlib.pyplot as plt
fig = plt.figure()
txt = fig.text(0.5, 0.5, 'sometext', ha='center', va='center',
family='Liberation Sans')
fig.savefig('mpl-eps-liberation-nospace.eps')
txt.set_text('some text')
fig.savefig('mpl-eps-liberation-space.eps')
txt.set_text(u'some\u00A0text')
fig.savefig('mpl-eps-liberation-nbspace.eps')
mpl-eps-liberation-nospace.eps
Description: PostScript document
mpl-eps-liberation-space.eps
Description: PostScript document
mpl-eps-liberation-nbspace.eps
Description: PostScript document
mpl-eps-liberation-space.out
Description: Binary data
--
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Patch for Qt4 backend for IPython GUI
On Mon, Aug 30, 2010 at 7:24 AM, Benjamin Root 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 -- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
