| msg46362 - (view) |
Author: Noam Raphael (noamr) * |
Date: 2004-07-12 20:16 |
| 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 |
|
|
| msg46363 - (view) |
Author: Kurt B. Kaiser (kbk) *  |
Date: 2004-07-14 20:44 |
| 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? |
|
|
| msg46364 - (view) |
Author: Noam Raphael (noamr) * |
Date: 2005-01-30 11:58 |
| 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. |
|
|
| msg46365 - (view) |
Author: Kurt B. Kaiser (kbk) * |
Date: 2005-02-04 01:02 |
| 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. |
|
|
| msg46366 - (view) |
Author: Michiel de Hoon (mdehoon) * |
Date: 2005-02-04 13:08 |
| 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. |
|
|
| msg46367 - (view) |
Author: Michiel de Hoon (mdehoon) * |
Date: 2005-02-08 08:53 |
| 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. |
|
|
| msg46368 - (view) |
Author: Michiel de Hoon (mdehoon) * |
Date: 2005-02-12 06:27 |
| 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. |
|
|
| msg46369 - (view) |
Author: Dick Madden (dickmadden) |
Date: 2005-02-14 14:57 |
| 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. |
|
|
| msg46370 - (view) |
Author: Michiel de Hoon (mdehoon) * |
Date: 2005-03-03 05:35 |
| 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. |
|
|
| msg46371 - (view) |
Author: Kurt B. Kaiser (kbk) * |
Date: 2005-11-23 01:09 |
| 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. |
|
|
| msg46372 - (view) |
Author: Noam Raphael (noamr) * |
Date: 2005-11-23 09:50 |
| 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? |
|
|
| msg46373 - (view) |
Author: Kurt B. Kaiser (kbk) * |
Date: 2005-11-23 15:18 |
| 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. |
|
|
| msg46374 - (view) |
Author: Noam Raphael (noamr) * |
Date: 2005-11-23 15:42 |
| Logged In: YES user_id=679426 That's right. |
|
|
| msg46375 - (view) |
Author: Michiel de Hoon (mdehoon) * |
Date: 2005-11-23 17:54 |
| Logged In: YES user_id=488897 On the one hand, this patch is a bit of a hack, but on the other hand, finding a good solution that everybody can agree on may take a long time. I think therefore that it is OK to accept this patch (as written by Noam) now, and come back to this issue later if and when a more profound solution is found. The patch that I wrote (I put a link to it in one of the comments below) goes beyond what people agreed on on python-dev, so I think it is not appropriate to accept it now. You can just disregard it. |
|
|
| msg84306 - (view) |
Author: Guilherme Polo (gpolo) * |
Date: 2009-03-28 14:26 |
| I've changed the patch a bit and give it a quick try on the python-trunk. I didn't understand the need to verify for _tkinter while IDLE is already running, also, _tkinter.dooneevent is gone in py3k so I'm not using the module function (these are the differences in this patch). I find it nice to use Tkinter interactively on IDLE, is someone against this ? |
|
|
| msg114366 - (view) |
Author: Mark Lawrence (BreamoreBoy) * |
Date: 2010-08-19 15:10 |
| There were no comments in reply to , anyone got any comments now? If not could someone take a look at the patch and if happy get it committed. |
|
|
| msg155684 - (view) |
Author: Andrew Svetlov (asvetlov) * |
Date: 2012-03-13 22:35 |
| I've uploaded gpolo's patch converted to python 3.3 Works good on Linux |
|
|
| msg155699 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2012-03-14 00:50 |
| +1. asvetlov: please commit. |
|
|
| msg155707 - (view) |
Author: Roundup Robot (python-dev)  |
Date: 2012-03-14 01:38 |
| New changeset 535bb0bf1f49 by Andrew Svetlov in branch 'default': Issue #989712: Support using Tk without a mainloop. http://hg.python.org/cpython/rev/535bb0bf1f49 |
|
|
| msg155719 - (view) |
Author: Andrew Svetlov (asvetlov) * |
Date: 2012-03-14 04:21 |
| The issue is fixed. Thanks to Guilherme Polo. |
|
|
| msg156847 - (view) |
Author: Roger Serwy (roger.serwy) * |
Date: 2012-03-26 18:42 |
| There's a subtle bug in the currently applied patch. import tkinter a = tkinter.Tk() b = tkinter.Tk() Closing the first window will prevent closing the second window. This example may seem abstract, but it is a real issue especially when using matplotlib with multiple figures. Attached is a patch that incorporates what IdleX uses for driving the Tk/Tcl event loop. |
|
|
| msg156856 - (view) |
Author: Roundup Robot (python-dev) |
Date: 2012-03-26 19:00 |
| New changeset 837ac3abf0c5 by Andrew Svetlov in branch 'default': Issue #989712: update the code to process tkinter messages in IDLE http://hg.python.org/cpython/rev/837ac3abf0c5 |
|
|
| msg156857 - (view) |
Author: Andrew Svetlov (asvetlov) * |
Date: 2012-03-26 19:03 |
| Roger, your patch is pushed. Please next time when you reopen closed bug set 'Resolution' field to 'remind'. Thank you. |
|
|