[SciPy-dev] gui_thread issue

Fernando Perez Fernando.Perez at colorado.edu
Sat Nov 6 16:02:57 EST 2004


eric jones wrote:
> Do we still have the problem that gui_thread can't be started from an 
> IPython resource file so that the user doesn't explicitly have to call 
> gui_thread.start() (or whatever)?  My initial attempts failed.
> I just tried something like:
> 
>     import gui_thread
>     gui_thread.start()
>     import time
>     time.sleep(1) # any value here fails.
>     import enthought.chaco.wxplt as plt

Well, I just ran in ipython:

In [1]: import gui_thread

In [2]: gui_thread.start()
<Importing wxPython...  done.>
 >>>

In [3]: import time

In [4]: time.sleep(1)

In [5]:

and it looks just fine.  I can't test the enthought import, since I don't have 
that code installed myself. Note, however, that upon exit the follwing nasty 
gets printed on my laptop, which is running a slightly outdated version of scipy:

Exception wxPython.wxc.wxPyAssertionError: u'C++ assertion 
"wxThread::IsMain()" failed in 
/usr/src/redhat/BUILD/wxPythonSrc-2.4.2.4/src/unix/threadpsx.cpp(1618): only 
main thread can be here' in <bound method __wxPyCleanup.__del__ of 
<wxPython.wx.__wxPyCleanup instance at 0x9d60984>> ignored

Things seem to quit normally, though.  On my office desktop, with recent CVS 
scipy, it all seems to work perfectly (no ugly error on quit).

I can also start the gui_thread from an ipython resource file without any 
problems:


[~]> ipython -p gui_thread
Python 2.2.3 (#1, Oct 15 2003, 23:33:35)
Type "copyright", "credits" or "license" for more information.

IPython 0.6.4.rc4 -- An enhanced Interactive Python.
?       -> Introduction to IPython's features.
%magic  -> Information about IPython's 'magic' % functions.
help    -> Python's own help system.
object? -> Details about 'object'. ?object also works, ?? prints more.

IPython profile: gui_thread

*** Starting gui_thread...
<Importing wxPython...  done.>
 >>>
In [1]: import time

In [2]: time.sleep(1)

In [3]: 99+1
Out[3]: 100

where the gui_thread profile is:


[~/.ipython]> cat ipythonrc-gui_thread
# -*- Mode: Shell-Script -*-  Not really, but shows comments correctly

# include base config and only add some extras
include ipythonrc

# import the gui_thread module first
import_mod gui_thread

# code to execute: activate gui_thread before the user gets a prompt
execute print "*** Starting gui_thread..."
execute gui_thread.start()


So on linux, with reasonably recent CVS scipy, the gui_thread support seems 
quite good.  The improvements recently discussed in this thread would be a 
usability gain (import gui_thread.start & friends), but the functionality 
seems to be there.

> and I get an error that wxPython is already imported (by the wxplt call 
> I'm sure).  This all brought dredged up unpleasant memories that are 
> documented here:
> 
>     
> http://www.scipy.org/mailinglists/mailman?fn=scipy-cvs/2002-October/000593.html
> 
> Fernando, did you figure out a way around all this import/thread madness 
> when you were working with matplotlib?  The patch I had never made it 
> into Python 1.5.2, and I haven't tried it anytime recently.  I'm hoping 
> Fernando has a less intrusive solution...

Good grief, that thread made my head spin.  I never really got anything fancy 
going.  The matplotlib hack is completely specific to matplotlib, because 
ipython and matplotlib are basically cooperating.  John added a flag inside 
the matplotlib code to indicate who is in control of the mainloop, and when 
ipython runs in -pylab mode, ipython handles this.  So while the solution 
works quite well for the end user (both with WX and with GTK), it is not a 
generic WX one, since it hinges on specific cooperation between the two programs.

As far as I could tell, the only way to obtain a generic solution for 
arbitrary third-party WX code is the complex solution which gui_thread 
implements.  But seeing how this can be encapsulated in an ipython resource 
file, I don't think it's such a problem.  And with Prabhu and Pearu's recent 
enhancements, gui_thread seems to be working extremely well, as they can run 
the full gamut of WX demos.

Best,

f




More information about the SciPy-Dev mailing list