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

Brian Granger ellisonbg at gmail.com
Sun Aug 29 15:24:11 EDT 2010

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.



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

More information about the IPython-dev mailing list