mechanisms, and the widget after method (or similar) is used by the GUI program to
detect incoming output to be displayed. The non-GUI script would not be blocked by
a mainloop call.
For example, the GUI could be spawned by the non-GUI script as a separate program,
where user interaction results can be communicated from the spawned GUI to the script
using pipes, sockets, files, or other IPC mechanisms we met in Chapter 5. The advantage
to this approach is that it provides a separation of GUI and non-GUI code—the non-
GUI script would have to be modified only to spawn and wait for user results to appear
from the separate GUI program, but could otherwise be used as is. Moreover, the non-
GUI script would not be blocked while an in-process mainloop call runs (only the GUI
process would run a mainloop), and the GUI program could persist after the point at
which user inputs are required by the script, leading to fewer pop-up windows.
In other scenarios, the GUI may spawn the non-GUI script instead, and listen for its
feedback on an IPC device connected to the script’s output stream. In even more com-
plex arrangements, the GUI and non-GUI script may converse back and forth over
bidirectional connections.
Examples 10-23, 10-24, and 10-25 provide a simple example of these techniques in
action: a non-GUI script sending output to a GUI. They represent non-GUI and GUI
programs that communicate over sockets—the IPC and networking device we met
briefly in Chapter 5 and will explore in depth in the next part of the book. The important
point to notice as we study these files is the way the programs are linked: when the
non-GUI script prints to its standard output, the printed text is sent over a socket
connection to the GUI program. Other than the import and call to the socket redirection
code, the non-GUI program knows nothing at all about GUIs or sockets, and the GUI
program knows nothing about the program whose output it displays. Because this
model does not require existing scripts to be entirely rewritten to support a GUI, it is
ideal for scripts that otherwise run on the world of shells and command lines.
In terms of code, we first need some IPC linkage in between the script and the GUI.
Example 10-23 encapsulates the client-side socket connection used by non-GUI code
for reuse. As is, it’s a partial work in progress (notice the ... ellipses operator in its last
few functions—Python’s notion of “To be decided,” and equivalent to a pass in this
context). Because sockets are covered in full in Chapter 12, we’ll defer other stream
redirection modes until then, when we’ll also flesh out the rest of this module. The
version of this module here implements just the client-side connection of the standard
output stream to a socket—perfect for a GUI that wants to intercept a non-GUI script’s
printed text.
Example 10-23. PP4E\Gui\Tools\socket_stream_redirect0.py
"""
[partial] Tools for connecting streams of non-GUI programs to sockets
that a GUI (or other) can use to interact with the non-GUI program;
see Chapter 12 and PP4E\Sockets\Internet for a more complete treatment
"""
650 | Chapter 10: GUI Coding Techniques