[IPython-dev] Generic gui_thread + IPython: solution already exists!

Prabhu Ramachandran prabhu_r at users.sf.net
Tue Nov 16 13:41:39 CST 2004


>>>>> "FP" == Fernando Perez <Fernando.Perez at colorado.edu> writes:

    FP> Prabhu Ramachandran wrote:
    >> No, not final.  We need to do more stunts here.  I'll mail the
    >> list a patch tonight that I'd appreciate if someone with a
    >> non-threaded Tcl can test with.  Then we can change things
    >> suitably.

    FP> Send it this way, I can test it tomorrow briefly in my office
    FP> (the fedora2 destkop with threaded _tkinter but non-threaded
    FP> tcl/tk).

Well, I spent quite bit of time on this.  I can't really see why this
is a problem on non-threaded Tcl's.  This is how the gtk/wx threading
works:
 
  1. gtk/wx mainloop is running in the main thread.
  2. The timer is called from the main thread and this calls runcode
     to interpret the Python code.
  3. The interpreter console runs in the secondary thread and
     interacts with the user on the console.

Now, if I import Tkinter in the gtk/wx thread, then the Tcl
interpreter is "running" in the main thread.  `update_tk(...)` is
called in the main thread by the timer.  So, why is there a problem at
all?

With your current Shell.py, what happens if you do this::

 ipython -gthread # or -wthread

>>> import Tkinter
>>> r = Tkinter.Tk()
>>> r.update()
>>> import mayavi
>>> v = mayavi.mayavi()
>>> v.load_visualization('some_mv_file.mv')
>>> r.update()


This is essentially all I am doing in the patch.  The only difference
is that r.update() is called automatically by the timer callback.

Anyway, I think I'm done with this.  It seems to work pretty well for
me under Debian.  So with the -tk option I think, this is reasonably
good enough for now.

cheers,
prabhu




More information about the IPython-dev mailing list