[IPython-dev] [matplotlib-devel] Uniform GUI support across matplotlib, ets and ipython

Mon Aug 30 14:06:06 EDT 2010

On Mon, Aug 30, 2010 at 7:10 AM, Michiel de Hoon <mjldehoon at yahoo.com> 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 <ellisonbg at gmail.com> wrote:
>
>> From: Brian Granger <ellisonbg at gmail.com>
>> Subject: Re: [matplotlib-devel] Uniform GUI support across matplotlib, ets and ipython
>> To: "Michiel de Hoon" <mjldehoon at yahoo.com>
>> Cc: matplotlib-devel at lists.sourceforge.net, "IPython Development list" <ipython-dev at scipy.org>, enthought-dev at enthought.com, "Evan Patterson" <epatters at enthought.com>
>> Date: Sunday, August 29, 2010, 3:24 PM
>> On Sat, Aug 28, 2010 at 8:12 PM,
>> Michiel de Hoon <mjldehoon at yahoo.com>
>> 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 <ellisonbg at gmail.com>
>> wrote:
>> >
>> >> From: Brian Granger <ellisonbg at gmail.com>
>> >> Subject: [matplotlib-devel] Uniform GUI support
>> across matplotlib, ets and ipython
>> >> To: matplotlib-devel at lists.sourceforge.net,
>> "IPython Development list" <ipython-dev at scipy.org>,
>> enthought-dev at enthought.com,
>> "Evan Patterson" <epatters at enthought.com>
>> >> 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
>> >> Matplotlib-devel at lists.sourceforge.net
>> >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> >>
>> >
>> >
>> >
>> >
>>
>>
>>
>> --
>> Brian E. Granger, Ph.D.
>> Assistant Professor of Physics
>> Cal Poly State University, San Luis Obispo
>> bgranger at calpoly.edu
>> ellisonbg at gmail.com
>>
>
>
>
>

-- 
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu
ellisonbg at gmail.com