Application console for Tkinter program?
Terry Reedy
tjreedy at udel.edu
Sat Mar 5 16:16:11 EST 2016
On 3/5/2016 6:45 AM, Christian Gollwitzer wrote:
> Am 05.03.16 um 11:15 schrieb Terry Reedy:
>> On 3/5/2016 2:52 AM, Christian Gollwitzer wrote:
>>> is there an easy way to add an application console to a Tkinter program?
>>
>> Right now, you should turn the question around.
>
> so this means no, right?
Right.
>> Is there an easy way to
>> run a tkinter program within an interactive console? Answer: yes, two
>> ways, after removing the runshell stuff and mainloop call*.
>>
>> 1. Call your program mytk.py. In your system console, run 'python -i
>> myth.py'. When the code ends, control passes to the console running
>> python. Statements like 'print(nvar.get())' will be executed in the
>> main namespace of the still running program.
>
> well yes, this does work, but I should have explained why I want it the
> other way round. We have an in-house tool which is used to manipulate
> images. During production use, at some point you think "and now if I
> could just save the image that I see on screen into a PNG file". You
> know exactly that MyViewer.image is the thing that contains what you
> need, if only you had a way to tell it
> 'MyViewer.image.save("somewhere.png")'. At this point, you haven't
> started the program from an interactive python. Always running the tool
> from ipython or idle means there are useless windows hanging around, but
> if you close them, your pogram goe away. To make it even more
> complicated, the deployed version of the tool uses pyinstaller to be
> safe from environment changes.
Since idlelib.PyShell is the idle startup module as well Shell window
module, importing it imports practically all of idlelib. Not what you
want. Calling PyShell.main calls tk.Tk and tk.mainloop, also not what
you want.
> Of course, I could pack some text widget somewhere and fiddle a few
> bindings to make it do this with eval(), but a good REPL has history,
> autocompletion, syntax highlighting.... you get it. I had simply hoped,
> since idle is written in Tkinter, that it could be reused for that purpose.
(For statements, you would use exec() rather than eval().)
Not now. A console is a REPL + text display to read from and print to.
The actual IDLE REPL is PyShell.ModifiedInterpreter, which subclasses
stdlib code.InteractiveInterpreter. Most of the additions are for
interacting with the subprocess that runs user code. You should start
instead with the base class.
The Shell text display is a subclass of a subclass of a class that
contains a subclass of Toplevel with the complete IDLE Menu and a Text
widget wrapper. Again, this is too much baggage for an application console.
The idlelib ColorDelegator syntax highlighter can be reused with a Text
instance. See turtledemo.__main__ for an example. I don't know if (or
how) IDLE's autocompletion modules could be reused in their current
state. I believe Shell's history 'list' consists of the statements in
the Text instance prefixed by the '>>> ' prompt.
A simple app console might have separate text boxes for input and output.
> For pure Tcl/Tk, there is tkcon which can do exactly this and I use it
> in similar tools writtin in Tcl/Tk. I can run it via Tk.eval(), but I
> couldn't find a way to call back into Python coming from the Tkinter
> interpreter, and obviously autocompletion and syntax highlighting do not
> work well.
>
>>> For instance, can you embed IDLE into a program such that when a button
>>> is pressed, it pops up a REPL window where the running program can be
>>> examined?
>>
>> If the REPL window is defined in an imported module, the problem is
>> linking the main namespace of the tkinter program with the REPL loop in
>> such a way that commands entered into the REPL are executed in the main
>> module, not in the REPL module.
>
> I'm happy to pass the main module as an argument to REPLInit().
>
>>> 2) If you click the Shell button twice, it locks up the program, because
>>> main() obviously starts it's own mainloop
>>
>> IDLE executes user code in a separate process, linked by sockets, so
>> that execution of IDLE GUI code and user code do not interfere with each
>> other.
>
> Ahhh - OK this makes sense in the general case, but not for a console
> where you *want* your REPL to perform surgery on the main program.
>
>> I would like to refactor IDLE so that the Shell window
>> ...
>> It might be possible to adapt such a component as an embedded console.
>> An imported frame should not interfere with the main-module code or code
>> in other modules. The main problems are a) namespace linkage (mentioned
>> before),
Perhaps I should have said 'issues that require attention' rather than
'problems' ;-). As you note, b) and c) are conceptually easy, though
the execution in IDLE is complicated by having to communicate between
two processes. The execution in a within-process console would be much
easier.
>> b) the need for sys.stdin/out/err to not be None,
>
> tkcon solves this be redirecting stdin/stdout/stderr to functions which
> write to the console window.
IDLE sets sys.stdin, etc, in the user process to custom instances with
read/write methods.
>> and c) for
>> capturing exceptions in code entered in the console, so as to not crash
>> the main program.
>
> For Python exceptions I see no problem - the eval must simply be
> properly wrapped in try..except and the traceback is redirected to the
> console.
--
Terry Jan Reedy
More information about the Python-list
mailing list