matplotlib-devel Mailing List for matplotlib

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')

On Mon, Aug 30, 2010 at 7:10 AM, Michiel de Hoon <mjl...@ya...> 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 <ell...@gm...> wrote:
>
>> From: Brian Granger <ell...@gm...>
>> Subject: Re: [matplotlib-devel] Uniform GUI support across matplotlib, ets and ipython
>> To: "Michiel de Hoon" <mjl...@ya...>
>> Cc: mat...@li..., "IPython Development list" <ipy...@sc...>, ent...@en..., "Evan Patterson" <epa...@en...>
>> Date: Sunday, August 29, 2010, 3:24 PM
>> On Sat, Aug 28, 2010 at 8:12 PM,
>> Michiel de Hoon <mjl...@ya...>
>> 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 <ell...@gm...>
>> wrote:
>> >
>> >> From: Brian Granger <ell...@gm...>
>> >> Subject: [matplotlib-devel] Uniform GUI support
>> across matplotlib, ets and ipython
>> >> To: mat...@li...,
>> "IPython Development list" <ipy...@sc...>,
>> ent...@en...,
>> "Evan Patterson" <epa...@en...>
>> >> 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,
>> >> this was not a problem because we used to
>> >> hijack/monkeypatch the GUI
>> >> eventloops after we started them. In 0.11, we
>> will no
>> >> longer be doing
>> >> that. To address these issues, we have created
>> a
>> >> standalone module
>> >> that implements the needed logic:
>> >>
>> >> http://github.com/ipython/ipython/blob/newkernel/IPython/lib/guisupport.py
>> >>
>> >> This module is heavily commented and introduces a
>> new
>> >> informal
>> >> protocol that all of use can use to detect if
>> event
>> >> loops are
>> >> running. This informal protocol is inspired by
>> how
>> >> some of this is
>> >> handled inside ETS. Our idea is that all
>> projects
>> >> will simply copy
>> >> this module into their code and ship it. It is
>> >> lightweight and does
>> >> not depend on IPython or other top-level
>> imports. As
>> >> you will see, we
>> >> have implemented the logic for wx and qt4, we will
>> need
>> >> help with
>> >> other toolkits. An important point is that
>> matplotlib
>> >> and ets WILL
>> >> NOT WORK with the upcoming release of IPython
>> unless
>> >> changes are made
>> >> to their respective codebases. We consider this
>> a
>> >> draft and are more
>> >> than willing to modify the design or approach as
>> >> appropriate. One
>> >> thing that we have not thought about yet is how to
>> continue
>> >> to support
>> >> 0.10 within this model.
>> >>
>> >> The good news amidst all of this is that the
>> quality and
>> >> stability of
>> >> the GUI support in IPython is orders of magnitude
>> better
>> >> than that in
>> >> the 0.10 series.
>> >>
>> >> Cheers,
>> >>
>> >> Brian
>> >>
>> >> PS: If you are curious, here is a bit of
>> background
>> >> on the issues
>> >> related to the PyOS_Inputhook stuff:
>> >>
>> >> http://mail.scipy.org/pipermail/ipython-dev/2010-July/006330.html
>> >>
>> >>
>> ------------------------------------------------------------------------------
>> >> 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
>> >>
>> >
>> >
>> >
>> >
>>
>>
>>
>> --
>> Brian E. Granger, Ph.D.
>> Assistant Professor of Physics
>> Cal Poly State University, San Luis Obispo
>> bgr...@ca...
>> ell...@gm...
>>
>
>
>
>
-- 
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgr...@ca...
ell...@gm...

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

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 <ell...@gm...> wrote:
> From: Brian Granger <ell...@gm...>
> Subject: Re: [matplotlib-devel] Uniform GUI support across matplotlib, ets and ipython
> To: "Michiel de Hoon" <mjl...@ya...>
> Cc: mat...@li..., "IPython Development list" <ipy...@sc...>, ent...@en..., "Evan Patterson" <epa...@en...>
> Date: Sunday, August 29, 2010, 3:24 PM
> On Sat, Aug 28, 2010 at 8:12 PM,
> Michiel de Hoon <mjl...@ya...>
> 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 <ell...@gm...>
> wrote:
> >
> >> From: Brian Granger <ell...@gm...>
> >> Subject: [matplotlib-devel] Uniform GUI support
> across matplotlib, ets and ipython
> >> To: mat...@li...,
> "IPython Development list" <ipy...@sc...>,
> ent...@en...,
> "Evan Patterson" <epa...@en...>
> >> 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,
> >> this was not a problem because we used to
> >> hijack/monkeypatch the GUI
> >> eventloops after we started them. In 0.11, we
> will no
> >> longer be doing
> >> that. To address these issues, we have created
> a
> >> standalone module
> >> that implements the needed logic:
> >>
> >> http://github.com/ipython/ipython/blob/newkernel/IPython/lib/guisupport.py
> >>
> >> This module is heavily commented and introduces a
> new
> >> informal
> >> protocol that all of use can use to detect if
> event
> >> loops are
> >> running. This informal protocol is inspired by
> how
> >> some of this is
> >> handled inside ETS. Our idea is that all
> projects
> >> will simply copy
> >> this module into their code and ship it. It is
> >> lightweight and does
> >> not depend on IPython or other top-level
> imports. As
> >> you will see, we
> >> have implemented the logic for wx and qt4, we will
> need
> >> help with
> >> other toolkits. An important point is that
> matplotlib
> >> and ets WILL
> >> NOT WORK with the upcoming release of IPython
> unless
> >> changes are made
> >> to their respective codebases. We consider this
> a
> >> draft and are more
> >> than willing to modify the design or approach as
> >> appropriate. One
> >> thing that we have not thought about yet is how to
> continue
> >> to support
> >> 0.10 within this model.
> >>
> >> The good news amidst all of this is that the
> quality and
> >> stability of
> >> the GUI support in IPython is orders of magnitude
> better
> >> than that in
> >> the 0.10 series.
> >>
> >> Cheers,
> >>
> >> Brian
> >>
> >> PS: If you are curious, here is a bit of
> background
> >> on the issues
> >> related to the PyOS_Inputhook stuff:
> >>
> >> http://mail.scipy.org/pipermail/ipython-dev/2010-July/006330.html
> >>
> >>
> ------------------------------------------------------------------------------
> >> 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
> >>
> >
> >
> >
> >
> 
> 
> 
> -- 
> Brian E. Granger, Ph.D.
> Assistant Professor of Physics
> Cal Poly State University, San Luis Obispo
> bgr...@ca...
> ell...@gm...
> 
 

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