Hey guys, On Mon, Jul 19, 2010 at 4:07 PM, Eric Firing <efir...@hawaii.edu> wrote: > > Please leave out the -a. It is harmful, not helpful, for mpl. This may > mean we need to change mpl and/or ipython, or the documentation, to > prevent problems with the -a option; but I think you will find that if > you leave out that option, the behavior will be more consistent and the > need for Ctrl-C will go away. Without %gui, there will still be an > inconsistency between wx and the others--but that's what the %gui magic > is for, to make wx use PyOS_InputHook like the others.
I just wanted to say thanks a LOT for this testing. Right now we're not quite in the gui code, but it's *very* useful for us to have this information. And please keep in mind that if you find out that from the ipython side we're doing something silly/backwards regarding this, we're more than happy to change it. We ultimately want the gui integration to be as painless as possible. One extra twist to consider: we're moving to a 2-process model for most of ipython, so that user interface and code execution live in separate processes. It will continue to be possible to use a one-process ipython, but we think most users will prefer the two-process model. One quirk there will be that %gui now uses PyOSInputHook to talk to the GUI event loop, but this is only called by Python if stdin is waiting for input. In a server process (like we are starting to develop), there is no interactive input (the input comes over a socket) so we'll need to worry about letting the GUI event loop work while keeping the network event loop also responsive. As our picture becomes clearer we'll make sure to update you folks as well, so we can work from both ends (ipython/mpl) to ensure a good end-user experience with minimal fuss and all relevant backends. Cheers, f ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
