[Patches] [ python-Patches-989712 ] Support using Tk without a mainloop

[SourceForge.net]

Patches item #989712, was opened at 2004-07-12 16:16
Message generated for change (Comment added) made by kbk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=989712&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Noam Raphael (noamr)
Assigned to: Kurt B. Kaiser (kbk)
Summary: Support using Tk without a mainloop

Initial Comment:
In the regular python shell, you can open Tk windows,
and they will operate even though you didn't call
Tkinter.mainloop(). This is useful, for example, when
you manipulate matplotlib graphs from within the python
shell.
This is done by a hook, installed when a tkapp object
is being initialized, which handles Tk events while the
shell is waiting for user input.

I imitated this behaviour in IDLE: When the subprocess
is idle, it checks whether Tkinter._default_root is set
(this happens when the Tkinter.Tk class, which makes a
tkapp object, is initialized, unless
Tkinter._use_default_root is False), and if so, handles
Tk events.

For me it works very well.

Have a good day,
Noam Raphael

----------------------------------------------------------------------

>Comment By: Kurt B. Kaiser (kbk)
Date: 2005-11-23 10:18

Message:
Logged In: YES 
user_id=149084

IDLE is advertised as 'pure' Python, and we'd
like to keep it that way if at all possible, so if
an API is added, it would be to Python core.  I
gather you think the patch could go in as-is for now
and we could update later if the API appears.

----------------------------------------------------------------------

Comment By: Noam Raphael (noamr)
Date: 2005-11-23 04:50

Message:
Logged In: YES 
user_id=679426

It seems to me that the python-dev discussion didn't reach a
conclusion. My patch is a sort of a workaround that lets you
use Tk interactively from IDLE - it doesn't really invoke
PyOS_InputHook. Since Tk always sets itself as
PyOS_InputHook, it solves the Tk problem, which I think is
the most common one.

A more "correct" approach, which can be easily implemented,
is to give a Python API that will call PyOS_InputHook. This
would enable IDLE to imitate the exact behaviour of the
textual interactive interpreter. It would have to be written
in C, of course, and the question is where to put that C
function: should it be in a C module which comes with IDLE,
like the old "interrupt" module, or should a function be
added to the "sys" or "os" modules?

----------------------------------------------------------------------

Comment By: Kurt B. Kaiser (kbk)
Date: 2005-11-22 20:09

Message:
Logged In: YES 
user_id=149084

Noam, Michiel, what is the current position
on this patch?  There have been a lot of related
patches and much discussion on python-dev.

----------------------------------------------------------------------

Comment By: Michiel de Hoon (mdehoon)
Date: 2005-03-03 00:35

Message:
Logged In: YES 
user_id=488897

Patch #1121234 (see my previous comment) was accepted and is
now included in CVS, clearing the way for this patch.

----------------------------------------------------------------------

Comment By: Dick Madden (dickmadden)
Date: 2005-02-14 09:57

Message:
Logged In: YES 
user_id=1219007

I've tried the updated patches with Tkinter and my rasmol
extension using the new inputhooks scheme and everything
seems to be coexisting just fine.

----------------------------------------------------------------------

Comment By: Michiel de Hoon (mdehoon)
Date: 2005-02-12 01:27

Message:
Logged In: YES 
user_id=488897

