[SciPy-dev] gui_thread issue
eric at enthought.com
Sat Nov 6 14:04:24 CST 2004
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:
time.sleep(1) # any value here fails.
import enthought.chaco.wxplt as plt
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
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...
Pearu Peterson wrote:
> On Sat, 6 Nov 2004, Prabhu Ramachandran wrote:
>>>>>>> "FP" == Fernando Perez <Fernando.Perez at colorado.edu> writes:
>> FP> Pearu Peterson schrieb:
>> >> Interesting idea. Here's another possibility to execute `import
>> >> gui_thread;gui_thread.start()`:
>> >> import gui_thread.start
>> FP> Sure. Short and sweet. The final question is whether to list
>> FP> start in gui_thread's __all__, since this determines the
>> FP> behavior of a
>> That sounds like a good plan. We could also use this::
>> import gui_thread.wx_start
>> Just in the rare case that someone comes up with working gui_thread
>> code for other toolkits?
> I agree.
> gui_thread.start could contain a code to pick up default backend to
>> In any case, should this be done now or once SciPy moves to SVN?
> I'd say now. Moving to SVN seems to delay but we should not stop
> contributing to scipy because of that. It does not matter much whether
> patches go to CVS or to SVN repository, SVN has an advantage only when
> we want to move directories around in the code repository.
> Scipy-dev mailing list
> Scipy-dev at scipy.net
More information about the Scipy-dev