Re: [matplotlib-devel] Uniform GUI support across matplotlib, ets and ipython

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

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