States button is gone this time, and we only get PortableLauncher messages in stdout
as the demos start up in Example 8-34:
C:\...\PP4E\Gui\Tour> python demoAll_prg.py
demoDlg
demoRadio
demoCheck
demoScaleOn some platforms, messages printed by the demo programs (including their own State
buttons) may show up in the original console window where this script is launched;
on Windows, the os.spawnv call used to start programs by launchmodes in Exam-
ple 8-34 completely disconnects the child program’s stdout stream from its parent, but
the multiprocessing scheme of Example 8-35 does not. Regardless, there is no direct
way to call all demos’ report methods at once—they are spawned programs in distinct
address spaces, not imported modules.
Of course, we could trigger report methods in the spawned programs with some of the
Inter-Process Communication (IPC) mechanisms we met in Chapter 5. For instance:
- The demos could be instrumented to catch a user signal, and could run their
report in response. - The demos could also watch for request strings sent by the launching program to
show up in pipes or fifos; the demoAll launching program would essentially act as
a client, and the demo GUIs as servers that respond to client requests. - Independent programs can also converse this same way over sockets, the general
IPC tool introduced in Chapter 5, which we’ll study in depth in Part IV. The main
window might send a report request and receive its result on the same socket (and
might even contact demos running remotely). - If used, the multiprocessing module has IPC tools all its own, such as the object
pipes and queues we studied in Chapter 5, that could also be leveraged: demos
might listen on this type of pipe, too.
Given their event-driven nature, GUI-based programs like our demos also need to avoid
becoming stuck in wait states—they cannot be blocked while waiting for requests on
IPC devices like those above, or they won’t be responsive to users (and might not even
redraw themselves). Because of that, they may also have be augmented with threads,
timer-event callbacks, nonblocking input calls, or some combination of such techni-
ques to periodically check for incoming messages on pipes, fifos, or sockets. As we’ll
see, the tkinter after method call described near the end of the next chapter is ideal for
this: it allows us to register a callback to run periodically to check for incoming requests
on such IPC tools.
We’ll explore some of these options near the end of Chapter 10, after we’ve looked at
GUI threading topics. But since this is well beyond the scope of the current chapter’s
simple demo programs, I’ll leave such cross-program extensions up to more parallel-
minded readers for now.
Running GUI Code Three Ways | 481