Richard Madden was kind enough to test the patch at
http://bonsai.ims.u-tokyo.ac.jp/~mdehoon/inputhooks.diff. 
This led to the discovery of two bugs in my patch and one
preexisting bug in Tkinter.py. For this second bug, I
submitted a separate patch (#1121234). I uploaded a fixed
patch at
http://bonsai.ims.u-tokyo.ac.jp/~mdehoon/inputhooks.diff;
together with patch #1121234 the input hooks appear to be
working correctly.

----------------------------------------------------------------------

Comment By: Michiel de Hoon (mdehoon)
Date: 2005-02-08 03:53

Message:
Logged In: YES 
user_id=488897

I have written a patch that solves this problem more
generally via PyOS_InputHook, as suggested by Noam. This
patch also solves the related bugs #1053687, #798058, and
supersedes patch #1049855. The patch is available at
http://bonsai.ims.u-tokyo.ac.jp/~mdehoon/inputhooks.diff

Currently, the EventHook function sits in a loop handling
Tcl events until keyboard input is detected. The presence of
Tcl events is checked every Tkinter_busywaitinterval
milliseconds. If a Tcl event arrives during this interval,
it won't be handled until the end of the interval. However,
with the default value of Tkinter_busywaitinterval = 20
milliseconds, that delay is not noticable.

Now consider the situation in which there can be more than
one input hook, for example set by different extension
modules. We cannot have EventHook sit in a loop until
keyboard input is detected, because that would prevent other
PyOS_InputHooks from being serviced. So in the EventHook in
the patch, the function returns immediately after handling
all Tcl events.

If we use Python from the command line and open a Tkinter label:
>>> from Tkinter import *
>>> l = Label()
then readline will call PyOS_InputHook ten times per second
while Python is idle. Because PyOS_InputHook points to
EventHook, we will return to the EventHook function almost
immediately. Effectively, we are then in the same situation
as before the patch. On Cygwin, however, previously mainloop
needed to be run in order for the label to appear; this is
no longer necessary with this patch. On Windows, currently
PyOS_InputHook is partially broken, as it is called only
once per command instead of ten times per second. This patch
fixed that also (same as patch #1049855).

If we have two or more input hooks, they are called
successively by readline. Since each input hook returns
after it has no more work to do, all of the input hooks are
guaranteed to be serviced.

To be able to have more than one input hook, we need to
replace PyOS_InputHook by three functions:
PyOS_AddInputHook, PyOS_RemoveInputHook, and
PyOS_CallInputHooks. For the third function, the
corresponding Python function call_input_hooks was created
in the readline module.

By adding a call to readline.call_input_hooks in run.py, as
suggested by Noam, all input hook functions are serviced
when IDLE is idle. So we can use Tkinter without calling
mainloop, and we can use other extension packages that use
input hooks. We can even do both:
>>> import Tkinter
>>> import gist # my extension module also needs input hooks
>>> Tkinter.Label() # label appears
>>> gist.window() # Graphics window appears.
works both with command-line python and IDLE.

I'm interested to hear your comments and suggestions. If
this patch seems like the way to go, I'd be happy to write
the documentation for it.


----------------------------------------------------------------------

Comment By: Michiel de Hoon (mdehoon)
Date: 2005-02-04 08:08

Message:
Logged In: YES 
user_id=488897

I agree, this is basically the same bug as #798058. The call
to readline.call_input_hook sounds like a good solution. But
the hook function should be different than the current
EventHook in _tkinter.c. That hook function sits in a loop
until a keyboard event is noticed. A problem occurs if there
is more than one hook function. Currently, that is not
possible in Python, since there is only one PyOS_InputHook.
I am working on a patch in which PyOS_InputHook is replaced
by PyOS_AddInputHook and PyOS_RemoveInputHook, so that there
can be more than one hook functions.

Now suppose that there is one hook function to handle Tk
events, and another one e.g. handling messages to windows in
Microsoft Windows. (This is a real issue for one of my
extension modules). If python sits in a loop in _tkinter.c's
EventHook until a key is pressed, the MS windows won't get
their messages.

The following structure might work better:

while(there is no keyboard input or other interesting event) {
            Call PyOS_InputHook #1
            Call PyOS_InputHook #2
            etc.
}
where each of the PyOS_InputHook functions should return if
there is no more work for them. The tricky part is to find
out which events to wait for; some of the events may be
handled by one of the PyOS_InputHook functions.

Obviously I need to do some more thinking about this.


----------------------------------------------------------------------

Comment By: Kurt B. Kaiser (kbk)
Date: 2005-02-03 20:02

Message:
Logged In: YES 
user_id=149084

Hm, this seems closely related to Bug 798058

I'd lost track of it because it got switched to tkinter.

----------------------------------------------------------------------

Comment By: Noam Raphael (noamr)
Date: 2005-01-30 06:58

Message:
Logged In: YES 
user_id=679426

in _tkinter.c, look for EventHook - you'll find the
EventHook function, which is called when the interpreter is
idle, and the Enable/Disable EventHook functions.

In readline.c, line 765, you'll find the call to
PyOS_InputHook, when waiting for input.

Perhaps a more general approach would be to let Python code
call PyOS_InputHook, for example, by defining
readline.call_input_hook() and readline.has_input_hook().
Then IDLE would be able to call them when idle, with no
Tkinter-specific code.

----------------------------------------------------------------------

Comment By: Kurt B. Kaiser (kbk)
Date: 2004-07-14 16:44

Message:
Logged In: YES 
user_id=149084

Can you give me some more information on the hook in the
Python interpreter?  Where is it in the code?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=989712&group_id=5470