Hi folks, On Sat, Aug 28, 2010 at 12:42 PM, Brian Granger <elliso...@gmail.com> wrote: > 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.
I just wanted to ping back with this topic, both to update you a little and to ask for help... Brian is now using Andrew's git repo and made an mpl branch for experimenting with the guisupport work: http://github.com/ellisonbg/matplotlib/tree/guisupport For now there's just one commit, but at any point in time, this URL will easily let you compare what's new vs Andrew's trunk (which I'm considering the canonical reference on github): http://github.com/ellisonbg/matplotlib/compare/astraw:trunk...guisupport Basically we're a bit stumped with GTK, and also partly with Tk. With Tk things *seem* to work ok in light testing, but it's possible that problems lurk. It's just that we do get something 'for free' because python itself manages the Tk event loop. But for GTK, no clue... This type of code will be needed to support the multiprocess capabilities we're developing with ipython, and for qt, wx and (apparently, but only by chance) tk, matplotlib with the guisupport added, works right now on IPython: - 0.10.1 with the old -Xthread flags (just like always, rather fragile and brittle but useful for a lot of things). - trunk at the command-line, using --pylab {qt, wx, tk}: this uses PyOSInputHook, which is more reliable than the --Xthread flags. - our 'newkernel' branch with the fancy Qt widget and two process control. So we're doing pretty good: Qt and Wx seem solid, Tk so far is cutting us slack. But GTK is simply hosed. Brian tried and got lost, and I don't have the foggiest clue. So if anyone here can help us out solidify the GTK solution, as well as point out anything that might be needed for Tk and any possible flaws in the code for Wx/Qt, we'd be immensely grateful. We're very, very excited about the possibilities the code we're building in ipython opens up. But we don't want to have the massive regression of breaking GTK support for matplotlib, and we're a bit stuck. Once the code in Brian's branch is tested/fixed/approved by you guys, we'd like to propose it for merging into matplotlib. The idea is that MPL would carry its own copy of this guisupport file, enabling it to cooperate well with IPython or anyone else who supports this approach (and we've talked with the IEP author --http://code.google.com/p/iep, enthought for the Traits machinery, etc). But it would NOT create an ipython dependency on matplotlib, nor should it break any embedded uses in a GUI application, etc. This stuff is hard, and Brian and I are both pretty ignorant when it comes to GUIs, so any help we can get will be really appreciated. If you want to comment inline or on the whole commit for the purposes of review, the commit URL at github always allows that: http://github.com/ellisonbg/matplotlib/commit/d4dcce8635bfe4a82f5e6eef89aa5daf025f1a20 The little + signs on the left of each line are for inline comments, and the box at the bottom for whole-commit commenting. Thanks! f ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
