[IPython-dev] GUI support: conflicts between IPython 0.11 and Matplotlib/ETS
Wed Feb 10 16:11:07 CST 2010
I wholly concur with Hans that running GUI apps simultaneously (e.g.
non-blocking) within IPython is crucial, but it's not necessarily the
case that because IPython doesn't start the GUI it doesn't get started
- as Christopher says, it could just be foisting the responsibility
onto the third party...
On the other hand, there are clearly some problems there (at least in
the current designs) - I've been running on the bzr ipython for a
while now along with traits GUIs, and I've noticed a big change in
behavior from IPython < .11: it used to be when you called
traitedobject.configure_traits() or traitedobject.edit_traits(), the
GUIs would pop up and everything would run fine. But now,
configure_traits is blocking (and it kills the app at the end, making
edit_traits stop working), while edit_traits has the same behavior as
before, so I use edit_traits... On the other hand, if I have a
non-interactive script (e.g. not ipython) if I run the exact same
code, edit_traits freaks out because no app object has been created.
For now I've just ignored the problem, as I mostly work in interactive
mode, but it would be way better if I could use a single function call
in either situation. But that could be resolved in either traits or
As for which layer that belongs on... personally, I think that
anything that requires "two-way" communication between IPython and the
third-party app is a bad idea do to the dangers of version desync.
e.g. if Traits has to know it's in IPython to know that it should
create the app, there's a huge potentially for the code getting
out-of-sync between the two projects whenever some new feature gets
implemented with the inevitable unintended consequences, causing
headaches for all involved. So I would advocate either
monkey-patching as some of the others here have suggested, or use some
method of passing the information through the GUI toolkit instead of
directly from IPython to the third-party if possible. I'm really only
familiar with wx, but do the other toolkits have an equivalent
wx.GetApp() function? And are there similar mechanisms that can leave
messages embedded somewhere in the toolkit as to whether or not the
PyOS_InputHook is calling as opposed to living in the event loop? If
that's the case, most everything should be left to the 3rd party
On Wed, Feb 10, 2010 at 12:26 AM, Hans Meine <firstname.lastname@example.org> wrote:
> On Mittwoch 10 Februar 2010, Brian Granger wrote:
>> When a GUI program is used interactively within IPython, the event loop of
>> the GUI should *not* be started. This is because, the PyOS_Inputhook itself
>> is responsible for iterating the GUI event loop.
> From a user's perspective (i.e. not from an MPL/ETS point of view), the above
> also rings bells: I am used to running GUI apps from within ipython, where
> (with older IPython versions) I'll get at most an exception from running
> sys.exit(), but my main window pops up and the app is running while I still
> have the interpreter available. That's an incredibly important use case to
> Now if the mainloop must not be started with 0.11, how about monkey-patching
> the application classes (i.e. QCoreApplication.exec_) in order to allow
> running unpatched programs when the GUI toolkit integration is active?
> (In fact, in our own Qt3-based python terminal, we had monkeypatched
> QApplication in order to also ignore the creation of a second app object.)
> Ciao, / / .o.
> /--/ ..o
> / / ANS ooo
> IPython-dev mailing list
More information about the IPython-dev