Запуск графических интерфейсов в виде самостоятельных программ — вершина независимости кода, но это затрудняет связь между компонентами. Например, поскольку демонстрационные примеры выполняются здесь в виде отдельных программ, нет простого способа вызвать все их методы report из окна запускающего сценария, изображенного слева вверху на рис. 8.35. Кнопки States теперь нет, и в поток stdout попадают только сообщения от экземпляра PortableLauncher:
C:\…\PP4E\Gui\Tour> python demoAll_prg.py
demoDlg
demoRadio demoCheck demoScale
На некоторых платформах сообщения, выводимые демонстрационными программами (в том числе собственными кнопками State), могут появиться в исходном окне консоли, в котором запущен сценарий. В Windows функция os.spawnv, используемая в модуле launchmodes для запуска программ, полностью отключает поток stdout дочерней программы от родителя. В любом случае нет прямого способа одновременно вызвать методы report во всех демонстрационных программах — это отдельные программы, выполняющиеся в отдельных адресных пространствах, а не импортированные модули.
Однако существует возможность организовать вызов методов report в порожденных программах с помощью некоторых механизмов IPC, с которыми мы познакомились в главе 5. Например:
• Демонстрационные программы могут быть оснащены механизмом приема сигнала, в ответ на который они будут вызывать свой метод report.
• Они могут ждать появления в именованных или неименованных каналах строк запросов, посылаемых запускающей программой — запускающая программа demoAll стала бы фактически клиентом, а демонстрационные сценарии — серверами, отвечающими на запросы клиента.
• Независимые программы могут общаться подобным образом с помощью сокетов, универсальным инструментом, представленным в главе 5, который мы будем подробно изучать в четвертой части книги. Главный сценарий мог бы отправлять запрос на получение отчета и принимать ответ в тот же самый сокет (и контактировать с демонстрационными сценариями, выполняющимися удаленно).
• При использовании модуля multiprocessing становятся доступны его собственные инструменты IPC, такие как каналы и очереди объектов, представленные в главе 5, которые также можно было бы задействовать для организации обмена данными: демонстрационные сценарии могли бы также прослушивать каналы этого типа.
Исходя из управляемой событиями природы, программы с графическим интерфейсом должны избегать перехода в состояние ожидания — они не должны блокироваться, ожидая появления запросов в механизмах IPC, иначе они не будут откликаться на действия пользователя (и даже не смогут перерисовывать себя). Поэтому может потребоваться дополнить их потоками выполнения, обработчиками, вызываемыми по таймеру, выполнять операции чтения в неблокирующем режиме или использовать комбинации этих инструментов для периодической проверки таких входящих сообщений в каналах, fifo или сокетах. Как мы увидим далее, метод after из библиотеки tkinter, описываемый ближе к концу следующей главы, является идеальным средством для этого: он позволяет регистрировать функции обратного вызова для периодической проверки наличия входящих запросов.
Мы исследуем некоторые из имеющихся возможностей ближе к концу главы 10, после того как рассмотрим темы, связанные с созданием многопоточных графических интерфейсов. Но поскольку это выходит далеко за рамки представленных простых демонстрационных программ, я оставляю реализацию таких межпрограммных взаимодействий тем из читателей, кто лучше подготовлен к мышлению в категориях параллельных процессов.
Использованная литература:
Марк Лутц — Программирование на Python, 4-е издание, I том, 2011
