On Sat, Aug 28, 2010 at 8:12 PM, Michiel de Hoon <mjldeh...@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 <elliso...@gmail.com> wrote: > >> From: Brian Granger <elliso...@gmail.com> >> Subject: [matplotlib-devel] Uniform GUI support across matplotlib, ets and >> ipython >> To: matplotlib-devel@lists.sourceforge.net, "IPython Development list" >> <ipython-...@scipy.org>, enthought-...@enthought.com, "Evan Patterson" >> <epatt...@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@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 bgran...@calpoly.edu elliso...@gmail.com ------------------------------------------------------------------------------ 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
