[Python-Dev] Event loops, PyOS_InputHook, and Tkinter

[Michiel Jan Laurens de Hoon]

Greg Ewing wrote:

>I'm not sure the event-loop situation would be
>much different with another one, anyway. From what
>I've seen of GUI toolkits, they all have their own
>form of event loop, and they all provide some way
>of hooking other things into it (as does Tkinter),
>but whichever one you're using, it likes to be in
>charge.
>
It's not because it likes to be in charge, it's because there's no other 
way to do it in Python. In our scientific visualization software, we 
also have our own event loop. I'd much rather let a Python event loop 
handle our messages. Not only would it save us time programming (setting 
up an event loop in an extension module that passes control back to 
Python when needed is tricky), it would also give better performance, it 
would work with IDLE (which an event loop in an extension module cannot 
as explained in my previous post), and it would let different extension 
modules live happily together all using the same event loop.

Tkinter is a special case among GUI toolkits because it is married to 
Tcl. It doesn't just need to handle its GUI events, it also needs to run 
the Tcl interpreter in between. Which is why Tkinter needs to be in 
charge of the event loop. For other GUI toolkits, I don't see a reason 
why they'd need their own event loop.

> Code which blocks reading from standard
>input doesn't fit very well into any of them.
>  
>
Actually, this is not difficult to accomplish. For example, try Tcl's 
wish on Linux: It will pop up a (responsive) graphics window but 
continue to read Tcl commands from the terminal. This is done via a call 
to select (on Unix) or MsgWaitForMultipleObjects (on Windows). Both of 
these can listen for terminal input and GUI events at the same time.

--Michiel.

-- 
Michiel de Hoon
Center for Computational Biology and Bioinformatics
Columbia University
1150 St Nicholas Avenue
New York, NY 10032