Patches item #989712, was opened at 2004-07-12 23:16 Message generated for change (Comment added) made by noamr 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: Noam Raphael (noamr) Date: 2005-11-23 17:42 Message: Logged In: YES user_id=679426 That's right. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-11-23 17: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 11: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-23 03: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 07: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 16: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 08: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 10: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 15: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-04 03: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 13: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 23: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 _______________________________________________ Patches mailing list [email protected] http://mail.python.org/mailman/listinfo/patches
