[AstroPy] Re: gui/thread issues

[David King]

>>>>David King wrote [private note, not a previous thread]:

      David> Dear Prabhu: I noticed a forum thread discussing gui
      David> threading, e.g.:

      David>
http://www.scipy.net/pipermail/ipython-dev/2004-November/000299.html

      David> I'm asking you to have mercy on a fairly new python user.
      David> I want to use Tkinter and still have the python console
      David> remain 'live'.  I have the impression you have gone far
      David> more deeply into this than I, and that others as well have
      David> thought on it.  Yet I still have no solid doc on when
      David> tk.mainloop() is necessary and when not, on how to process
      David> Tkinter events while the python interpreter remains active
      David> to input.  I have prowled around fairly extensively in a
      David> (so-far) vain search for the definitive answer to this.


Prabhu Ramachandran wrote:

> The answer strongly depends on what particular Python interpreter you
> are using.  Under IPython (without -wthread or -gthread) or vanilla
> Python, tk.mainloop() is not necessary and in fact should not be
> called if you want the console active.  Even if you do not call the
> mainloop, events will still be processed and your application will work
> just fine.
>
> However, if you are running apps written with pyGTK or wxPython then
> you can't get away with running a Tkinter app and not calling
> mainloop.  With IPython, there is an option (-wthread/-gthread) that
> starts up the GTK and wx mainloops in a secondary thread and allows
> for an interactive console on the main thread.  In this case, if you
> start a Tkinter application, it will in all probability not work.
> This is because GTK and wx have their own event handling loops that do
> not play nicely with the Tkinter event loop in another thread.  To get
> around this, IPython also provides a -tk flag that processes tk events
> every so often.  Now this works best only if tkinter is compiled with
> thread support, if not things break badly.
>
> With the IDLE interpreter things are different since IDLE itself
> starts the mainloop and recent versions of IDLE have some issues and
> you might want to read this thread:
>
>   http://aspn.activestate.com/ASPN/Mail/Message/edu-sig/1818398
>
>
> I hope I have answered the question clearly enough and not confused
> you any more.


Dear Prabhu:

Thanks you very much for your note regarding Python-gui interaction; very
kind of you.  Some of what I've read on the net does add to my confusion,
but definitely _not_ your reply; it is helping me piece things together.

In the short run, I would be ok just using Tk alone on IPython or plain
Python, although I'd be happiest having the whole picture.  In the long run,
our project will want to serve varied users, who will no doubt want to use
python in their own way.

Russell Owen also mentioned that Tkinter's 'after[_idle]' might not work
without calling mainloop() explicitly; although perhaps I can do without
those features, I'd certainly like to know if this is the case, and what
else to watch out for of this sort....


I will continue to study what I have (that forum-thread link was helpful
too--thanks).  But I can't help feeling other python gui programmers must
run up against this problem too, and wonder why practically all the standard
Tkinter doc (including Grayson's book) just says "you gotta call mainloop()
to make anything actually appear and respond in Tkinter" (manifestly untrue).

I'm beginning to suspect that although the information I seek resides in
various people's heads, noone has written a real overview of gui event
loop/threading issues, with simple pictures of what is going on, the various
cases known to work or not work, and guidance on how to write the most
generally usable gui apps in python while keeping the interpreter 'alive'.
Ideally, I'd like to see an overview considering all the cases:
  - Tkinter, wx, GTK
  - plain python, IPython, IDLE
  - IPython -wthread -gthread and -tk flags
  - compiling Tkinter with/without thread support

Perhaps when I'm done with my researches I'll write such an article
myself...  :-).  Meanwhile, any other pointers or good clues you can give
would certainly be welcome.

There are also some intriguing comments in _tkinter.c on threading; my
'ideal guithreads article' would also provide an overview of that code, as
an aid in reading it.  (I will be dwelling on thc C/C++ side as well in my
project.  FYI, I am trying to port a C++ library that displays our in-house
types of (astronomical) data, so that it can operate under python control.
As currently used, it is already a custom Tk widget (outside of
Tkinter/python), and has a command interface as well (via a home-grown
inter-process communication framework), so that it is controlled through
both mouse and scripting.  I want to replace the current command interface
with python scripting).


As a concrete question, may I ask you how to tell if 'tkinter is compiled
with thread support'?  (I note that a 'test_threading' passed in the 'make
test' log for my python; I presume that if threading was on for my python
build, it was on for building _tkinter.so...(?))


Anyway, thanks again for your help; I hope I haven't taken too much of your
time.

Regards,

David King