..
02/21/2010
01
47
PM
5,000,000 part0001
02/21/2010
01
47
PM
5,000,000 part0002
02/21/2010
01
47
PM
3,814,272 part0003
3
File(s)
13,814,272 bytes
2
Dir(s)
188,654,452,736 bytes free
Конечно, проблему, которую решают эти сценарии, в настоящее время легко можно решить, просто купив более емкую флешку или предоставив детям выход в Интернет. Тем не менее, как только вы решите какую-либо проблему с помощью сценариев, вы поймете, насколько простым и гибким средством является Python, снабженный мощными встроенными инструментами, особенно удобными для разработки сценариев автоматизации, таких как эти. При грамотном использовании Python может стать для вас аналогом швейцарского армейского ножа.
Создание веб-страниц для переадресации
Перемещаться всегда трудно, даже в киберпространстве. Изменение адреса веб-сайта в Интернете может привести ко всякого рода неудобствам. Вам придется просить знакомых использовать новый адрес, а в случае всех остальных - надеяться, что по ходу дела они наткнутся на него сами. Но если ваша работа зависит от Интернета, то перемещение вызывает не меньше проблем, чем смена адреса в реальном мире.
К сожалению, таких перемещений сайта часто невозможно избежать. Как провайдеры интернет-услуг (Internet Service Providers, ISP), так и серверы с течением времени приходят и уходят. Кроме того, некоторые провайдеры допускают падение уровня обслуживания до неприемлемого уровня; если вам не повезло и случилось подписаться на услуги такого провайдера, не остается ничего иного, как сменить его, а это часто требует изменения веб-адреса.28
Представьте себе, однако, что вы пишете книги для издательства O’Reilly и опубликовали адрес своего веб-сайта во многих книгах, продаваемых по всему свету. Что делать, если качество обслуживания вашего провайдера такое, что требуется переместить сайт? Оповещение об этом сотен тысяч читателей не представляется возможным.
Вероятно, лучшее, что можно сделать, это на достаточно продолжительный промежуток времени поместить на прежнем сайте инструкции по переадресации - виртуальный эквивалент вывески «Мы переехали по новому адресу» в витрине магазина. В Сети такое объявление может автоматически отправлять посетителей на новый сайт: нужно просто оставить на прежнем сайте страничку, содержащую гиперссылку на адрес страницы на новом сайте и обеспечивающую возможность автоматического перемещения через несколько секунд. При наличии таких файлов со ссылками переадресации посетители прежнего адреса окажутся на расстоянии одного щелчка от нового адреса.
Звучит довольно просто. Но поскольку посетители могут попытаться непосредственно обратиться по адресу любого файла на вашем прежнем сайте, в общей сложности вам потребуется оставить по одному файлу со ссылкой переадресации для каждого прежнего файла - страниц
HTML, графических файлов и так далее. Если ваш прежний сервер не поддерживает возможность автоматической переадресации (мой не поддерживал), это может превратиться в проблему. Если вам нравится бездумно вводить с клавиатуры большие объемы данных, можете вручную создать все файлы со ссылками переадресации. Но с учетом того, что мой домашний сайт содержал более 100 файлов HTML к тому времени, когда я писал этот абзац, перспектива запускать редактор для каждого файла оказалась более чем достаточной мотивацией для выработки автоматизированного решения.
Файл шаблона страницы
Вот что я придумал. Прежде всего, я создал текстовый файл универсального шаблона страницы, представленный в примере 6.7 и описывающий вид всех файлов со ссылками переадресации, части которых будут заполнены позднее.
Пример 6.7. PP4E\System\Filetools\template.html
Site Redirection Page: $file$
This page has moved
This page now lives at this address:
http://$server$/$home$/$file$
Please click on the new address to jump to this page, and update any links accordingly. You will be redirectly shortly.
Чтобы полностью разобраться в этом шаблоне, требуется некоторое знание HTML - языка описания веб-страниц, который мы рассмотрим в четвертой части книги. Но для целей данного примера можно проигнорировать большую часть содержимого этого файла и сосредоточиться только на тех частях, которые окружены знаками доллара: строки $server$, $home$ и $file$ являются элементами, которые должны быть заменены действительными значениями с помощью операции глобального поиска с заменой. Значения этих элементов зависят от места, куда был перемещен сайт, и от имени файла.
Сценарий генератора страниц
Теперь, имея файл шаблона страницы, сценарий Python из примера 6.8 автоматически сгенерирует все необходимые файлы со ссылками переадресации.
Пример 6.8. PP4E\System\Filetools\site-forward.py
##############################################################################
Создает страницы со ссылками переадресации на перемещенный веб-сайт.
Генерирует по одной странице для каждого существующего на сайте файла html; сгенерированные файлы нужно выгрузить на ваш старый веб-сайт. Смотрите описание ftplib далее в книге, где представлены приемы реализации выгрузки файлов в сценариях после или в процессе создания файлов страниц. ##############################################################################
import os
servername = ‘learning-python.com’ # новый адрес сайта homedir = ‘books’ # корневой каталог сайта
sitefilesdir = r’C:\temp\public_html’ # локальный каталог с файлами сайта uploaddir = r’C:\temp\isp-forward’ # где сохранять сгенерированные файлы templatename = ‘template.html’ # шаблон для генерируемых страниц
try:
os.mkdir(uploaddir) # при необходимости создать каталог для
except OSError: pass # выгружаемых страниц
template = open(templatename).read() # загрузить или импортировать шаблон sitefiles = os.listdir(sitefilesdir) # имена файлов без пути к ним
count = 0
for filename in sitefiles:
if filename.endswith(’.html’) or filename.endswith(’.htm’): fwdname = os.path.join(uploaddir, filename) print(‘creating’, filename, ‘as’, fwdname)
filetext = template.replace(‘$server$’, servername) # вставить текст filetext = filetext.replace(‘$home$’, homedir) # и записать
filetext = filetext.replace(‘$file$’, filename) # измененный файл
open(fwdname, ‘w’).write(filetext) count += 1
print(‘Last file =>\n’, filetext, sep=’’) print(‘Done:’, count, ‘forward files created.’)
Обратите внимание, что текст шаблона загружается путем чтения файла, - шаблон можно было бы реализовать в виде импортируемой строковой переменной Python (например, в виде строки в тройных кавычках в файле модуля). Заметьте также, что все параметры конфигурации задаются инструкциями присваивания в начале сценария, а не аргументами командной строки, - поскольку они меняются очень редко, удобнее просто один раз напечатать их в самом сценарии.
Но главное, что нужно отметить, - этому сценарию совершенно безразлично, как выглядит файл шаблона. Он просто слепо выполняет глобальную подстановку с различными именами файлов для каждого генерируемого файла. Фактически файл шаблона можно изменить как угодно, и это никак не отразится на сценарии. Такое разделение труда может быть использовано в самых разных ситуациях - при создании «make-файлов», бланков писем, ответов CGI-сценариев на веб-сервере и так далее. Что касается библиотечных инструментов, сценарий генератора:
• Использует функцию os.listdir для обхода всех имен файлов в каталоге сайта (точно так же можно было бы использовать функцию glob.glob, но при этом потребовалось бы удалять пути к файлам из их имен)
• Использует строковый метод replace для поиска и замены элементов в тексте файла шаблона, ограниченных символами $, и метод end-swith, чтобы пропустить файлы, не являющиеся страницами HTML (например, изображения - большинство броузеров не знают, что делать с разметкой HTML в файлах «.jpg»)
• Использует функцию os.path.join и встроенные объекты файлов для записи полученного текста в файл со ссылками переадресации с тем же именем в выходном каталоге
Окончательным результатом является зеркальное отражение первоначального каталога веб-сайта, содержащее только файлы со ссылками переадресации, созданные по шаблону страницы. Дополнительным преимуществом сценария генератора является возможность его выполнения практически на любой платформе Python. Я запускал его на ноутбуке, работающем под управлением Windows (на котором я пишу эту книгу), а также на Linux-сервере (где находится мой сайт http:// learning-python.com). Ниже показан пример запуска этого сценария в Windows:
C:\...\PP4E\System\Filetools> python site-forward.py
creating about-lp.html as C:\temp\isp-forward\about-lp.html creating about-lp1e.html as C:\temp\isp-forward\about-lp1e.html creating about-lp2e.html as C:\temp\isp-forward\about-lp2e.html creating about-lp3e.html as C:\temp\isp-forward\about-lp3e.html creating about-lp4e.html as C:\temp\isp-forward\about-lp4e.html ...множество строк удалено...
creating training.html as C:\temp\isp-forward\training.html creating whatsnew.html as C:\temp\isp-forward\whatsnew.html creating whatsold.html as C:\temp\isp-forward\whatsold.html creating xlate-lp.html as C:\temp\isp-forward\xlate-lp.html creating zopeoutline.htm as C:\temp\isp-forward\zopeoutline.htm Last file =>
Site Redirection Page: zopeoutline.htm
This page has moved
This page now lives at this address:
http://learning-python.com/books/zopeoutline.htm
Please click on the new address to jump to this page, and update any links accordingly. You will be redirectly shortly.
Done: 124 forward files created.
Чтобы проверить результаты работы сценария, щелкните дважды на любом сгенерированном файле и посмотрите, как он выглядит в вебброузере (или выполните команду start в окне консоли DOS, например
start isp-forward\about-lp4e.html). На рис. 6.1 показано, как выглядит одна из сгенерированных страниц на моем компьютере.
Рис. 6.1. Сгенерированная страница переадресации сайта
Для завершения процесса еще необходимо установить ссылки переадресации: выгрузите все сгенерированные файлы из выходного каталога в веб-каталог вашего старого сайта. Если и это слишком большой объем для ручной работы, посмотрите, как это можно сделать автоматически с помощью Python посредством сценария загрузки на сервер по FTP в главе 13 (эту работу выполняет сценарий PP4E\Internet\Ftp\ uploadflat.py). Всерьез занявшись написанием сценариев, вы поразитесь тому, какой объем ручного труда можно автоматизировать с помощью Python. В следующем разделе представлен еще один большой пример.
Сценарий регрессивного тестирования
Рано или поздно ошибки случаются. Как мы уже видели, Python предоставляет интерфейсы доступа к различным системным службам, а также инструменты для добавления новых интерфейсов. В примере 6.9 показаны некоторые часто используемые системные инструменты в действии. В нем реализована простая система регрессивного тестирования сценариев на языке Python. Она запускает каждый сценарий Python в указанном каталоге с заданным набором входных файлов и аргументов командной строки и сравнивает вывод каждого прогона с предыдущими результатами. Этот сценарий можно было бы использовать в качестве автоматизированной системы тестирования, чтобы отлавливать ошибки, появляющиеся в результате изменений в исходных файлах программы, - в большой системе нельзя быть уверенным в том, что исправление не является в действительности скрытой ошибкой.
Пример 6.9. PP4E\System\Tester\tester.py
##############################################################################
Тестирует сценарии Python в каталоге, передает им аргументы командной строки, выполняет перенаправление stdin, перехватывает stdout, stderr и код завершения, чтобы определить наличие ошибок и отклонений от предыдущих результатов выполнения. Запуск сценариев и управление потоками ввода-вывода производится с помощью переносимого модуля subprocess (как это делает функция os.popen3 в Python 2.X). Потоки ввода-вывода всегда интерпретируются модулем subprocess как двоичные. Стандартный ввод, аргументы, стандартный вывод и стандартный вывод ошибок отображаются в файлы, находящиеся в подкаталогах.
Этот сценарий командной строки позволяет указать имя тестируемого каталога и флаг принудительной генерации выходного файла. Этот программный код можно было бы упаковать в функцию, однако то обстоятельство, что результатами сценария являются сообщения и выходные файлы, снижает практическую пользу модели вызов/ возвращаемое значение.
Дополнительные возможные расширения: можно было бы реализовать по несколько наборов аргументов командной строки и/или входных файлов для каждого тестируемого сценария и запускать их по несколько раз (использовать функцию glob для выборки нескольких файлов “.in*” в каталоге Inputs).
Возможно, было бы проще хранить все файлы, необходимые для проведения тестов, в одном и том же каталоге, но с различными расширениями, однако с течением времени их объем мог бы оказаться слишком большим.
В случае ошибок можно было бы сохранять содержимое потоков вывода stderr и stdout в подкаталоге Errors, но я предпочитаю иметь ожидаемый/фактический вывод в подкаталоге Outputs.
##############################################################################
import os, sys, glob, time
from subprocess import Popen, PIPE
# конфигурационные аргументы
testdir = sys.argv[1] if len(sys.argv) > 1 else os.curdir forcegen = len(sys.argv) > 2 print(‘Start tester:’, time.asctime()) print(‘in’, os.path.abspath(testdir))
def verbose(*args): print(‘-’*80)
for arg in args: print(arg) def quiet(*args): pass trace = quiet
# отбор сценариев для тестирования
testpatt = os.path.join(testdir, ‘Scripts’, ‘*.py’) testfiles = glob.glob(testpatt) testfiles.sort() trace(os.getcwd(), *testfiles)
numfail = 0
for testpath in testfiles: # протестировать все сценарии
testname = os.path.basename(testpath) # отбросить путь к файлу
# получить входной файл и аргументы для тестируемого сценария infile = testname.replace(‘.py’, ‘.in’)
inpath = os.path.join(testdir, ‘Inputs’, infile)
indata = open(inpath, ‘rb’).read() if os.path.exists(inpath) else b’’
argfile = testname.replace(‘.py’, ‘.args’)
argpath = os.path.join(testdir, ‘Args’, argfile)
argdata = open(argpath).read() if os.path.exists(argpath) else ''
# местоположение файлов для сохранения stdout и stderr,
# очистить предыдущие результаты outfile = testname.replace(‘.py’, ‘.out’) outpath = os.path.join(testdir, ‘Outputs’, outfile) outpathbad = outpath + ‘.bad’
if os.path.exists(outpathbad): os.remove(outpathbad)
errfile = testname.replace(‘.py’, ‘.err’) errpath = os.path.join(testdir, ‘Errors’, errfile) if os.path.exists(errpath): os.remove(errpath)
# запустить тестируемый сценарий, перенаправив потоки ввода-вывода pypath = sys.executable
command = ‘%s %s %s’ % (pypath, testpath, argdata) trace(command, indata)
process = Popen(command, shell=True, stdin=PIPE, stdout=PIPE, stderr=PIPE)
process.stdin.write(indata)
process.stdin.close()
outdata = process.stdout.read()
errdata = process.stderr.read() # при работе с двоичными файлами
exitstatus = process.wait() # данные имеют тип bytes
trace(outdata, errdata, exitstatus)
# проанализировать результаты if exitstatus != 0:
print(‘ERROR status:’, testname, exitstatus) # код заверш.
if errdata: # и/или stderr
print(‘ERROR stream:’, testname, errpath) # сохр. текст ошибки
open(errpath, ‘wb’).write(errdata)
if exitstatus or errdata: # оба признака ошибки
numfail += 1 # можно получить код завершения + код ошибки
open(outpathbad, ‘wb’).write(outdata) # сохранить вывод
elif not os.path.exists(outpath) or forcegen:
print(‘generating:’, outpath) # создать файл, если
open(outpath, ‘wb’).write(outdata) # необходимо
else:
priorout = open(outpath, ‘rb’).read() # или сравнить с прежними
# результатами
if priorout == outdata:
print(‘passed:’, testname) else:
numfail += 1
print(‘FAILED output:’, testname, outpathbad) open(outpathbad, ‘wb’).write(outdata)
print(‘Finished:’, time.asctime())
print(‘%s tests were run, %s tests failed.’ % (len(testfiles), numfail))
Мы уже познакомились с инструментами, используемыми этим сценарием, выше в этой части книги - с модулем subprocess, с функциями os.path, glob, с файлами и другими. Этот пример в значительной степени просто объединяет эти инструменты для решения поставленной задачи. Основной операцией в сценарии является сравнение нового и старого вывода с целью обнаружить изменения («регрессии»). Попутно он также манипулирует аргументами командной строки, сообщениями об ошибках, кодами завершения и файлами.
Кроме того, этот сценарий не только самый большой из тех, что встречались нам до сих пор; это также самый практичный и представительный инструмент системного администрирования (он был разработан на основе похожего инструмента, который я использовал в прошлом для выявления изменений в компиляторе). Самый лучший способ понять, как он действует, вероятно, состоит в том, чтобы продемонстрировать его на конкретных примерах. В следующем разделе демонстрируется сеанс тестирования и попутно даются пояснения по реализации сценария.
Запускаем тестирование
Основная магия сценария, выполняющего тестирование, представленного в примере 6.9, заключена в используемой им структуре каталогов. При первом запуске в каталоге тестирования (или если вы заставляете его начать сначала, передавая ему второй аргумент командной строки) сценарий:
• Составит список тестируемых сценариев в подкаталоге Scripts
• Извлечет ассоциированные с тестируемым сценарием входной файл и аргументы командной строки из подкаталогов Inputs и Args
• Сгенерирует начальные файлы для стандартного потока вывода stdout, которые обычно помещаются в подкаталог Outputs
• Сообщит о сценариях, в процессе тестирования которых либо появились сообщения об ошибках в потоке stderr, либо код завершения отличается от нуля
В случае любых ошибок, обнаруженных при тестировании сценария, сохраняется содержимое потока stderr с текстом сообщений об ошибках, а также полный вывод, сгенерированный до момента ошибки. Текст из стандартного потока ошибок сохраняется в файл в подкаталоге Errors. Содержимое стандартного вывода в случае обнаружения ошибок сохраняется в файл, имя которого имеет специальное расширение «.bad» в подкаталоге Outputs (сохранение в файле с нормальным именем в подкаталоге Outputs привело бы к ошибке тестирования после устранения ошибки в тестируемом сценарии!). Ниже приводится пример первого запуска:
C:\...\PP4E\System\Tester> python tester.py . 1 Start tester: Mon Feb 22 22:13:38 2010
in C:\Users\mark\Stuff\Books\4E\PP4E\dev\Examples\PP4E\System\Tester
generating: .\Outputs\test-basic-args.out
generating: .\Outputs\test-basic-stdout.out
generating: .\Outputs\test-basic-streams.out
generating: .\Outputs\test-basic-this.out
ERROR status: test-errors-runtime.py 1
ERROR stream: test-errors-runtime.py .\Errors\test-errors-runtime.err ERROR status: test-errors-syntax.py 1
ERROR stream: test-errors-syntax.py .\Errors\test-errors-syntax.err ERROR status: test-status-bad.py 42 generating: .\Outputs\test-status-good.out Finished: Mon Feb 22 22:13:41 2010 8 tests were run, 3 tests failed.
При запуске каждого сценария тестирующий сценарий устанавливает все заданные аргументы командной строки, передает все входные данные (если таковые имеются) в канал ввода и перехватывает стандартные потоки вывода и ошибок, сохраняет код завершения. Когда я запускал этот пример, в каталоге находилось 8 тестируемых сценариев, а также множество входных и выходных файлов. Поскольку схема именования каталогов и файлов имеет ключевое значение для данного примера, ниже приводится список с содержимым тестового каталога для этого сеанса - основным является каталог Scripts, потому что в нем собраны тестируемые сценарии:
C:\...\PP4E\System\Tester> dir /B
Args
Errors
Inputs
Outputs
Scripts
tester.py
xxold
C:\...\PP4E\System\Tester> dir /B Scripts
test-basic-args.py
test-basic-stdout.py
test-basic-streams.py
test-basic-this.py
test-errors-runtime.py
test-errors-syntax.py
test-status-bad.py
test-status-good.py
Другие подкаталоги содержат все необходимые входные данные и выходные файлы с результатами работы тестируемых сценариев:
C:\...\PP4E\System\Tester> dir /B Args
test-basic-args.args
test-status-good.args
C:\...\PP4E\System\Tester> dir /B Inputs
test-basic-args.in
test-basic-streams.in
C:\...\PP4E\System\Tester> dir /B Outputs
test-basic-args.out
test-basic-stdout.out
test-basic-streams.out
test-basic-this.out
test-errors-runtime.out.bad
test-errors-syntax.out.bad
test-status-bad.out.bad
test-status-good.out
C:\...\PP4E\System\Tester> dir /B Errors
test-errors-runtime.err
test-errors-syntax.err
Я не буду приводить здесь содержимое всех файлов (как видите, их достаточно много и все они входят в состав пакета с примерами для данной книги), но, чтобы вы могли получить некоторое представление, ниже приводится содержимое файлов, ассоциированных с тестируемым сценарием test-basic-args.py:
C:\...\PP4E\System\Tester> type Scripts\test-basic-args.py
# аргументы, потоки import sys, os
print(os.getcwd()) # в Outputs
print(sys.path[0])
print(‘[argv]’)
for arg in sys.argv: # из Args
print(arg) # в Outputs
print(‘[interaction]’) # в Outputs
text = input(‘Enter text:’) # из Inputs
rept = sys.stdin.readline() # из Inputs
sys.stdout.write(text * int(rept)) # в Outputs
C:\...\PP4E\System\Tester> type Args\test-basic-args.args
-command -line --stuff
C:\...\PP4E\System\Tester> type Inputs\test-basic-args.in
Eggs
10
C:\...\PP4E\System\Tester> type Outputs\test-basic-args.out
C:\Users\mark\Stuff\Books\4E\PP4E\dev\Examples\PP4E\System\Tester
C:\Users\mark\Stuff\Books\4E\PP4E\dev\Examples\PP4E\System\Tester\Scripts
[argv]
.\Scripts\test-basic-args.py
-command
-line
--stuff
[interaction]
Enter text:EggsEggsEggsEggsEggsEggsEggsEggsEggsEggs
А еще ниже - два файла, связанные с одной из обнаруженных ошибок. Первый из них хранит содержимое потока stderr, а второй - содержимое потока stdout, сгенерированное до момента появления ошибки. Они предназначены для анализа человеком (или с помощью других инструментов) и автоматически будут удалены в следующем сеансе тестирования:
C:\...\PP4E\System\Tester> type Errors\test-errors-runtime.err
Traceback (most recent call last):
File “.\Scripts\test-errors-runtime.py”, line 3, in print(1 / 0)
ZeroDivisionError: int division or modulo by zero
C:\...\PP4E\System\Tester> type Outputs\test-errors-runtime.out.bad
starting
Если теперь запустить тестирование еще раз, не внося никаких изменений в тестируемые сценарии, тестирующий сценарий сравнит сохраненные ранее результаты с новыми и определит отсутствие регрессий. Об ошибках, которые определяются по коду завершения, и о наличии сообщений в потоке stderr будет сообщаться, как и прежде, но в других тестах не будет обнаружено никаких отклонений от сохраненных ранее результатов:
C:\...\PP4E\System\Tester> python tester.py Start tester: Mon Feb 22 22:26:41 2010
in C:\Users\mark\Stuff\Books\4E\PP4E\dev\Examples\PP4E\System\Tester
passed: test-basic-args.py
passed: test-basic-stdout.py
passed: test-basic-streams.py
passed: test-basic-this.py
ERROR status: test-errors-runtime.py 1
ERROR stream: test-errors-runtime.py .\Errors\test-errors-runtime.err ERROR status: test-errors-syntax.py 1
ERROR stream: test-errors-syntax.py .\Errors\test-errors-syntax.err ERROR status: test-status-bad.py 42 passed: test-status-good.py Finished: Mon Feb 22 22:26:43 2010 8 tests were run, 3 tests failed.
Но когда я внес в один из тестируемых сценариев изменение, повлиявшее на его вывод (я изменил счетчик цикла, чтобы сценарий выводил меньше строк), тестирующий сценарий обнаружил регрессию и сообщил о ней - отличия между новым и старым выводом были восприняты как ошибка прохождения теста, и новый вывод был сохранен в подкаталоге Outputs в файле с расширением «.bad»:
C:\...\PP4E\System\Tester> python tester.py Start tester: Mon Feb 22 22:28:35 2010
in C:\Users\mark\Stuff\Books\4E\PP4E\dev\Examples\PP4E\System\Tester passed: test-basic-args.py
FAILED output: test-basic-stdout.py .\Outputs\test-basic-stdout.out.bad
passed: test-basic-streams.py
passed: test-basic-this.py
ERROR status: test-errors-runtime.py 1
ERROR stream: test-errors-runtime.py .\Errors\test-errors-runtime.err ERROR status: test-errors-syntax.py 1
ERROR stream: test-errors-syntax.py .\Errors\test-errors-syntax.err ERROR status: test-status-bad.py 42 passed: test-status-good.py Finished: Mon Feb 22 22:28:38 2010 8 tests were run, 4 tests failed.
C:\...\PP4E\System\Tester> type Outputs\test-basic-stdout.out.bad
begin
Spam!
Spam!Spam!
Spam!Spam!Spam!
Spam!Spam!Spam!Spam!
end
И еще одно замечание по использованию: если переменную trace в этом сценарии установить в значение verbose, он будет выводить более подробные сообщения, которые помогут вам проследить за порядком выполнения программы (но, вероятно, чересчур подробные для практического применения):
C:\...\PP4E\System\Tester> tester.py Start tester: Mon Feb 22 22:34:51 2010
in C:\Users\mark\Stuff\Books\4E\PP4E\dev\Examples\PP4E\System\Tester
C:\Users\mark\Stuff\Books\4E\PP4E\dev\Examples\PP4E\System\Tester
.\Scripts\test-basic-args.py
.\Scripts\test-basic-stdout.py
.\Scripts\test-basic-streams.py
.\Scripts\test-basic-this.py
.\Scripts\test-errors-runtime.py
.\Scripts\test-errors-syntax.py
.\Scripts\test-status-bad.py
.\Scripts\test-status-good.py
C:\Python31\python.exe .\Scripts\test-basic-args.py -command -line --stuff b’Eggs\r\n10\r\n’
b’C:\\Users\\mark\\Stuff\\Books\\4E\\PP4E\\dev\\Examples\\PP4E\\System\\Tester\r \nC:\\Users\\mark\\Stuff\\Books\\4E\\PP4E\\dev\\Examples\\PP4E\\System\\Tester\\ Scripts\r\n[argv]\r\n.\\Scripts\\test-basic-args.py\r\n-command\r\n-line\r\n--st uff\r\n[interaction]\r\nEnter text:EggsEggsEggsEggsEggsEggsEggsEggsEggsEggs’ b’’
0
passed: test-basic-args.py ...множество строк удалено...
Изучите внимательнее реализацию тестирующего сценария, чтобы получить о нем более полное представление. Естественно, о тестировании как таковом можно было бы рассказать намного больше, чем позволяет пространство книги. Например, для тестирования сценариев необязательно запускать их в дочерних процессах и вполне можно обойтись импортированием модулей и тестированием с помощью обработчиков исключений в инструкциях try. Кроме того, наш тестирующий сценарий можно было бы расширять и совершенствовать в самых разных направлениях (некоторые предложения приводятся в строке документирования). Более того, в состав Python входят два фреймворка тестирования, doctest и unittest (он же PyUnit), которые предоставляют инструменты и структуры для создания регрессивных и модульных тестов: unittest
Объектно-ориентированный фреймворк, который позволяет определять совокупности тестовых данных, ожидаемые результаты и комплекты тестов. Подклассы предоставляют методы тестирования и используют унаследованные методы проверки для определения ожидаемых результатов.
doctest
Анализирует и выполняет тесты, представленные в виде листингов интерактивного сеанса в строках документирования внутри тестируемого модуля. В листингах определяются тестовые вызовы и ожидаемые результаты - фреймворк doctest по сути повторно выполняет интерактивный сеанс.
За дополнительной информацией об инструментах и способах тестирования, сторонних или входящих в состав Python, обращайтесь к руководству по библиотеке Python, на веб-сайт PyPI и к своим любимым поисковым системам.
Тем не менее наш сценарий прекрасно справляется с задачей автоматизации тестирования сценариев командной строки на языке Python, которые выполняются как независимые программы в стандартном контексте выполнения. Поскольку наш сценарий полностью независим от тестируемых сценариев, мы можем определять новые совокупности тестовых данных без необходимости изменять реализацию тестирующего сценария. А так как он написан на языке Python, его легко и быстро можно приспосабливать под новые потребности. Как мы увидим еще раз в следующем разделе, такая простота, обеспечиваемая языком Python, может оказаться решающим преимуществом для реальных задач.
Тест прошел неудачно?
Когда в главе 13 мы узнаем, как из сценариев на языке Python отправлять электронную почту, вы, возможно, захотите улучшить этот сценарий так, чтобы он автоматически отправлял письмо в случае неудачи регулярно выполняемого теста (например, с помощью планировщика заданий cron в Unix). Благодаря этому не нужно будет даже помнить о необходимости проверить результаты. Конечно, можно развивать его еще дальше.
В одной компании я работал над добавлением звуковых эффектов в компилятор тестовых сценариев: вы слышали аплодисменты, если в процессе тестирования не было обнаружено регрессий, и совсем другие звуки в противном случае. (Советы по воспроизведению звуков смотрите в конце данной главы, в файле playfile.py.)
В другой компании, где я раньше работал, каждый вечер выполнялся тестирующий сценарий, который автоматически предотвращал сохранение файла с исходным программным кодом, вызвавшим регрессию в тесте, и посылал гневное письмо виновной стороне (и их руководству). Никто не уйдет от испанской инквизиции!
Копирование деревьев каталогов
Мой пишущий привод компакт-дисков иногда делает странные вещи. Копии файлов с необычными именами могут оказаться совершенно испорченными на CD, несмотря на то, что остальные файлы оказываются целыми и невредимыми. При этом не обязательно идет насмарку вся работа - если в большой резервной копии на CD испорчено лишь несколько файлов, я всегда могу поштучно скопировать проблемные файлы на дискеты. К несчастью, копирование в Windows путем перетаскивания мышью нехорошо поступает с такими CD: копирование прерывается, как только будет обнаружен первый такой испорченный файл. Получить удается столько файлов, сколько было скопировано к моменту возникновения ошибки, и не больше того.
Это ограничение касается не только копий на компакт-дисках. Я столкнулся с подобной проблемой, когда попытался создать резервную копию жесткого диска моего ноутбука на другом жестком диске, - операция копирования, инициированная перетаскиванием файлов мышью, прекращалась, как только встречался файл со слишком длинным или необычным именем (обычно среди сохраненных веб-страниц). Последние полчаса, потраченные на копирование, оказывались потраченными впустую - я был, мягко говоря, расстроен!
Возможно, в Windows существует какая-нибудь волшебная настройка, позволяющая справиться с этой особенностью, но я перестал ее разыскивать, когда понял, что проще написать сценарий копирования на языке Python. Сценарий cpall.py, представленный в примере 6.10, реализует один из возможных способов копирования. С его помощью я могу управлять действиями, которые выполняются при обнаружении проблемных файлов, например, пропустить файл с помощью обработчика исключения. Кроме того, этот инструмент работает и на других платформах с тем же интерфейсом и таким же результатом. По крайней мере, мне кажется, что потратить несколько минут и написать на языке Python переносимый и многократно используемый сценарий для решения некоторой задачи более выгодно, чем искать решения, работающие только на одной платформе (если они вообще есть).
Пример 6.10. PP4E\System\Filetools\epall.py
##############################################################################
Порядок использования: “python cpall.py dirFrom dirTo”.
Рекурсивно копирует дерево каталогов. Действует подобно команде Unix “cp -r dirFrom/* dirTo”, предполагая, что оба аргумента dirFrom и dirTo являются именами каталогов.
Был написан с целью обойти фатальные ошибки при копировании файлов перетаскиванием мышью в Windows (когда встреча первого же проблемного файла вызывает прекращение операции копирования) и обеспечить возможность реализации более специализированных операций копирования на языке Python. ##############################################################################
import os, sys maxfileload = 1000000 blksize = 1024 * 500
def copyfile(pathFrom, pathTo, maxfileload=maxfileload):
Копирует один файл из pathFrom в pathTo, байт в байт; использует двоичный режим для подавления операций кодирования/декодирования и преобразований символов конца строки
if os.path.getsize(pathFrom) <= maxfileload:
bytesFrom = open(pathFrom,’rb’).read() # маленький файл читать целиком open(pathTo, ‘wb’).write(bytesFrom) else:
fileFrom = open(pathFrom, ‘rb’) # большие файлы - по частям
fileTo = open(pathTo, ‘wb’) # режим b для обоих файлов
while True:
bytesFrom = fileFrom.read(blksize) # прочитать очередной блок if not bytesFrom: break # пустой после последнего блока
fileTo.write(bytesFrom)
def copytree(dirFrom, dirTo, verbose=0):
Копирует содержимое dirFrom и вложенных подкаталогов в dirTo, возвращает счетчики (files, dirs);
для представления имен каталогов, недекодируемых на других платформах, может потребоваться использовать переменные типа bytes; в Unix может потребоваться выполнять дополнительные проверки типов файлов, чтобы пропускать ссылки, файлы fifo и так далее.
fcount = dcount = 0
for filename in os.listdir(dirFrom): # для файлов/каталогов
pathFrom = os.path.join(dirFrom, filename) pathTo = os.path.join(dirTo, filename) # расширить оба пути if not os.path.isdir(pathFrom): # скопировать простые файлы
try:
if verbose > 1: print(‘copying’, pathFrom, ‘to’, pathTo) copyfile(pathFrom, pathTo)
fcount += 1 except:
print(‘Error copying’, pathFrom, ‘to’, pathTo, ‘--skipped’) print(sys.exc_info()[0], sys.exc_info()[1]) else:
if verbose: print(‘copying dir’, pathFrom, ‘to’, pathTo) try:
os.mkdir(pathTo) # создать новый подкаталог
below = copytree(pathFrom, pathTo) # спуск в подкаталоги fcount += below[0] # увеличить счетчики
dcount += below[1] # подкаталогов
dcount += 1 except:
print(‘Error creating’, pathTo, ‘--skipped’) print(sys.exc_info()[0], sys.exc_info()[1]) return (fcount, dcount)
def getargs():
Извлекает и проверяет аргументы с именами каталогов, по умолчанию возвращает None в случае ошибки
try:
dirFrom, dirTo = sys.argv[1:] except:
print(‘Usage error: cpall.py dirFrom dirTo’) else:
if not os.path.isdir(dirFrom):
print(‘Error: dirFrom is not a directory’) elif not os.path.exists(dirTo): os.mkdir(dirTo)
print(‘Note: dirTo was created’) return (dirFrom, dirTo) else:
print(‘Warning: dirTo already exists’) if hasattr(os.path, ‘samefile’):
same = os.path.samefile(dirFrom, dirTo) else:
same = os.path.abspath(dirFrom) == os.path.abspath(dirTo) if same:
print(‘Error: dirFrom same as dirTo’) else:
return (dirFrom, dirTo)
if __name__ == ‘__main__’: import time dirstuple = getargs() if dirstuple:
print(‘Copying...’)
start = time.clock()
fcount, dcount = copytree(*dirstuple)
print(‘Copied’, fcount, ‘files,’, dcount, ‘directories’, end=’ ‘) print(‘in’, time.clock() - start, ‘seconds’)
В этом сценарии реализована собственная логика рекурсивного обхода дерева каталогов, в ходе которого запоминаются пути каталогов источника и приемника. На каждом уровне она копирует простые файлы, создает каталоги в целевом пути и производит рекурсивный спуск в подкаталоги с расширением путей «из» и «в» на один уровень. Эту задачу можно запрограммировать и другими способами (например, в процессе обхода можно изменять текущий рабочий каталог с помощью функции os.chdir или использовать решение на основе функции os.walk, замещая пути «из» и «в» по мере их обхода), но на практике вполне достаточно использовать прием расширения имен каталогов при спуске.
Обратите внимание на повторно используемую в этом сценарии функцию copyfile - на тот случай, если потребуется копировать файлы размером в несколько гигабайтов, она, исходя из размера файла, решает, читать ли файл целиком или по частям (напомню, что при вызове без аргументов метода read файла он загружает весь файл в строку, находящуюся в памяти). Мы выбрали достаточно большие размеры для читаемых целиком файлов и для блоков, потому что чем больший объем мы будем читать за один присест, тем быстрее будет работать сценарий. Это решение гораздо эффективнее, чем могло бы показаться на первый взгляд, - строки, остающиеся в памяти после последней операции чтения, будут утилизироваться сборщиком мусора, и освободившаяся память будет повторно использована последующими операциями. Здесь мы снова используем двоичный режим доступа к файлам, чтобы подавить кодирование/декодирование содержимого файлов и преобразование символов конца строки - в дереве каталогов могут находиться файлы самых разных типов.
Заметьте также, что сценарий при необходимости создает целевой каталог, и перед началом копирования предполагает, что он пуст, - удалите целевой каталог перед копированием нового дерева с тем же именем, иначе к дереву результата могут присоединиться старые файлы (мы могли бы автоматически очищать целевой каталог перед копированием, но это не всегда бывает желательно). Кроме того, данный сценарий пытается определить - не являются ли исходный и конечный каталоги одним и тем же каталогом. В Unix-подобных системах, где есть такие диковины, как ссылки, функция os.path.samefile проделывает более сложную работу, чем простое сравнение абсолютных имен файлов (разные имена файлов могут означать один и тот же файл).
Ниже приводится пример копирования большого дерева примеров книги в Windows (на протяжении этой главы я буду использовать дерево с примерами к предыдущему изданию). При запуске сценарию необходимо указать имена исходного и целевого каталогов, перенаправить вывод сценария в файл, если возникает слишком много ошибок, чтобы можно было прочитать все сообщения о них сразу (например, > output.
txt), и при необходимости выполнить команду оболочки rm -r или rmdir /S (или аналогичную для соответствующей платформы), чтобы сначала удалить целевой каталог:
C:\...\PP4E\System\Filetools> rmdir /S copytemp
copytemp, Are you sure (Y/N)? y
C:\...\PP4E\System\Filetools> cpall.py C:\temp\PP3E\Examples copytemp
Note: dirTo was created
Copying...
Copied 1430 files, 185 directories in 10.4470980971 seconds
C:\...\PP4E\System\Filetools> fc /B copytemp\PP3E\Launcher.py
C:\temp\PP3E\Examples\PP3E\Launcher.py
Comparing files COPYTEMP\PP3E\Launcher.py and C:\TEMP\PP3E\EXAMPLES\PP3E\
LAUNCHER.PY
FC: no differences encountered
Вы можете воспользоваться аргументом verbose функции копирования, чтобы проследить, как протекает процесс копирования. Когда я работал над этим изданием в 2010 году, в этом примере за 10 секунд было скопировано дерево каталогов, содержащее 1430 файлов и 185 подкаталогов, - на моем удручающе медлительном нетбуке (для получения системного времени была использована встроенная функция time.clock). У вас аналогичная операция может выполняться быстрее или медленнее. Во всяком случае, это не хуже, чем самые лучшие результаты хронометража, полученные мной при перетаскивании каталогов мышью на этом же компьютере.
Каким же образом этот сценарий справляется с проблемными файлами на CD с резервными копиями? Секрет заключается в том, что он перехватывает и игнорирует исключения и продолжает обход. Чтобы скопировать с CD все хорошие файлы, я просто выполняю команду такого вида:
C:\...\PP4E\System\Filetools> python cpall.py G:\Examples C:\PP3E\Examples
Поскольку на моем компьютере, работающем под управлением Windows, привод CD доступен как диск «G:», эта команда эквивалентна копированию путем перетаскивания элемента, находящегося в папке верхнего уровня на компакт-диске, за исключением того, что сценарий Python восстанавливается после возникающих ошибок и копирует остальные файлы. В случае ошибки копирования он выводит сообщение в стандартный поток вывода и продолжает работу. При копировании большого количества файлов, вероятно, будет удобнее перенаправить стандартный вывод сценария в файл, чтобы позднее его можно было детально исследовать.
Вообще говоря, сценарию cpall можно передать любой абсолютный путь к каталогу на вашем компьютере, даже такой, который обозначает устройство, например привод CD. Для выполнения сценария в Linux можно обратиться к приводу CD, указав такой каталог, как /dev/edrom. После копирования дерева каталогов таким способом у вас может появиться желание проверить получившийся результат. Чтобы увидеть, как это делается, перейдем к следующему примеру.
Сравнение деревьев каталогов
Инженеры могут иметь параноидальные наклонности (но я вам этого не говорил). По крайней мере, ко мне это относится. Я полагаю, что все это от многолетнего наблюдения за встречающимися ошибками. Например, когда я создаю CD с резервной копией жесткого диска, то ощущаю, что за этим процессом стоит нечто слишком таинственное, чтобы я мог положиться на то, что делает программа записи CD. Может быть, я неправ, но я не могу безоговорочно доверять инструментам, которые временами калечат файлы и, кажется, выбрали третий четверг каждого месяца, чтобы вызывать крах моего компьютера с Windows. В общем, в решающий момент неплохо было бы иметь возможность как можно скорее убедиться, что скопированные на CD данные совпадают с исходными, или хотя бы найти отклонения. Если резервная копия вообще нужна, то такая возможность когда-нибудь действительно понадобится.
Поскольку доступ к компакт-дискам с данными осуществляется как к обычным деревьям каталогов, мы снова попадаем в сферу действия инструментов обхода деревьев - для проверки CD с резервной копией достаточно просто выполнить обход его каталога верхнего уровня. Если написать достаточно универсальный сценарий, его также можно будет использовать для проверки других операций копирования, например загруженных tar-файлов, резервных копий жестких дисков и так далее. Фактически, объединив сценарий cpall из предыдущего раздела с универсальным инструментом сравнения деревьев, мы получили бы переносимый и легко настраиваемый способ копирования и проверки наборов данных.
Мы уже познакомились с некоторыми механизмами обхода деревьев каталогов, но мы не сможем здесь воспользоваться ими непосредственно: нам необходимо параллельно обойти два каталога и попутно исследовать встречающиеся файлы. Кроме того, обход только одного из двух каталогов не позволит выявить файлы и каталоги, существующие только в другом каталоге. Здесь требуется некоторое более специализированное и рекурсивное решение.
Поиск расхождений между каталогами
Прежде чем приступать к программированию, необходимо выяснить, что значит сравнить два дерева каталогов. Если оба дерева имеют одинаковую структуру ветвей и глубину, проблема сводится к сравнению соответствующих файлов в каждом дереве. Однако в общем случае деревья могут иметь произвольную различную форму, глубину и так далее.
В более общем случае каталог в одном дереве может содержать больше или меньше элементов, чем соответствующий каталог в другом дереве. Если различие обусловлено наличием других файлов, это означает отсутствие соответствующих файлов для сравнения в другом каталоге. Если различие обусловлено наличием других каталогов, это означает отсутствие соответствующей ветви, в которую нужно войти. На самом деле единственный способ выявить файлы и каталоги, которые есть в одном дереве, но отсутствуют в другом, заключается в том, чтобы выявить различия в каталогах каждого уровня.
Иными словами, алгоритм сравнения деревьев должен также попутно выполнять сравнение каталогов. Начнем с реализации сравнения имен файлов для одного каталога, представленной в примере 6.11, так как это вложенная и более простая операция.
Пример 6.11. PP4E\System\Filetools\dirdiff.py
##############################################################################
Порядок использования: python dirdiff.py dir1-path dir2-path Сравнивает два каталога, пытаясь отыскать файлы, присутствующие в одном и отсутствующие в другом.
Эта версия использует функцию os.listdir и выполняет поиск различий между двумя списками. Обратите внимание, что сценарий проверяет только имена файлов, но не их содержимое, - версию, которая сравнивает результаты вызова методов .readQ^bi найдете в сценарии diffall.py.
##############################################################################
import os, sys
def reportdiffs(unique1, unique2, dir1, dir2):
Генерирует отчет о различиях для одного каталога: часть вывода функции comparedirs
if not (unique1 or unique2):
print(‘Directory lists are identical’) else:
if unique1:
print(‘Files unique to’, dir1) for file in unique1: print(’...’, file) if unique2:
print(‘Files unique to’, dir2) for file in unique2: print(‘...’, file)
def difference(seq1, seq2):
Возвращает элементы, присутствующие только в seq1;
Операция set(seq1) - set(seq2) даст аналогичный результат, но множества являются неупорядоченными коллекциями, поэтому порядок следования элементов в каталоге будет утерян
return [item for item in seq1 if item not in seq2]
def comparedirs(dir1, dir2, files1=None, files2=None):
Сравнивает содержимое каталогов, но не сравнивает содержимое файлов; функции listdir может потребоваться передавать аргумент типа bytes, если могут встречаться имена файлов, недекодируемые на других платформах
print(‘Comparing’, dir1, ‘to’, dir2)
files1 = os.listdir(dir1) if files1 is None else files1
files2 = os.listdir(dir2) if files2 is None else files2
unique1 = difference(files1, files2)
unique2 = difference(files2, files1)
reportdiffs(unique1, unique2, dir1, dir2)
return not (unique1 or unique2) # true, если нет различий
def getargs():
“Аргументы при работе в режиме командной строки” try:
dir1, dir2 = sys.argv[1:] # 2 аргумента командной строки
except:
print(‘Usage: dirdiff.py dir1 dir2’) sys.exit(1) else:
return (dir1, dir2)
if __name__ == ‘__main__’: dir1, dir2 = getargs() comparedirs(dir1, dir2)
Получив списки имен для каждого каталога, этот сценарий просто выбирает уникальные имена в первом каталоге, уникальные имена во втором каталоге и сообщает о найденных уникальных именах как о расхождениях (то есть о файлах, имеющихся в одном каталоге, но отсутствующих в другом). Функция comparedirs возвращает значение True, если расхождения не были обнаружены, что полезно для обнаружения различий при вызове из других программ.
Запустим этот сценарий с несколькими каталогами - он сообщит о найденных различиях, которые представляют уникальные имена в любом из переданных каталогов. Обратите внимание, что при этом сравниваются только структуры путем проверки имен в списках, но не содержимое файлов (эта возможность будет добавлена ниже):
C:\...\PP4E\System\Filetools> dirdiff.py C:\temp\PP3E\Examples copytemp
Comparing C:\temp\PP3E\Examples to copytemp Directory lists are identical
C:\...\PP4E\System\Filetools> dirdiff.py C:\temp\PP3E\Examples\PP3E\System ..
Comparing C:\temp\PP3E\Examples\PP3E\System to ..
Files unique to C:\temp\PP3E\Examples\PP3E\System
... App
... Exits
... Media
... moreplus.py
Files unique to ..
... more.pyc ... spam.txt ... Tester ... __init__.pyc
В основе сценария лежит функция difference: она реализует простую операцию сравнения списков. Применительно к каталогам, уникальные элементы представляют различия между деревьями, а общие элементы представляют имена файлов или подкаталогов, которые заслуживают дальнейшего сравнения или обхода. В Python 2.4 и более поздних версиях можно было бы использовать встроенные объекты типа set, если порядок следования имен в результатах не имеет значения - множества не являются последовательностями, поэтому они не сохраняют оригинальный порядок следования элементов в списках, полученных с помощью функции os.listdir. По этой причине (и чтобы не вынуждать пользователей модернизировать сценарий) вместо множеств мы будем использовать функцию, опирающуюся на использование выражения-генератора.
Поиск различий между деревьями
Мы только что реализовали инструмент, отбирающий уникальные имена файлов и каталогов. Теперь нам осталось реализовать инструмент обхода дерева, который будет применять функции из модуля dir-diff на каждом уровне, чтобы отобрать уникальные файлы и каталоги; явно сравнит содержимое общих файлов и обойдет общие каталоги. Эти операции осуществляет сценарий из примера 6.12.
Пример 6.12. PP4E\System\Filetools\diffall.py
##############################################################################
Порядок использования: “python diffall.py dir1 dir2”.
Выполняет рекурсивное сравнение каталогов: сообщает об уникальных файлах, существующих только в одном из двух каталогов, dir1 или dir2; сообщает о файлах с одинаковыми именами и с разным содержимым, присутствующих в каталогах dir1 и dir2; сообщает об разнотипных элементах с одинаковыми именами, присутствующих в каталогах dir1 и dir2; то же самое выполняется для всех подкаталогов с одинаковыми именами, находящихся внутри деревьев каталогов dir1 и dir2. Сводная информация об обнаруженных отличиях помещается в конец вывода, однако в процессе поиска в вывод добавляется дополнительная информация об отличающихся и уникальных файлах с метками “DIFF” и “unique”. Новое: (в 3 издании) для больших файлов введено ограничение на размер читаемых блоков в 1 Мбайт, (3 издание) обнаруживаются одинаковые имена файлов/каталогов, (4 издание) исключены лишние вызовы os.listdir() в dirdiff.comparedirs() за счет передачи результатов.
##############################################################################
import os, dirdiff
blocksize = 1024 * 1024 # не более 1 Мбайта на одну операцию чтения
def intersect(seq1, seq2):
Возвращает все элементы, присутствующие одновременно в seq1 и seq2; выражение set(seq1) & set(seq2) возвращает тот же результат, но множества являются неупорядоченными коллекциями, поэтому при их использовании может быть утерян порядок следования элементов, если он имеет значение для некоторых платформ
return [item for item in seq1 if item in seq2]
def comparetrees(dir1, dir2, diffs, verbose=False):
Сравнивает все подкаталоги и файлы в двух деревьях каталогов;
для предотвращения кодирования/декодирования содержимого и преобразования
символов конца строки использует двоичный режим доступа к файлам,
так как деревья могут содержать произвольные двоичные и текстовые файлы;
функции listdir может потребоваться передавать аргумент типа bytes, если
могут встречаться имена файлов, недекодируемые на других платформах
# сравнить списки с именами файлов print(‘-’ * 20)
names1 = os.listdir(dir1) names2 = os.listdir(dir2)
if not dirdiff.comparedirs(dir1, dir2, names1, names2): diffs.append(‘unique files at %s - %s’ % (dir1, dir2))
print(‘Comparing contents’) common = intersect(names1, names2) missed = common[:]
# сравнить содержимое файлов с одинаковыми именами for name in common:
path1 = os.path.join(dir1, name) path2 = os.path.join(dir2, name) if os.path.isfile(path1) and os.path.isfile(path2): missed.remove(name)
file1 = open(path1, ‘rb’) file2 = open(path2, ‘rb’) while True:
bytes1 = file1.read(blocksize) bytes2 = file2.read(blocksize) if (not bytes1) and (not bytes2):
if verbose: print(name, ‘matches’) break
if bytes1 != bytes2:
diffs.append(‘files differ at %s - %s’ % (path1, path2))
print(name, ‘DIFFERS’)
break
# рекурсивно сравнить каталоги с одинаковыми именами for name in common:
path1 = os.path.join(dir1, name) path2 = os.path.join(dir2, name) if os.path.isdir(path1) and os.path.isdir(path2): missed.remove(name)
comparetrees(path1, path2, diffs, verbose)
# одинаковые имена, но оба не являются одновременно файлами или каталогами? for name in missed:
diffs.append(‘files missed at %s - %s: %s’ % (dir1, dir2, name)) print(name, ‘DIFFERS’)
if__name__== ‘__main__’:
dir1, dir2 = dirdiff.getargs() diffs = []
comparetrees(dir1, dir2, diffs, True) # список diffs изменяется в print(‘=’ * 40) # процессе обхода, вывести diffs
if not diffs:
print(‘No diffs found.’) else:
print(‘Diffs found:’, len(diffs)) for diff in diffs: print(‘-’, diff)
В каждом каталоге этого дерева данный сценарий просто использует модуль dirdiff, чтобы обнаружить уникальные имена, а затем сравнивает общие имена, присутствующие одновременно в обоих списках содержимого каталогов. Рекурсивный спуск в подкаталоги выполняется только после сравнения всех файлов на каждом уровне, чтобы вывод сценария было удобнее воспринимать на глаз (трассировка обхода подкаталогов выводится ниже результатов сравнения файлов - они не смешиваются).
Обратите внимание на список misses, добавленный в сценарий в третьем издании книги. Очень маловероятно, но не невозможно, чтобы одно и то же имя в одном каталоге соответствовало файлу, а в другом - подкаталогу. Кроме того, обратите внимание на переменную blocksize. Как и в сценарии копирования деревьев каталогов, который мы видели выше, вместо того чтобы слепо пытаться читать файлы в память целиком, мы установили ограничение в 1 Мбайт для каждой операции чтения - на тот случай, если какие-нибудь файлы окажутся слишком большими, чтобы их можно было загрузить в память. Предыдущая версия этого сценария, без этого ограничения, которая читала файлы целиком, как показано ниже, на некоторых компьютерах возбуждала исключение MemoryError:
bytes1 = open(path1, ‘ rb’).read() bytes2 = open(path2, ‘ rb’).read() if bytes1 == bytes2: ...
Этот код проще, но менее практичен в ситуациях, когда могут встречаться очень большие файлы, не умещающиеся в память целиком (например, файлы образов CD и DVD). В новой версии файл читается в цикле порциями не более 1 Мбайта, пока не будет возвращена пустая строка, свидетельствующая об окончании файла. Файлы считаются одинаковыми, если совпадают все прочитанные из них блоки и конец файла достигнут одновременно.
Помимо всего прочего, мы обрабатываем содержимое файлов в двоичном режиме, чтобы подавить операцию декодирования их содержимого и предотвратить преобразование символов конца строки, потому что деревья каталогов могут содержать произвольные двоичные и текстовые файлы. Держим также наготове обычное замечание о необходимости передачи аргумента типа bytes функции os.listdir на платформах, где имена файлов могут оказаться недекодируемыми (например, с помощью dir1.encode()). На некоторых платформах может также потребоваться определять и пропускать некоторые файлы специальных типов, чтобы обеспечить полную универсальность, но в моих каталогах такие файлы отсутствовали, поэтому я не включил эту проверку в сценарий.
В четвертом издании было внесено одно незначительное изменение: для каждого подкаталога результаты os.listdir теперь собираются и передаются только один раз, чтобы избежать лишних вызовов функций из модуля dirdiff, - не самая большая победа, но на моем медлительном нетбуке, который я использовал во время работы над этим изданием, каждый лишний цикл на счету.
Запускаем сценарий
Так как мы уже изучали инструменты обхода деревьев, задействованные в этом сценарии, перейдем прямо к некоторым примерам его использования. При обработке идентичных деревьев во время обхода выводятся сообщения о состоянии, а в конце появляется сообщение: «No diffs found» (Расхождений не обнаружено):
C:\...\PP4E\System\Filetools> diffall.py C:\temp\PP3E\Examples
copytemp > diffs.txt
C:\...\PP4E\System\Filetools> type diffs.txt | more
Comparing C:\temp\PP3E\Examples to copytemp Directory lists are identical Comparing contents README-root.txt matches
Comparing C:\temp\PP3E\Examples\PP3E to copytemp\PP3E
Directory lists are identical
Comparing contents
echoEnvironment.pyw matches
LaunchBrowser.pyw matches
Launcher.py matches
Launcher.pyc matches
...более 2000 строк опущено...
Comparing C:\temp\PP3E\Examples\PP3E\TempParts to copytemp\PP3E\TempParts
Directory lists are identical
Comparing contents
109_0237.JPG matches
lawnlake1-jan-03.jpg matches
part-001.txt matches
part-002.html matches
No diffs found.
При использовании этого сценария я обычно устанавливаю флаг verbose в значение True и перенаправляю вывод в файл (для больших деревьев выводится слишком много информации, которую трудно воспринимать в процессе выполнения сценария). Чтобы ограничить количество сообщений, устанавливайте флаг verbose в значение False. Чтобы посмотреть, как выглядит отчет о расхождениях, нужно их создать. Для простоты я вручную изменил несколько файлов в одном из деревьев, но вы можете воспользоваться сценарием глобального поиска и замены, представленным выше в этой главе. Заодно удалим несколько файлов, чтобы в процессе поиска можно было обнаружить уникальные элементы. Последние две команды удаления из приведенных ниже воздействуют на один и тот же каталог в разных деревьях:
C:\...\PP4E\System\Filetools> notepad copytemp\PP3E\README-PP3E.txt C:\...\PP4E\System\Filetools> notepad copytemp\PP3E\System\Filetools\commands.py C:\...\PP4E\System\Filetools> notepad C:\temp\PP3E\Examples\PP3E\__init__.py
C:\...\PP4E\System\Filetools> del copytemp\PP3E\System\Filetools\cpall_visitor.py C:\...\PP4E\System\Filetools> del copytemp\PP3E\Launcher.py C:\...\PP4E\System\Filetools> del C:\temp\PP3E\Examples\PP3E\PyGadgets.py
Теперь перезапустим сценарий сравнения, чтобы обнаружить различия, и перенаправим вывод в файл, чтобы облегчить просмотр результатов. Ниже приведена лишь часть выходного отчета, в которой сообщается о различиях. При обычном использовании я сначала смотрю на сводку в конце отчета, а затем ищу в тексте отчета строки «DIFF» и «unique», если мне нужна дополнительная информация об отличиях, указанных в сводке, - конечно, этот интерфейс можно было бы сделать более дружественным, но мне вполне хватает и этого:
C:\...\PP4E\System\Filetools> diffall.py C:\temp\PP3E\Examples
copytemp > diff2.txt
C:\...\PP4E\System\Filetools> notepad diff2.txt
Comparing C:\temp\PP3E\Examples to copytemp Directory lists are identical Comparing contents README-root.txt matches
Comparing C:\temp\PP3E\Examples\PP3E to copytemp\PP3E
Files unique to C:\temp\PP3E\Examples\PP3E
... Launcher.py
Files unique to copytemp\PP3E
... PyGadgets.py
Comparing contents
echoEnvironment.pyw matches
LaunchBrowser.pyw matches
Launcher.pyc matches
...множество строк опущено...
PyGadgets_bar.pyw matches README-PP3E.txt DIFFERS todos.py matches tounix.py matches
__init__.py DIFFERS
__init__.pyc matches
Comparing C:\temp\PP3E\Examples\PP3E\System\Filetools to copytemp\PP3E\System\ Fil...
Files unique to C:\temp\PP3E\Examples\PP3E\System\Filetools
... cpall_visitor.py
Comparing contents
commands.py DIFFERS
cpall.py matches
...множество строк опущено...
Comparing C:\temp\PP3E\Examples\PP3E\TempParts to copytemp\PP3E\TempParts
Directory lists are identical
Comparing contents
109_0237.JPG matches
lawnlake1-jan-03.jpg matches
part-001.txt matches
part-002.html matches
Diffs found: 5
- unique files at C:\temp\PP3E\Examples\PP3E - copytemp\PP3E
- files differ at C:\temp\PP3E\Examples\PP3E\README-PP3E.txt -
copytemp\PP3E\README-PP3E.txt
- files differ at C:\temp\PP3E\Examples\PP3E\__init__.py -
copytemp\PP3E\__init__.py
- unique files at C:\temp\PP3E\Examples\PP3E\System\Filetools -
copytemp\PP3E\System\Filetools
- files differ at C:\temp\PP3E\Examples\PP3E\System\Filetools\commands.py -
copytemp\PP3E\System\Filetools\commands.py
Я добавил разрывы строк и отступы кое-где, чтобы уместить листинг по ширине страницы, но отчет легко понять. В дереве, насчитывающем 1430 файлов и 185 каталогов, было найдено пять различий - три файла были изменены мною вручную, а два каталога мы рассогласовали тремя командами удаления.
Проверка резервных копий
Каким же образом этот сценарий способен унять паранойю при создании резервных копий на CD? Для дублирующей проверки работы моего пишущего привода CD я выполняю команду, как показано ниже. С помощью такой команды я могу также найти изменения, произведенные после предыдущего резервного копирования. И снова, поскольку на моем компьютере привод CD представляется как «G:», я указываю путь с таким корнем. В Linux используйте корень вида /dev/cdrom или /mnt/ cdrom:
C:\...\PP4E\System\Filetools> python diffall.py Examples
g:\PP3E\Examples > diff0226
C:\...\PP4E\System\Filetools> more diff0226
...вывод опущен...
Компакт-диск крутится, сценарий сравнивает, и в конце отчета появляется информация о различиях. Пример полного отчета о различиях находится в файле diff*.txt в пакете с примерами для этой книги. А чтобы быть действительно уверенным, я выполняю следующую команду глобального сравнения - чтобы проверить все дерево с резервной копией книги на флешке (которая, с точки зрения файловой системы, ничем не отличается от CD):
C:\...\PP4E\System\Filetools> diffall.py F:\writing-backups\feb-26-10\dev
C:\Users\mark\Stuff\Books\4E\PP4E\dev > diff3.txt
C:\...\PP4E\System\Filetools> more diff3.txt
Comparing F:\writing-backups\feb-26-10\dev to C:\Users\mark\Stuff\Books\4E\PP4E\ dev
Directory lists are identical
Comparing contents
ch00.doc DIFFERS
ch01.doc matches
ch02.doc DIFFERS
ch03.doc matches
ch04.doc DIFFERS
ch05.doc matches ch06.doc DIFFERS
...множество строк опущено...
Comparing F:\writing-backups\feb-26-10\dev\Examples\PP4E\System\Filetools to C:\...
Files unique to C:\Users\mark\Stuff\Books\4E\PP4E\dev\Examples\PP4E\System\
Filetools
... copytemp
... cpall.py
... diff2.txt
... diff3.txt
... diffall.py
... diffs.txt
... dirdiff.py
... dirdiff.pyc
Comparing contents
bigext-tree.py matches
bigpy-dir.py matches
...множество строк опущено...
Diffs found: 7
- files differ at F:\writing-backups\feb-26-10\dev\ch00.doc -
C:\Users\mark\Stuff\Books\4E\PP4E\dev\ch00.doc
- files differ at F:\writing-backups\feb-26-10\dev\ch02.doc -
C:\Users\mark\Stuff\Books\4E\PP4E\dev\ch02.doc
- files differ at F:\writing-backups\feb-26-10\dev\ch04.doc -
C:\Users\mark\Stuff\Books\4E\PP4E\dev\ch04.doc
- files differ at F:\writing-backups\feb-26-10\dev\ch06.doc -
C:\Users\mark\Stuff\Books\4E\PP4E\dev\ch06.doc
- files differ at F:\writing-backups\feb-26-10\dev\TOC.txt -
C:\Users\mark\Stuff\Books\4E\PP4E\dev\TOC.txt
- unique files at F:\writing-backups\feb-26-10\dev\Examples\PP4E\System\Filetools -
C:\Users\mark\Stuff\Books\4E\PP4E\dev\Examples\PP4E\System\Filetools
- files differ at F:\writing-backups\feb-26-10\dev\Examples\PP4E\Tools\visitor.py -
C:\Users\mark\Stuff\Books\4E\PP4E\dev\Examples\PP4E\Tools\visitor.py
Данный пример показывает, что после создания предыдущей резервной копии я добавил несколько примеров и изменил несколько файлов с текстом глав. Если выполнить эту команду сразу после создания резервной копии, то радаром diffall не будет обнаружено никаких изменений, за исключением файлов, которые вообще не могут быть скопированы. Такое глобальное сравнение может занять несколько минут. Эта операция выполняет побайтовое сравнение всех файлов глав и снимков с экрана, дерева примеров и других, но это точное и полное сравнение. Дерево каталогов этой книги содержит большое количество файлов, и какая-либо менее автоматизированная процедура проверки без помощи Python была бы совершенно немыслима.
После того как этот сценарий был написан, я начал использовать его для проверки резервных копий моих ноутбуков на внешнем жестком диске, создаваемых автоматически. Для этого я запускаю сценарий cpall, написанный нами в предыдущем разделе этой главы, а затем, чтобы проверить результаты и получить список файлов, вызвавших проблемы при копировании, - сценарий сравнения, разработанный здесь. Когда я выполнял эту процедуру в последний раз, было скопировано и проверено 225 000 файлов и 15 000 каталогов, занимающих 20 Гбайт дискового пространства, - это явно не та задача, которую можно выполнить вручную!
Ниже приводятся магические заклинания, которые я вводил на моем ноутбуке с системой Windows. Здесь f:\ - это раздел на внешнем жестком диске, и вас не должно удивлять, что каждая из этих команд выполняется около получаса или даже больше на распространенном аппаратном обеспечении. Копирование, инициированное операцией перетаскивания мышью, выполняется ничуть не быстрее (если вообще выполняется!):
C:\...\System\Filetools> cpall.py c:\ f:\ > f:\copy-log.txt
C:\...\System\Filetools> diffall.py f:\ c:\ > f:\diff-log.txt
Отчет о различиях и другие идеи
Наконец, стоит заметить, что этот сценарий обнаруживает расхождения только в деревьях, не сообщая никаких подробностей о различиях в отдельных файлах. На самом деле он просто загружает и сравнивает двоичное содержимое соответствующих файлов в виде строк, давая простой результат «да/нет».
Когда мне нужны дополнительные сведения о фактических различиях в двух несовпавших файлах, я либо открываю их в редакторе, либо выполняю команду сравнения файлов на соответствующей платформе (например, fc в Windows/DOS, diff или cmp в Unix и Linux). Этот последний шаг не является переносимым решением, но для стоявших передо мною задач просто нахождение различий в дереве из 1400 файлов было значительно более важным, чем сообщение в отчете о том, в каких строках различаются эти файлы.
Конечно, поскольку в Python всегда можно вызвать команды оболочки, этот последний шаг можно автоматизировать, порождая при обнаружении различий команду diff или fc с помощью os.popen (или делать это после обхода, сканируя содержащуюся в отчете сводку). Вывод этих системных вызовов можно было бы поместить в отчет в первоначальном виде или оставить только наиболее важные его части.
Мы могли бы также открывать текстовые файлы в текстовом режиме, чтобы игнорировать различия, вызванные разными комбинациями символов завершения строк при передаче файлов между платформами, но не всегда ясно - действительно ли такие отличия должны игнорироваться (что если пользователь пожелает узнать, не изменились ли символы конца строки?). Например, после загрузки файла с веб-сайта с помощью сценария FTP, с которым мы встретимся в главе 13, сценарий diffall обнаруживает несоответствие между локальной копией файла и оригиналом на удаленном сервере. Продолжая исследования, я просто выполнил несколько инструкций в интерактивном сеансе Python:
>>> a = open('lp2e-updates.html', 'rb').read()
>>> b = open(r'C:\Mark\WEBSITE\public_html\lp2e-updates.html', 'rb').read()
>>> a == b
False
Эта проверка показывает, что двоичное содержимое локальной версии файла отличается от содержимого удаленной версии. Чтобы выяснить, обусловлено ли это различием способов завершения строк в Unix и DOS, я попробовал выполнить то же самое, но в текстовом режиме, чтобы перед сравнением символы окончания строк были приведены к стандартному символу \n:
>>> a = open('lp2e-updates.html', 'r').read()
>>> b = open(r'C:\Mark\WEBSITE\public_html\lp2e-updates.html', 'r').read()
>>> a == b
True
Теперь, чтобы отыскать различия, я выполнил следующие инструкции, которые проверяют содержимое символ за символом, пока не наткнутся на первое несоответствие (применение двоичного режима сохраняет различия):
>>> a = open('lp2e-updates.html', 'rb').read()
>>> b = open(r'C:\Mark\WEBSITE\public_html\lp2e-updates.html', 'rb').read()
>>> for (i, (ac, bc)) in enumerate(zip(a, b)):
... if ac != bc:
... print(i, repr(ac), repr(bc))
... break
37966 ‘ \r’ ‘ \n’
Этот результат означает, что в загруженном файле в байте со смещением 37 966 находится символ \r, а в локальной копии - символ \n. Эта строка в одном файле оканчивается комбинацией символов завершения строки в DOS, а в другом - символом завершения строки в Unix. Чтобы увидеть больше, можно вывести текст, окружающий несовпадение:
>>> for (i, (ac, bc)) in enumerate(zip(a, b)):
... if ac != bc:
... print(i, repr(ac), repr(bc))
... print(repr(a[i-20:i+20]))
... print(repr(b[i-20:i+20]))
... break
37966 ‘ \r’ ‘ \n’
‘ re>\r\ndef min(*args):\r\n tmp = list(arg'
‘ re>\r\ndef min(*args):\n tmp = list(args’
По всей видимости, я вставил символ завершения строки Unix в одном месте в локальной копии, там, где в загруженной версии находится комбинация символов завершения строки в DOS, - результат использования текстового режима в сценарии загрузки (который преобразует символы \n в комбинации \r\n) и многих лет использования ноутбуков и PDA, работающих под управлением Linux и Windows (вероятно, я внес это изменение, когда после редактирования этого файла в Linux я скопировал его в Windows в двоичном режиме). Такой программный код, как показано выше, можно было бы добавить в сценарий diffall, чтобы обеспечить более интеллектуальное сравнение текстовых файлов и вывод более подробной информации об отличиях в них.
Поскольку Python отлично подходит для обработки строк и файлов, можно пойти еще дальше и реализовать на языке Python сценарий, эквивалентный командам fc и diff. Фактически большая часть работы в этом направлении уже выполнена - эту задачу можно было бы существенно упростить, задействовав модуль difflib из стандартной библиотеки. Более подробные сведения о нем и примеры использования вы найдете в руководстве по библиотеке Python.
Можно было бы поступить еще умнее и не выполнять загрузку и сравнение файлов, отличающихся размерами; выполнять чтение файлов более мелкими порциями, чтобы уменьшить потребление памяти. Для большинства деревьев каталогов такие оптимизации излишни -чтение многомегабайтных файлов в строки в Python осуществляется очень быстро, а память постоянно освобождается сборщиком мусора в процессе работы.
Поскольку эти улучшения выходят за рамки задач данного сценария и размеров этой главы, его предоставляется выполнить любознательному читателю. (В этой книге официально отсутствуют упражнения для самостоятельного решения, но данное предложение выглядит именно так, не правда ли?) А теперь перейдем к исследованию способов реализации еще одной операции, часто применяемой к деревьям каталогов: поиск.
Поиск в деревьях каталогов
Инженеры любят что-нибудь изменять. В процессе написания этой книги я испытывал почти непреодолимое желание перемещать и переименовывать каталоги, переменные и совместно используемые модули в дереве примеров книги, как только мне начинало казаться, что я набрел на более подходящую структуру. На достаточно раннем этапе все было приемлемо, но по мере того как дерево становилось все более запутанным, сопровождение его превратилось в кошмар. Пути к каталогам программ и имена модулей были разбросаны по всему программному коду - в операциях импорта пакетов, вызовах программ, комментариях, файлах конфигурации и так далее.
Можно, конечно, исправлять все эти ссылки, вручную редактируя файлы в каталоге и отыскивая в них ту информацию, которая изменилась. Однако это настолько объемная работа, что для дерева примеров данной книги она практически неосуществима. Дерево примеров к предыдущему изданию содержит 186 каталогов и 1429 файлов! Очевидно, что мне был необходим инструмент, автоматизирующий обновление после производимых изменений. Существуют различные способы решения этой задачи - от команд оболочки до операций поиска, функций обхода деревьев и универсальных фреймворков. В этом и в следующем разделах мы исследуем каждый способ в отдельности, как это сделал я в поисках наиболее оптимального решения этой проблемы.
grep, glob и find
Если вы работаете в Unix-подобной системе, то наверняка знаете о существовании стандартного способа поиска строк в файлах в таких системах. Программа командной строки grep и родственные ей позволяют получить перечень всех строк в одном или нескольких файлах, содержащих строку или шаблон строки.29 Учитывая, что командные оболочки Unix автоматически расширяют (то есть «глобализуют») шаблоны имен файлов, такая команда, как приведена ниже, будет искать строку, указанную в командной строке, в файлах Python, расположенных в одном каталоге (в этом примере используется команда grep, входящая в состав облочки Cygwin для Windows, о которой я рассказывал в предыдущей главе):
C:\...\PP4E\System\Filetools> c:\cygwin\bin\grep.exe walk *.py
bigext-tree.py:for (thisDir, subsHere, filesHere) in os.walk(dirname): bigpy-path.py: for (thisDir, subsHere, filesHere) in os.walk(srcdir):
bigpy-tree.py:for (thisDir, subsHere, filesHere) in os.walk(dirname):
Как мы уже знаем, те же действия можно запрограммировать в сценарии на языке Python, организовав запуск такой команды с помощью os.system или os.popen. А в случае реализации операции поиска вручную, мы могли бы добиться похожих результатов с помощью модуля glob, с которым познакомились в главе 4, - он, подобно командной оболочке, расширяет шаблоны имен файлов в списки строк соответствующих имен файлов:
C:\...\PP4E\System\Filetools> python >>> import os
>>> for line in os.popen(r'c:\cygwin\bin\grep.exe walk *.py'):
... print(line, end='')
bigext-tree.py:for (thisDir, subsHere, filesHere) in os.walk(dirname): bigpy-path.py: for (thisDir, subsHere, filesHere) in os.walk(srcdir):
bigpy-tree.py:for (thisDir, subsHere, filesHere) in os.walk(dirname):
>>> from glob import glob
>>> for filename in glob('*.py'):
... if 'walk' in open(filename).read():
... print(filename)
bigext-tree.py
bigpy-path.py
bigpy-tree.py
К сожалению, область действия этих инструментов обычно ограничивается одним каталогом. Модуль glob способен выполнить обход нескольких каталогов при правильно сформированной строке шаблона, но он не является универсальным средством обхода деревьев каталогов, который требуется мне для обслуживания большого дерева каталогов с примерами. В Unix-подобных системах команда find оболочки предоставляет расширенные возможности для обхода всего дерева каталогов. Например, следующая команда Unix точно определила бы файлы и строки в текущем каталоге и ниже, где встречается строка popen:
find . -name “*.py” -print -exec fgrep popen {} \;
Если у вас имеется Unix-подобная команда find на всех компьютерах, которыми вы пользуетесь, можете считать, что у вас есть инструмент для обработки каталогов.
Создание собственного модуля find
Но если команда find доступна не на всех ваших компьютерах, не волнуйтесь - ее легко можно реализовать на языке Python. Ранее в стандартной библиотеке Python имелся модуль find, который я часто использовал. И хотя этот модуль был удален из библиотеки где-то между вторым и третьим изданиями этой книги, в стандартной библиотеке появилась функция os.walk, которая способна упростить создание собственного модуля find. Вместо того чтобы оплакивать исчезновение модуля, я решил потратить 10 минут и написать свой эквивалент.
В примере 6.13 представлена утилита find, реализованная на языке Python, которая выбирает все имена файлов в каталоге, соответствующие шаблону. В отличие от glob.glob, функция find.find автоматически выполняет поиск во всем дереве каталогов. А в отличие от структуры обхода os.walk, результаты find.find можно трактовать, как простую линейную группу строк.
Пример 6.13. PP4E\Tools\find.py
#!/usr/bin/python
############################################################################## Возвращает все имена файлов, соответствующие шаблону в дереве каталогов;
собственная версия модуля find, ныне исключенного из стандартной библиотеки: импортируется как “PP4E.Tools.find”; похож на оригинал, но использует цикл os.walk, не поддерживает возможность обрезания ветвей подкаталогов и может запускаться как самостоятельный сценарий;
find() - функция-генератор, использующая функцию-генератор os.walk(), возвращающая только имена файлов, соответствующие шаблону: чтобы получить весь список результатов сразу, используйте функцию findlist(); ##############################################################################
import fnmatch, os
def find(pattern, startdir=os.curdir):
for (thisDir, subsHere, filesHere) in os.walk(startdir): for name in subsHere + filesHere:
if fnmatch.fnmatch(name, pattern):
fullpath = os.path.join(thisDir, name) yield fullpath
def findlist(pattern, startdir=os.curdir, dosort=False): matches = list(find(pattern, startdir)) if dosort: matches.sort() return matches
if__name__== ‘__main__’:
import sys
namepattern, startdir = sys.argv[1], sys.argv[2] for name in find(namepattern, startdir): print(name)
Вроде бы немного делает этот программный код - по сути, он лишь несколько расширяет возможности функции os.walk, - но его функция find позволяет получить те же результаты, что давал ранее существовавший в стандартной библиотеке модуль find и одноименная утилита в Unix. Кроме того, этот модуль является более переносимым решением, и пользоваться им намного проще, чем повторять его программный код всякий раз, когда потребуется выполнить поиск. Поскольку этот файл можно использовать и как сценарий, и как библиотечный модуль, его можно применять как инструмент командной строки и вызывать из других программ.
Например, чтобы обработать все файлы с программным кодом на языке Python, находящиеся в дереве каталогов, с корнем на один уровень выше текущего рабочего каталога, достаточно просто запустить приведенную ниже команду в окне консоли. Запустите эту команду у себя, чтобы увидеть ее в действии, - в данном примере стандартный вывод сценария передается по конвейеру команде more, обеспечивающей возможность постраничного просмотра результатов, но его точно так же можно передать любой другой программе обработки, которая читает входные данные из стандартного потока ввода:
C:\...\PP4E\Tools> python find.py *.py .. | more
..\LaunchBrowser.py
..\Launcher.py
..\__init__.py
..\Preview\attachgui.py ..\Preview\customizegui.py ...множество строк опущено...
Чтобы получить еще больший контроль, выполните следующий программный код на языке Python в сценарии или в интерактивной оболочке. При таком подходе к найденным файлам можно применять любые операции, доступные в языке Python:
C:\...\PP4E\System\Filetools> python
>>> from PP4E.Tools import find # или просто import find, если
>>> for filename in find.find('*.py', '..’): # модуль находится в cwd ... if 'walk’ in open(filename).read():
... print(filename)
..\Launcher.py
..\System\Filetools\bigext-tree.py
..\System\Filetools\bigpy-path.py
..\System\Filetools\bigpy-tree.py
..\Tools\cleanpyc.py
..\Tools\find.py
..\Tools\visitor.py
Обратите внимание, что в данном случае отпала необходимость во вложенных циклах, необходимых при использовании функции os.walk, когда требуется получить список имен файлов, соответствующих шаблону, - во многих случаях такой подход концептуально выглядит проще. Заметьте также, что функция поиска является функцией-генератором, благодаря чему сценарию не приходится ждать, пока не будут выбраны все соответствующие имена файлов, - функция os.walk поставляет результаты для каждого каталога в отдельности, а функция find.find поставляет имена файлов, выбирая их из этих результатов.
Ниже приводится более сложный пример использования модуля find: следующая команда выводит все имена файлов с программным кодом на языке Python, находящиеся в дереве каталогов с корнем в C:\temp\ PP3E, начинающиеся с символа q или t. Обратите внимание, что find возвращает полные пути к файлам, начиная от указанного каталога:
C:\...\PP4E\Tools> find.py [qx]*.py C:\temp\PP3E
C:\temp\PP3E\Examples\PP3E\Database\SQLscripts\querydb.py
C:\temp\PP3E\Examples\PP3E\Gui\Tools\queuetest-gui-class.py
C:\temp\PP3E\Examples\PP3E\Gui\Tools\queuetest-gui.py
C:\temp\PP3E\Examples\PP3E\Gui\Tour\quitter.py
C:\temp\PP3E\Examples\PP3E\Internet\Other\Grail\Question.py
C:\temp\PP3E\Examples\PP3E\Internet\Other\XML\xmlrpc.py
C:\temp\PP3E\Examples\PP3E\System\Threads\queuetest.py
А ниже приводится программный код Python, который выполняет тот же поиск, но при этом выводит только имена файлов без путей к ним и размеры файлов:
C:\...\PP4E\Tools> python
>>> import os
>>> from find import find
>>> for name in find('[qx]*.py', r'C:\temp\PP3E'):
... print(os.path.basename(name), os.path.getsize(name))
querydb.py 635 queuetest-gui-class.py 1152 queuetest-gui.py 963 quitter.py 801 Question.py 817 xmlrpc.py 705 queuetest.py 1273
Модуль fnmatch
Чтобы добиться такой экономии программного кода, модуль find вызывает функцию os.walk для обхода дерева каталогов и просто возвращает соответствующие имена файлов в процессе обхода. Однако в нем содержится еще одна новинка - модуль fnmatch, входящий в состав стандартной библиотеки Python, который выполняет сопоставление имен файлов с шаблоном. Этот модуль поддерживает общие операторы в строках шаблонов: * соответствует любому количеству символов, ? соответствует одному любому символу, а [... ] и [!... ] соответствуют любым символам, перечисленным и отсутствующим в квадратных скобках, соответственно; другие символы соответствуют самим себе. В отличие от модуля re, модуль fnmatch поддерживает только самые общие операторы шаблонов командной оболочки Unix и не поддерживает полноценные регулярные выражения. Значение этого отличия мы увидим в главе 19.
Интересно отметить, что функция glob.glob тоже использует модуль fn-match для сопоставления имен: она объединяет os.listdir и fnmatch для сопоставления имен файлов в каталоге практически так же, как наша функция find.find объединяет os.walk и fnmatch для поиска совпадений в деревьях (хотя функция os.walk, в свою очередь, использует функцию os.listdir). Одно из следствий всего этого состоит в том, что имеется возможность передавать функции find.find имя начального каталога и шаблон в виде строк байтов, если необходимо подавить декодирование имен файлов, содержащих символы Юникода, как это возможно при использовании функций os.walk и glob.glob, - в результате вы будете получать имена файлов в виде строк байтов. Подробнее о символах Юникода в именах файлов рассказывается в главе 4.
Для сравнения, вызов find.find со строкой шаблона «*» является примерным эквивалентом команды оболочки, выводящей содержимое дерева каталогов, такой как dir /B /S в DOS и Windows. Поскольку шаблону «*» соответствуют все файлы, такой вызов вернет все имена файлов, присутствующих в дереве, за один проход. Подобные команды мы легко можем выполнять в сценариях на языке Python с помощью функции os.popen, поэтому следующий фрагмент выполняет ту же самую работу, но он изначально является непереносимым и приводит к запуску параллельной программы:
>>> import os
>>> for line in os.popen('dir /B /S’): print(line, end=’’)
>>> from PP4E.Tools.find import find
>>> for name in find(pattern=’*’, startdir=’.’): print(name)
Данная утилита еще будет демонстрироваться далее в этой главе и в книге, включая самые, пожалуй, убедительные демонстрации в следующем разделе и в диалоге Grep, в главе 11 - в реализации текстового редактора PyEdit с графическим интерфейсом, где она будет играть центральную роль в многопоточном внешнем инструменте поиска. Модуль find был исключен из стандартной библиотеки, но это не повод забывать о нем.
Если модулю fnmatch имя файла передается в виде строки байтов, то шаблон также должен иметь тип bytes (либо оба аргумента должны иметь тип str), потому что используемый им модуль re, реализующий сопоставление с регулярными выражениями, не позволяет смешивать типы испытуемой строки и шаблона. Это требование по наследству переходит и нашей функции find.find, принимающей имя каталога и шаблон. Подробнее о модуле re рассказывается в главе 19.
Любопытно отметить, что модуль fnmatch в Python 3.1 также преобразует строку шаблона типа bytes в строку str Юникода и обратно в ходе внутренней обработки текста, используя при этом кодировку Latin-1. Этого достаточно для большинства применений, но это может вступать в противоречие с некоторыми кодировками, которые неточно отображаются в кодировку Latin-1. В таких ситуациях параметр sys. getfilesystemencoding мог бы точнее соответствовать используемой кодировке, так как он отражает ограничения, накладываемые файловой системой (как мы узнали в главе 4, параметр sys.getdefaultencoding отражает кодировку содержимого файлов, а не их имен).
Когда функции os.walk передаются аргументы типа str, она предполагает, что имена файлов следуют соглашениям для данной платформы, и не игнорирует ошибки декодирования, возбуждаемые функцией os.listdir. В утилите «grep» в примере PyEdit в главе 11 эта картина еще больше омрачается тем фактом, что строку str шаблона, полученную из графического интерфейса, необходимо кодировать в строку bytes, используя кодировку, возможно, неподходящую для некоторых файлов. За дополнительными подробностями обращайтесь к описанию функций fnmatch.py и os.py в руководстве по стандартной библиотеке Python и к их исходному программному коду. Работа с Юникодом может оказаться очень тонким делом.
Удаление файлов с байт-кодом
Модуль find из предыдущего раздела - не самый универсальный инструмент поиска строк из тех, что мы увидим далее, но несомненно является первым важным шагом. Он отбирает файлы, по которым затем можно реализовать поиск в сценарии автоматизации. Фактически наличие одной только операции отбора файлов из дерева каталогов достаточно для решения разнообразных задач системного администрирования.
Например, одна из типичных задач, которую мне приходится выполнять регулярно, заключается в удалении всех файлов с байт-кодом в дереве каталогов. Поскольку эти файлы не всегда являются переносимыми между основными версиями Python, их желательно удалять при подготовке программы к передаче пользователям, чтобы дать возможность интерпретатору самому создать новые файлы при первой же попытке импортировать модули. Теперь, когда мы получили богатый опыт использования функции os.walk, мы могли бы отказаться от услуг посредников и использовать ее непосредственно. В примере 6.14 представлен переносимый и универсальный инструмент командной строки, принимающий аргументы, обрабатывающий исключения и поддерживающий режим трассировки и простого поиска без удаления.
Пример 6.14. PP4E\Tools\cleanpyc.py
удаляет все файлы .pyc с байт-кодом в дереве каталогов: аргумент командной строки, если он указан, интерпретируется как корневой каталог, в противном случае корневым считается текущий рабочий каталог
import os, sys findonly = False
rootdir = os.getcwd() if len(sys.argv) == 1 else sys.argv[1] found = removed = 0
for (thisDirLevel, subsHere, filesHere) in os.walk(rootdir): for filename in filesHere:
if filename.endswith(‘.pyc’):
fullname = os.path.join(thisDirLevel, filename) print(‘=>’, fullname) if not findonly: try:
os.remove(fullname) removed += 1 except:
type, inst = sys.exc_info()[:2] print(‘*’*4, ‘Failed:’, filename, type, inst) found += 1
print(‘Found’, found, ‘files, removed’, removed)
Если запустить этот сценарий, он выполнит обход дерева каталогов (CWD - по умолчанию, или дерева с корнем в каталоге, переданном в виде аргумента командной строки) и удалит все встретившиеся файлы с байт-кодом:
C:\...\Examples\PP4E> Tools\cleanpyc.py
=> C:\Users\mark\Stuff\Books\4E\PP4E\dev\Examples\PP4E\__init__.pyc => C:\Users\mark\Stuff\Books\4E\PP4E\dev\Examples\PP4E\Preview\initdata.pyc => C:\Users\mark\Stuff\Books\4E\PP4E\dev\Examples\PP4E\Preview\make_db_file.pyc => C:\Users\mark\Stuff\Books\4E\PP4E\dev\Examples\PP4E\Preview\manager.pyc => C:\Users\mark\Stuff\Books\4E\PP4E\dev\Examples\PP4E\Preview\person.pyc ...множество строк опущено...
Found 24 files, removed 24
C:\...\PP4E\Tools> cleanpyc.py .
=> .\find.pyc => .\visitor.pyc
=> .\__init__.pyc
Found 3 files, removed 3
Этот сценарий действует, но в нем выполняется чуть больше ручной работы, чем требуется. Теперь, когда мы знаем, как выполнять операцию поиска, создание сценариев на основе этих знаний становится практически тривиальным делом, которое сводится к поиску соответствующих имен файлов. Так, в примере 6.15 мы вновь используем команды оболочки, если они присутствуют в системе.
Пример 6.15. PP4E\Tools\cleanpyc-find-shell.py
отыскивает и удаляет все файлы “*.pyc” с байт-кодом в дереве каталогов, имя которого передается в виде аргумента командной строки; предполагает наличие непереносимой Unix-подобной команды find
import os, sys
rundir = sys.argv[1] if sys.platform[:3] == ‘win’:
findcmd = r’c:\cygwin\bin\find %s -name “*.pyc” -print’ % rundir else:
findcmd = ‘find %s -name “*.pyc” -print’ % rundir
print(findcmd) count = 0
for fileline in os.popen(findcmd): # обход всех строк результата,
count += 1 # завершающихся символом \n
print(fileline, end=’’) os.remove(fileline.rstrip())
print(‘Removed %d .pyc files’ % count)
Этот сценарий удалит все файлы, имена которых возвращает команда оболочки:
C:\...\PP4E\Tools> cleanpyc-find-shell.py .
c:\cygwin\bin\find . -name “*.pyc” -print
./find.pyc
./visitor.pyc
./__init__.pyc
Removed 3 .pyc files
В этом сценарии функция os.popen получает вывод программы find из оболочки Cygwin, установленной на одном из моих Windows-компьютеров, или от стандартной команды find, имеющейся в Linux. Он также абсолютно непереносим на компьютеры, работающие под управлением Windows, если на них не установлена Unix-подобная программа find, а ее нет ни на одном из моих личных компьютеров (не говоря уже о большинстве компьютеров в мире в целом). Кроме того, как мы уже знаем, запуск команд оболочки из сценариев наносит ущерб производительности, поскольку при этом приходится запускать новую независимую программу.
Мы можем значительно улучшить переносимость и производительность и при этом сохранить программный код простым, применив инструмент поиска, написанный нами на языке Python в предыдущем разделе. Новый сценарий приводится в примере 6.16.
Пример 6.16. PP4E\Tools\cleanpyc-find-py.py
отыскивает и удаляет все файлы “*.pyc” с байт-кодом в дереве каталогов, имя которого передается в виде аргумента командной строки;
использует утилиту find, написанную на языке Python, за счет чего обеспечивается переносимость;
запустите этот сценарий, чтобы удалить файлы .pyc, скомпилированные старой версией Python;
import os, sys, find # here, gets Tools.find count = 0
for filename in find.find(‘*.pyc’, sys.argv[1]): count += 1
print(filename)
os.remove(filename)
print(‘Removed %d .pyc files’ % count)
Как и прежде, этот сценарий удалит все файлы с байт-кодом в дереве каталогов с корнем, переданным в аргументе командной строки, но на этот раз наш сценарий может выполняться в любой системе, где установлен Python:
C:\...\PP4E\Tools> cleanpyc-find-py.py .
.\find.pyc
.\visitor.pyc
.\__init__.pyc
Removed 3 .pyc files
Этот сценарий переносим и позволяет избежать издержек, связанных с запуском внешних программ. Однако утилита find просто осуществляет поиск в дереве каталогов - она отбирает имена файлов, соответствующие шаблону, но не обращает внимания на их содержимое. Мы можем запрограммировать дополнительный поиск, используя результаты, полученные с помощью find, однако ручное управление позволит нам использовать процесс поиска более непосредственно. Как это можно сделать, демонстрируется в следующем разделе.
Сценарий Python для поиска в дереве
Наконец, после экспериментов с инструментами grep, glob и find для упрощения глобального поиска на всех платформах, которые могут мне когда-либо встретиться, я написал сценарий на языке Python, который выполняет основную работу вместо меня. В примере 6.17 применяются стандартные средства Python, с которыми мы познакомились в предыдущих главах: os.walk - для обхода файлов в каталоге, os.path. splitext - для пропуска файлов с расширениями, характерными для двоичных файлов, и os.path.join - для переносимого объединения путей к каталогам с именами файлов.
Поскольку он написан исключительно на языке Python, этот сценарий в равной степени может использоваться и в Linux, и в Windows. На самом деле он должен работать на любом компьютере, где установлен Python. Более того, благодаря непосредственному использованию системных вызовов он должен работать быстрее, чем при использовании приема запуска команды оболочки.
Пример 6.17. PP4E\Tools\search_all.py
############################################################################## Порядок использования: “python ...\Tools\search_all.py dir string”.
Отыскивает все файлы в указанном дереве каталогов, содержащие заданную строку; для предварительного отбора имен файлов использует интерфейс os.walk вместо
find.find; вызывает visitfile для каждой строки в результатах, полученных вызовом функции find.find с шаблоном “*”; ##############################################################################
import os, sys listonly = False
textexts = [‘.py’, ‘.pyw’, ‘.txt’, ‘.c’, ‘.h’] # игнорировать двоичные файлы
def searcher(startdir, searchkey): global fcount, vcount fcount = vcount = 0
for (thisDir, dirsHere, filesHere) in os.walk(startdir):
for fname in filesHere: # для каждого некаталога
fpath = os.path.join(thisDir, fname) # fname не содержит пути visitfile(fpath, searchkey)
def visitfile(fpath, searchkey): # для каждого некаталога
global fcount, vcount # искать строку
print(vcount+1, ‘=>’, fpath) # пропустить защищенные файлы
try:
if not listonly:
if os.path.splitext(fpath)[1] not in textexts: print(‘Skipping’, fpath) elif searchkey in open(fpath).read():
input(‘%s has %s’ % (fpath, searchkey)) fcount += 1
except:
print(‘Failed:’, fpath, sys.exc_info()[0]) vcount += 1
if __name__ == ‘__main__’:
searcher(sys.argv[1], sys.argv[2])
print(‘Found in %d files, visited %d’ % (fcount, vcount))
Функционально этот сценарий делает примерно то, что мы получили бы, вызвав его функцию visitfile для всех строк, сгенерированных нашей функцией find.find с шаблоном «*». Но поскольку эта версия настроена на поиск по содержимому файлов, она лучше соответствует своей цели. В действительности это сходство обусловлено лишь использованием шаблона «*», который вынуждает find.find выполнить обход всех файлов, а это, собственно, то, чем занята новая функция searcher. Инструмент поиска хорошо подходит для выбора файлов определенного типа, при этом преимущество данного сценария состоит в возможности произвести определенные действия непосредственно в процессе обхода.
При запуске в виде самостоятельного сценария ключ поиска передается в командной строке, а при импортировании клиент вызывает функцию searcher непосредственно. Например, чтобы найти все вхождения строки в дереве примеров для книги, выполните в команду в оболочке DOS или Unix, как показано ниже:
C:\\PP4E> Tools\search_all.py . mimetypes
1 => .\LaunchBrowser.py
2 => .\Launcher.py
3 => .\Launch_PyDemos.pyw
4 => .\Launch_PyGadgets_bar.pyw
5 => .\__init__.py
6 => .\__init__.pyc
Skipping .\__init__.pyc
7 => .\Preview\attachgui.py
8 => .\Preview\bob.pkl Skipping .\Preview\bob.pkl
...множество строк опущено: ожидает нажатия клавиши Enter после обнаружения каждого совпадения...
Found in 2 files, visited 184
Сценарий выводит список всех проверяемых им файлов, сообщает о пропущенных файлах (имена с расширениями, отсутствующими в переменной textexts, которые, как предполагается, являются двоичными файлами) и останавливается, ожидая нажатия клавиши Enter после вывода сообщения о нахождении в файле искомой строки. Точно так же сценарий search_all работает и при импортировании, но не выводит итоговой строки со статистикой (функции fcount и vcount находятся в модуле, и их также можно импортировать, чтобы получить итоговые сведения):
C:\...\PP4E\dev\Examples\PP4E> python >>> import Tools.search_all
>>> search_all.searcher(r’C:\temp\PP3E\Examples’, 'mimetypes’)
... множество строк опущено: останавливается 8раз в ожидании нажатия клавиши Enter...
>>> search_all.fcount, search_all.vcount # совпадений, файлов (8, 1429)
Каким бы образом ни запускался этот сценарий, он находит все вхождения искомой строки в целом дереве каталогов - например, изменившееся имя файла примера, объекта или каталога. Это именно то, что мне было необходимо, - по крайней мере, я так думал, пока не погрузился в дальнейшие размышления, пытаясь отыскать более полные и лучше структурированные решения, о которых рассказывается в следующем разделе.
Обязательно ознакомьтесь с обсуждением регулярных выражений в главе 19. В данном случае сценарий search_all пытается отыскать в каждом файле простую строку, применяя простое выражение проверки на вхождение, однако его легко можно было усовершенствовать, добавив возможность поиска по регулярному выражению (грубо говоря, для этого достаточно заменить оператор in вызовом метода поиска объекта регулярного выражения). Разумеется, это усовершенствование покажется вам намного проще, когда мы узнаем, как это делается.
Обратите также внимание на список textexts в примере 6.17.
В нем перечислены все допустимые расширения текстовых файлов. Решение можно сделать более универсальным и надежным, если использовать логику модуля mimetypes, с которым мы познакомимся ближе к концу этой главы, который позволяет делать предположения о типе содержимого файла по его имени. Однако список допустимых расширений обеспечивает более точное управление, и его вполне достаточно для деревьев, поиск по которым я осуществлял с помощью этого сценария.
Наконец, обратите внимание, что для простоты во всех примерах поиска по дереву каталогов в этой главе предполагается, что текстовые файлы содержат текст Юникода, закодированный с применением кодировки по умолчанию, используемой платформой. Чтобы избежать ошибок при декодировании, в примерах можно было бы открывать текстовые файлы в двоичном режиме, но при этом результаты поиска могут оказаться неточными, если сравниваемые строки байтов будут закодированы с применением различных схем кодирования. Более удачное решение вы найдете в реализации утилиты «grep» в примере приложения PyEdit с графическим интерфейсом, где обеспечивается возможность применения указанной пользователем кодировки и пропускаются те текстовые или двоичные файлы, попытка декодирования которых завершается неудачей.
Visitor: обход каталогов «++»
Лень - двигатель прогресса. Имея в своем распоряжении переносимый сценарий search_all из примера 6.17, я мог точнее находить файлы, которые было необходимо отредактировать при изменении содержимого или структуры дерева примеров в книге. Первоначально я в одном окне запускал search_all, чтобы отобрать подозрительные файлы, и вручную редактировал каждый из них в другом окне.
Однако довольно скоро и это стало утомительным. Вводить вручную имена файлов в командах запуска редактора - занятие невеселое, особенно если нужно отредактировать много файлов. Поскольку у меня всегда найдется более интересное занятие, чем десятки раз запускать редактор вручную, я стал думать, как автоматически запускать редактор для каждого подозрительного файла.
К сожалению, сценарий search_all просто выводит полученные результаты на экран. Хотя этот текст можно перехватить и проанализировать с помощью другой программы, запускаемой функцией os.popen, проще может оказаться подход, когда редактор запускается прямо во время поиска, но для этого могут потребоваться большие изменения в реализации сценария. Здесь мне пришли в голову три мысли.
Избыточность
Написав несколько утилит обхода каталогов, я понял, что каждый раз я снова и снова пишу однотипный программный код. Обход можно упростить еще больше, если скрыть детали под оболочкой и тем самым упростить повторное использование решения. Инструмент os.walk позволяет избежать необходимости писать рекурсивные функции, но при его использовании выполняются лишние действия (например, присоединение имен каталогов, вывод трассировочной информации).
Расширяемость
Исходя из прошлого опыта, очевидно, что в долгосрочной перспективе легче добавлять новые возможности в универсальный механизм поиска в каталогах в виде внешних компонентов, чем менять программный код исходного сценария. Редактирование файлов могло быть одним из возможных расширений (а что вы думаете об автоматизации операции замены текста?), поэтому предпочтительнее выглядит более обобщенное и настраиваемое решение, допускающее возможность многократного использования. Функция os.walk достаточно проста в использовании, но прием, основанный на циклах, не так хорошо поддается настройке, как использование классов.
Инкапсуляция
Опираясь на прошлый опыт, я также знаю, что всегда желательно стараться максимально скрывать детали реализации инструментов от программ. Функция os.walk скрывает свою рекурсивную природу, тем не менее она предлагает весьма специфический интерфейс, который вполне может измениться в будущем. Подобные изменения имели место в прошлом - ближе к концу этого раздела я расскажу, как из версии Python 3.X был исключен один из инструментов обхода деревьев, что сразу же привело к нарушениям в работе программного кода, использующего его. Было бы лучше скрыть подобные зависимости за более нейтральным интерфейсом, чтобы клиентский программный код не приходил в негодность, как только нам потребуется внести изменения в реализацию нашего инструмента.
Конечно, если вы в достаточной мере изучили язык Python, то вы не можете не понимать, что все эти цели указывают на необходимость использования объектно-ориентированного подхода к реализации обхода и поиска. В примере 6.18 приводится одна из возможных реализаций этих целей. Этот модуль экспортирует универсальный класс FileVisitor, который в основном служит лишь оболочкой для os.walk, облегчающей использование и расширение, а также базовый класс SearchVisitor, обобщающий идею поиска в каталоге.
Сам по себе класс SearchVisitor делает то же самое, что делал сценарий search_all, но кроме этого, он открывает новые возможности по на-
стройке процедуры поиска - какие-то черты его поведения могут модифицироваться путем перегрузки методов в подклассах. Более того, его базовая логика поиска может быть использована везде, где требуется поиск: достаточно просто определить подкласс, в котором будут добавлены специфические для поиска расширения. То же относится и к классу FileVisitor - переопределяя его методы и используя его атрибуты, можно внедряться в процесс обхода деревьев, используя приемы ООП. Это обычное дело в программировании - как только вы начинаете достаточно часто решать одни и те же тактические задачи, они наталкивают вас на подобные стратегические размышления.
Пример 6.18. PP4E\Tools\visitor.py
############################################################################## Тест: “python ...\Tools\visitor.py dir testmask [строка]”. Использует классы и подклассы для сокрытия деталей использования функции os.walk при обходе и поиске; testmask - битовая маска, каждый бит в которой определяет тип самопроверки; смотрите также: подклассы visitor_*/.py; вообще подобные
фреймворки должны использовать псевдочастные имена вида __X, однако в данной
реализации все имена экспортируются для использования в подклассах и клиентами; переопределите метод reset для поддержки множественных, независимых объектов-обходчиков, требующих обновлений в подклассах; ##############################################################################
import os, sys class FileVisitor:
Выполняет обход всех файлов, не являющихся каталогами, ниже startDir (по умолчанию ‘.’); при создании собственных обработчиков файлов/каталогов переопределяйте методы visit*; аргумент/атрибут context является необязательным и предназначен для хранения информации, специфической для подкласса; переключатель режима трассировки trace: 0 -нет трассировки, 1 - подкаталоги, 2 - добавляются файлы
def __init__(self, context=None, trace=2):
self.fcount = 0 self.dcount = 0 self.context = context self.trace = trace
def run(self, startDir=os.curdir, reset=True): if reset: self.reset()
for (thisDir, dirsHere, filesHere) in os.walk(startDir): self.visitdir(thisDir)
for fname in filesHere: # для некаталогов
fpath = os.path.join(thisDir, fname) # fname не содержит пути self.visitfile(fpath)
def reset(self): # используется обходчиками,
self.fcount = self.dcount = 0 # выполняющими обход независимо
def visitdir(self, dirpath): # вызывается для каждого каталога
self.dcount += 1 # переопределить или расширить
if self.trace > 0: print(dirpath, ‘...’)
def visitfile(self, filepath): # вызывается для каждого файла
self.fcount += 1 # переопределить или расширить
if self.trace > 1: print(self.fcount, ‘=>’, filepath)
class SearchVisitor(FileVisitor):
Выполняет поиск строки в файлах, находящихся в каталоге startDir и ниже; в подклассах: переопределите метод visitmatch, списки расширений, метод candidate, если необходимо; подклассы могут использовать testexts, чтобы определить типы файлов, в которых может выполняться поиск (но могут также переопределить метод candidate, чтобы использовать модуль mimetypes для определения файлов с текстовым содержимым: смотрите далее)
skipexts = []
testexts = [‘.txt’, ‘.py’, ‘.pyw’, ‘.html’, ‘.c’, ‘.h’] # допустимые расш. #skipexts = [‘.gif’, ‘.jpg’, ‘.pyc’, ‘.o’, ‘.a’, ‘.exe’] # или недопустимые
# расширения
def __init__(self, searchkey, trace=2):
FileVisitor.__init__(self, searchkey, trace) self.scount = 0
def reset(self): # в независимых обходчиках
self.scount = 0
def candidate(self, fname): # переопределить, если желательно
ext = os.path.splitext(fname)[1] # использовать модуль mimetypes if self.testexts:
return ext in self.testexts # если допустимое расширение else: # или, если недопустимое
return ext not in self.skipexts # расширение
def visitfile(self, fname): # поиск строки
FileVisitor.visitfile(self, fname) if not self.candidate(fname):
if self.trace > 0: print(‘Skipping’, fname) else:
text = open(fname).read() # ‘rb’ для недекодируемого текста
if self.context in text: # или text.find() != -1
self.visitmatch(fname, text) self.scount += 1
def visitmatch(self, fname, text): # обработка совпадения
print(‘%s has %s’ % (fname, self.context)) # переопределить
if __name__ == ‘__main__’:
# логика самотестирования dolist = 1
dosearch = 2 # 3 = список и поиск
donext = 4 # при добавлении следующего теста
def selftest(testmask): if testmask & dolist:
visitor = FileVisitor(trace=2) visitor.run(sys.argv[2]) print(‘Visited %d files and %d dirs’ %
(visitor.fcount, visitor.dcount))
if testmask & dosearch:
visitor = SearchVisitor(sys.argv[3], trace=0)
visitor.run(sys.argv[2])
print(‘Found in %d files, visited %d’ %
(visitor.scount, visitor.fcount))
selftest(int(sys.argv[1])) # например, 3 = dolist | dosearch
Этот модуль служит в основном для экспорта классов, используемых другими программами, но и при запуске в виде самостоятельного сценария делает кое-что полезное. Если вызвать его как сценарий с одним аргументом 1, он создаст и запустит объект FileVisitor и выведет полный список всех файлов и каталогов, начиная с того каталога, откуда он вызван, и ниже:
C:\...\PP4E\Tools> visitor.py 1 C:\temp\PP3E\Examples
C:\temp\PP3E\Examples ...
1 => C:\temp\PP3E\Examples\README-root.txt C:\temp\PP3E\Examples\PP3E ...
2 => C:\temp\PP3E\Examples\PP3E\echoEnvironment.pyw
3 => C:\temp\PP3E\Examples\PP3E\LaunchBrowser.pyw
4 => C:\temp\PP3E\Examples\PP3E\Launcher.py
5 => C:\temp\PP3E\Examples\PP3E\Launcher.pyc
...множество строк опущено (передайте по конвейеру команде more или перенаправьте в файл)...
1424 => C:\temp\PP3E\Examples\PP3E\System\Threads\thread-count.py
1425 => C:\temp\PP3E\Examples\PP3E\System\Threads\thread1.py C:\temp\PP3E\Examples\PP3E\TempParts ...
1426 => C:\temp\PP3E\Examples\PP3E\TempParts\109_0237.JPG
1427 => C:\temp\PP3E\Examples\PP3E\TempParts\lawnlake1-jan-03.jpg
1428 => C:\temp\PP3E\Examples\PP3E\TempParts\part-001.txt
1429 => C:\temp\PP3E\Examples\PP3E\TempParts\part-002.html Visited 1429 files and 186 dirs
Если же вызвать этот сценарий с 2 в первом аргументе, он создаст и запустит объект SearchVisitor, используя третий аргумент в качестве ключа поиска. Эта форма напоминает запуск знакомого нам сценария search_all.py, но в данном случае при обнаружении совпадений сценарий не останавливается:
C:\...\PP4E\Tools> visitor.py 2 C:\temp\PP3E\Examples mimetypes
C:\temp\PP3E\Examples\PP3E\extras\LosAlamosAdvancedClass\day1-system\data.txt has mimetypes
C:\temp\PP3E\Examples\PP3E\Internet\Email\mailtools\mailParser.py has mimetypes C:\temp\PP3E\Examples\PP3E\Internet\Email\mailtools\mailSender.py has mimetypes C:\temp\PP3E\Examples\PP3E\Internet\Ftp\mirror\downloadflat.py has mimetypes C:\temp\PP3E\Examples\PP3E\Internet\Ftp\mirror\downloadflat_modular.py has mimetypes
C:\temp\PP3E\Examples\PP3E\Internet\Ftp\mirror\ftptools.py has mimetypes C:\temp\PP3E\Examples\PP3E\Internet\Ftp\mirror\uploadflat.py has mimetypes C:\temp\PP3E\Examples\PP3E\System\Media\playfile.py has mimetypes Found in 8 files, visited 1429
Технически при передаче сценарию числа 3 в первом аргументе он выполнит оба объекта, FileVisitor и SearchVisitor (осуществив два отдельных обхода). Первый аргумент в действительности используется в качестве битовой маски для выбора одной или более поддерживаемых самопроверок - если бит для какого-либо теста установлен в двоичном значении аргумента, этот тест будет выполнен. Поскольку 3 представляется в двоичном виде, как 011, выбираются одновременно поиск (010) и вывод списка (001). В более дружественной системе можно было бы определить символические параметры (например, искать аргументы -search и -list), но для целей данного сценария достаточно битовых масок.
Как обычно, этот модуль можно также использовать в интерактивном сеансе. Ниже приводится один из способов определения количества файлов и каталогов внутри определенного каталога. Последняя команда выполняет обход всего жесткого диска (и выводит результаты после заметной задержки!). Смотрите также пример «Найди самый большой файл Python» в начале этой главы, где описываются такие проблемы, как повторное посещение подкаталогов, не обрабатываемые данной реализацией:
C:\...\PP4E\Tools> python
>>> from visitor import FileVisitor
>>> V = FileVisitor(trace=0)
>>> V.run(r’C:\temp\PP3E\Examples’)
>>> V.dcount, V.fcount (186, 1429)
>>> V.run('..’) # независимый обход (сброс счетчиков)
>>> V.dcount, V.fcount
(19, 181)
>>> V.run('..’, reset=False) # накопительный обход (счетчики сохраняются)
>>> V.dcount, V.fcount
(38, 362) >>> V = FileVisitor(trace=0) # новый независимый обходчик (свои счетчики)
>>> V.run(r’C:\\’) # весь диск: в Unix попробуйте ‘/’
>>> V.dcount, V.fcount
(24992, 198585)
Модуль visitor удобно использовать как самостоятельный сценарий, чтобы получить список файлов и выполнить поиск в дереве каталогов, но в действительности он создавался, чтобы служить основой для расширения. В оставшейся части этого раздела мы коротко познакомимся с некоторыми клиентами этого модуля, которые добавляют свои операции с деревьями каталогов, используя приемы ООП.
Редактирование файлов в деревьях каталогов (Visitor)
Теперь, после обобщения обхода деревьев и поиска, легко сделать следующий шаг и добавить отдельный, совершенно новый компонент автоматического редактирования файлов. В примере 6.19 приводится определение нового класса EditVisitor, который просто переопределяет метод visitmatch класса SearchVisitor, новая версия которого открывает найденный файл в текстовом редакторе. Да, это законченная программа - что-либо особое нужно делать только при обработке найденных файлов, и только это поведение должно обеспечиваться. Все остальное, касающееся логики обхода и поиска, остается неизменным и приобретается по наследству.
Пример 6.19. PP4E\Tools\visitor_edit.py
Порядок использования: “python ...\Tools\visitor_edit.py string rootdir?”. Добавляет подкласс класса SearchVisitor, который автоматически запускает текстовый редактор. В процессе обхода автоматически открывает в текстовом редакторе файлы, содержащие искомую строку; в Windows можно также использовать editor=’edit’ или ‘notepad’; чтобы воспользоваться текстовым редактором, реализация которого будет представлена далее в книге, попробуйте r’python Gui\ TextEditor\textEditor.py’; при работе с некоторыми редакторами можно было бы передать команду перехода к первому совпадению с искомой строкой;
import os, sys
from visitor import SearchVisitor
class EditVisitor(SearchVisitor):
открывает для редактирования файлы, содержащие искомую строку и находящиеся в каталоге startDir и ниже
editor = r’C:\cygwin\bin\vim-nox.exe’ # у вас может быть другой редактор!
def visitmatch(self, fpathname, text):
os.system(‘%s %s’ % (self.editor, fpathname))
if __name__ == ‘__main__’:
visitor = EditVisitor(sys.argv[1])
visitor.run(‘.’ if len(sys.argv) < 3 else sys.argv[2])
print(‘Edited %d files, visited %d’ % (visitor.scount, visitor.fcount))
При использовании объекта EditVisitor текстовый редактор запускается посредством передачи командной строки функции os.system, которая обычно блокирует вызывающий программный код до момента, когда завершится порожденная программа. На моих машинах при каждом обнаружении сценарием совпадения во время обхода запускается текстовый редактор vi в том окне консоли, где был запущен сценарий. При выходе из редактора обход дерева возобновляется.
Найдем и отредактируем несколько файлов. При запуске этого файла как самостоятельного сценария мы передаем ему искомую строку в аргументе командной строки (здесь используется строка «mimetypes»). Корневой каталог всегда передается методу run как «.» (текущий рабочий каталог). Сообщения о состоянии обхода выводятся на консоль, но каждый файл, в котором обнаружено совпадение с искомой строкой, тут же автоматически открывается в текстовом редакторе. В данном случае редактор запускается восемь раз - попробуйте запустить этот сценарий в своем дереве каталогов и со своим редактором, чтобы лучше почувствовать, как он работает:
C:\...\PP4E\Tools> visitor_edit.py mimetypes C:\temp\PP3E\Examples
C:\temp\PP3E\Examples ...
1 => C:\temp\PP3E\Examples\README-root.txt
C:\temp\PP3E\Examples\PP3E ...
2 => C:\temp\PP3E\Examples\PP3E\echoEnvironment.pyw
3 => C:\temp\PP3E\Examples\PP3E\LaunchBrowser.pyw
4 => C:\temp\PP3E\Examples\PP3E\Launcher.py
5 => C:\temp\PP3E\Examples\PP3E\Launcher.pyc
Skipping C:\temp\PP3E\Examples\PP3E\Launcher.pyc
...множество строк опущено...
1427 => C:\temp\PP3E\Examples\PP3E\TempParts\lawnlake1-jan-03.jpg
Skipping C:\temp\PP3E\Examples\PP3E\TempParts\lawnlake1-jan-03.jpg
1428 => C:\temp\PP3E\Examples\PP3E\TempParts\part-001.txt
1429 => C:\temp\PP3E\Examples\PP3E\TempParts\part-002.html
Edited 8 files, visited 1429
В итоге получился именно тот инструмент, который мне был нужен, чтобы упростить сопровождение дерева примеров книги. После значительных изменений, например задания имен совместно используемых модулей или файлов и каталогов, я запускаю этот сценарий в корневом каталоге дерева примеров с соответствующей строкой поиска и нужным образом редактирую все открывающиеся файлы. Мне все еще приходится вручную изменять файлы в редакторе, но это зачастую безопаснее, чем вслепую выполнять глобальную замену.
Глобальная замена в деревьях каталогов (Visitor)
Но раз уж я затронул этот вопрос, то, имея общий класс для обхода дерева, легко написать и подкласс для глобального поиска и замены. В примере 6.20 приводится определение класса ReplaceVisitor, наследующего класс FileVisitor, который переопределяет метод visitfile так, чтобы глобально заменять все вхождения одной строки другой строкой во всех текстовых файлах, находящихся в корневом каталоге и ниже. Он также составляет список всех изменившихся файлов, чтобы их можно было просмотреть и проверить автоматически сделанные изменения (можно, например, автоматически вызывать текстовый редактор для каждого измененного файла).
Пример 6.20. PP4E\Tools\visitor_replace.py
Использование: “python ...\Tools\visitor_replace.py rootdir fromStr toStr”. Выполняет глобальный поиск с заменой во всех файлах в дереве каталогов: заменяет fromStr на toStr во всех текстовых файлах; это мощный, но опасный инструмент!! visitor_edit.py запускает редактор, чтобы дать возможность проверить и внести коррективы, и поэтому он более безопасный; чтобы просто получить список соответствующих файлов, используйте visitor_collect.py; режим простого вывода списка здесь напоминает SearchVisitor и CollectVisitor;
import sys
from visitor import SearchVisitor
class ReplaceVisitor(SearchVisitor):
Заменяет fromStr на toStr в файлах в каталоге startDir и ниже; имена изменившихся файлов сохраняются в списке obj.changed
def__init__(self, fromStr, toStr, listOnly=False, trace=0):
self.changed = []
self.toStr = toStr
self.listOnly = listOnly
SearchVisitor.__init__(self, fromStr, trace)
def visitmatch(self, fname, text): self.changed.append(fname) if not self.listOnly:
fromStr, toStr = self.context, self.toStr text = text.replace(fromStr, toStr) open(fname, ‘w’).write(text)
if __name__ == ‘__main__’:
listonly = input(‘List only?’) == ‘y’
visitor = ReplaceVisitor(sys.argv[2], sys.argv[3], listonly) if listonly or input(‘Proceed with changes?’) == ‘y’: visitor.run(startDir=sys.argv[1])
action = ‘Changed’ if not listonly else ‘Found’ print(‘Visited %d files’ % visitor.fcount) print(action, ‘%d files:’ % len(visitor.changed)) for fname in visitor.changed: print(fname)
Чтобы применить этот сценарий к определенному дереву каталогов, выполните команду, как показано ниже, указав соответствующую искомую строку и строку замены. На моем, жутко нерасторопном нетбуке, обработка дерева с 1429 файлами, из которых 101 потребовалось изменить, заняла примерно три секунды реального времени, когда система была не слишком занята другими задачами:
C:\...\PP4E\Tools> visitor_replace.py C:\temp\PP3E\Examples PP3E PP4E
List only?y Visited 1429 files Found 101 files:
C:\temp\PP3E\Examples\README-root.txt
C:\temp\PP3E\Examples\PP3E\echoEnvironment.pyw
C:\temp\PP3E\Examples\PP3E\Launcher.py
...большое количество имен файлов, соответствующих критерию поиска, опущено...
C:\...\PP4E\Tools> visitor_replace.py C:\temp\PP3E\Examples PP3E PP4E
List only?n
Proceed with changes?y Visited 1429 files Changed 101 files:
C:\temp\PP3E\Examples\README-root.txt
C:\temp\PP3E\Examples\PP3E\echoEnvironment.pyw
C:\temp\PP3E\Examples\PP3E\Launcher.py
...большое количество имен изменившихся файлов опущено...
C:\...\PP4E\Tools> visitor_replace.py C:\temp\PP3E\Examples PP3E PP4E
List only?n
Proceed with changes?y Visited 1429 files Changed 0 files:
Естественно, проверить работу этого сценария можно с помощью сценария visitor (и суперкласса SearchVisitor):
C:\...\PP4E\Tools> visitor.py 2 C:\temp\PP3E\Examples PP3E
Found in 0 files, visited 1429
C:\...\PP4E\Tools> visitor.py 2 C:\temp\PP3E\Examples PP4E
C:\temp\PP3E\Examples\README-root.txt has PP4E C:\temp\PP3E\Examples\PP3E\echoEnvironment.pyw has PP4E C:\temp\PP3E\Examples\PP3E\Launcher.py has PP4E
...большое количество имен файлов, соответствующих критерию поиска, опущено...
Found in 101 files, visited 1429
Это одновременно очень мощный и опасный сценарий. Если заменяемая строка может обнаружиться в неожиданных местах, запуск определенного здесь объекта ReplaceVisitor может разрушить все дерево файлов. С другой стороны, если строка является чем-то очень специфическим, этот объект поможет избежать необходимости вручную редактировать подозрительные файлы. Например, адреса веб-сайтов в файлах HTML достаточно специфичны, чтобы случайно появиться в других местах.
Подсчет строк исходного программного кода (Visitor)
Два приведенных выше примера использования модуля visitor были ориентированы на выполнение поиска, однако базовый класс, реализующий обход дерева каталогов, легко можно было бы расширить для реализации более специфических задач. Так, в примере 6.21 приводится сценарий, расширяющий класс FileVisitor возможностью подсчета количества строк в файлах с исходными текстами программ во всем дереве каталогов. Принцип его действия основан на вызове метода vis-itfile этого класса для каждого файла, найденного инструментом поиска, написанным нами выше в этой главе, но применение ООП обеспечивает более высокую гибкость и расширяемость.
Пример 6.21. PP4E\Tools\visitor_sloc.py
Подсчитывает строки во всех файлах с исходными текстами программ в дереве каталогов, указанном в командной строке, и выводит сводную информацию, сгруппированную по типам файлов (по расширениям). Реализует простейший алгоритм SLOC (source lines of code - строки исходного текста): если необходимо, добавьте пропуск пустых строк и комментариев.
import sys, pprint, os
from visitor import FileVisitor
class LinesByType(FileVisitor):
srcExts = [] # define in subclass
def __init__(self, trace=1):
FileVisitor.__init__(self, trace=trace)
self.srcLines = self.srcFiles = 0
self.extSums = {ext: dict(files=0, lines=0) for ext in self.srcExts}
def visitsource(self, fpath, ext):
if self.trace > 0: print(os.path.basename(fpath)) lines = len(open(fpath, ‘rb’).readlines()) self.srcFiles += 1 self.srcLines += lines self.extSums[ext][‘files’] += 1 self.extSums[ext][‘lines’] += lines
def visitfile(self, filepath):
FileVisitor.visitfile(self, filepath) for ext in self.srcExts:
if filepath.endswith(ext):
self.visitsource(filepath, ext) break
class PyLines(LinesByType):
srcExts = [‘.py’, ‘.pyw’] # just python files
class SourceLines(LinesByType):
srcExts = [‘.py’, ‘.pyw’, ‘.cgi’, ‘.html’, ‘.c’, ‘.cxx’, ‘.h’, ‘.i’]
if __name__ == ‘__main__’: walker = SourceLines() walker.run(sys.argv[1])
print(‘Visited %d files and %d dirs’ % (walker.fcount, walker.dcount)) print(‘-’*80)
print(‘Source files=>%d, lines=>%d’ % (walker.srcFiles, walker.srcLines)) print(‘By Types:’) pprint.pprint(walker.extSums) print(‘\nCheck sums:’, end=’ ‘)
print(sum(x[‘lines’] for x in walker.extSums.values()), end=’ ‘)
print(sum(x[‘files’] for x in walker.extSums.values()))
print(‘\nPython only walk:’)
walker = PyLines(trace=0)
walker.run(sys.argv[1])
pprint.pprint(walker.extSums)
Если запустить его как самостоятельный сценарий, в процессе обхода будут выводиться трассировочные сообщения (опущены здесь для экономии места) и в конце будет представлен отчет о количестве строк, сгруппированный по типам файлов. Выполните этот сценарий в своем дереве каталогов, чтобы увидеть, как он действует. В моем дереве каталогов содержится 907 файлов с исходными текстами, насчитывающих 48 000 строк, включая 783 файла (.py) и 34 000 строк с исходными текстами на языке Python:
C:\...\PP4E\Tools> visitor_sloc.py C:\temp\PP3E\Examples
Visited 1429 files and 186 dirs
Source files=>907, lines=>48047 By Types:
{‘.c’: {‘files’: 45, ‘lines’: 7370},
‘.cgi’: {‘files’: 5, ‘lines’: 122},
‘.cxx’: {‘files’: 4, ‘lines’: 2278},
‘.h’: {‘files’: 7, ‘lines’: 297},
‘.html’: {‘files’: 48, ‘lines’: 2830},
‘.i’: {‘files’: 4, ‘lines’: 49}, ‘.py’: {‘files’: 783, ‘lines’: 34601 },
‘.pyw’: {‘files’: 11, ‘lines’: 500}}
Check sums: 48047 907
Python only walk:
{‘.py’: {‘files’: 783, ‘lines’: 34601 }, ‘.pyw’: {‘files’: 11, ‘lines’: 500}}
Копирование деревьев каталогов с помощью классов (Visitor)
Рассмотрим еще один случай использования классов-обходчиков. Когда я впервые написал сценарий cpall.py ранее в этой главе, я не понимал, как можно применить иерархию классов-обходчиков, с которой мы встретились выше, для копирования деревьев каталогов. При копировании необходимо выполнять обход сразу двух деревьев каталогов (оригинального и его копии), а visitor выполняет обход только одного дерева, используя функцию os.walk. Тогда мне казалось, что будет совсем не просто следить за тем, где находится сценарий в копии дерева.
Хитрость, до которой я в конце концов додумался, заключается в том, что следить за позицией в дереве копии вообще не требуется. Вместо этого сценарий в примере 6.22 просто замещает строку пути к каталогу «из» строкой пути к каталогу «в» и добавляет ее перед всеми именами каталогов, полученными от функции os.walk. В результате такой подмены получаются пути, куда должны быть скопированы оригинальные файлы и каталоги.
Пример 6.22. PP4E\Tools\visitor_cpall.py
Использование: “python ...\Tools\visitor_cpall.py fromDir toDir trace?”
Действует подобно сценарию System\Filetools\cpall.py, но использует классы-обходчики и функцию os.walk; заменяет строку fromDir на toDir перед всеми именами, возвращаемыми обходчиком; предполагается, что изначально каталог toDir не существует;
import os
from visitor import FileVisitor # обходчик в каталоге ‘.’
from PP4E.System.Filetools.cpall import copyfile # PP4E - в пути поиска
class CpallVisitor(FileVisitor):
def__init__(self, fromDir, toDir, trace=True):
self.fromDirLen = len(fromDir) + 1 self.toDir = toDir
FileVisitor.__init__(self, trace=trace)
def visitdir(self, dirpath):
toPath = os.path.join(self.toDir, dirpath[self.fromDirLen:])
if self.trace: print(‘d’, dirpath, ‘=>’, toPath)
os.mkdir(toPath)
self.dcount += 1
def visitfile(self, filepath):
toPath = os.path.join(self.toDir, filepath[self.fromDirLen:]) if self.trace: print(‘f’, filepath, ‘=>’, toPath) copyfile(filepath, toPath) self.fcount += 1
if __name__ == ‘__main__’: import sys, time fromDir, toDir = sys.argv[1:3] trace = len(sys.argv) > 3 print(‘Copying...’) start = time.clock()
walker = CpallVisitor(fromDir, toDir, trace) walker.run(startDir=fromDir)
print(‘Copied’, walker.fcount, ‘files,’, walker.dcount, ‘directories’, end=’ ‘)
print(‘in’, time.clock() - start, ‘seconds’)
Эта версия достигает почти той же цели, что и оригинал, но в ней сделано несколько допущений, чтобы упростить реализацию. Предполагается, что каталог «в» изначально не существует, а исключения, возникающие в процессе копирования, не игнорируются. Следующий пример демонстрирует копирование дерева примеров для предыдущего издания книги в Windows:
C:\...\PP4E\Tools> set PYTHONPATH
PYTHONPATH=C:\Users\Mark\Stuff\Books\4E\PP4E\dev\Examples
C:\...\PP4E\Tools> rmdir /S copytemp
copytemp, Are you sure (Y/N)? y
C:\...\PP4E\Tools> visitor_cpall.py C:\temp\PP3E\Examples copytemp
Copying...
Copied 1429 files, 186 directories in 11.1722033777 seconds
C:\...\PP4E\Tools> fc /B copytemp\PP3E\Launcher.py
C:\temp\PP3E\Examples\PP3E\Launcher.py
Comparing files COPYTEMP\PP3E\Launcher.py and C:\TEMP\PP3E\EXAMPLES\PP3E\ LAUNCHER.PY
FC: no differences encountered
Несмотря на то, что в этой версии выполняется дополнительная операция извлечения среза из строки, она действует так же быстро, как и оригинал (фактическое отличие можно списать на разницу в нагрузке на систему). Кроме того, эта версия позволяет проследить за всеми путями «из» и «в» в процессе обхода, если передать ей третий аргумент командной строки:
C:\...\PP4E\Tools> rmdir /S copytemp
copytemp, Are you sure (Y/N)? y
C:\...\PP4E\Tools> visitor_cpall.py C:\temp\PP3E\Examples copytemp 1
Copying...
d C:\temp\PP3E\Examples => copytemp\
f C:\temp\PP3E\Examples\README-root.txt => copytemp\README-root.txt d C:\temp\PP3E\Examples\PP3E => copytemp\PP3E
...множество строк опущено: запустите этот сценарий у себя, чтобы увидеть вывод целиком...
Другие примеры обходчиков (внешние)
Инструменту обхода деревьев на основе классов можно найти самые разные применения, однако у нас недостаточно места в книге, чтобы исследовать дополнительные подклассы. Дополнительные примеры реализации клиентов и их использования вы найдете в следующих примерах, входящих в состав пакета, описанного в Предисловии:
• Tools\visitor_collect.py отбирает и/или выводит имена файлов, содержащие искомую строку
• Tools\visitor_poundbang.py замещает пути к каталогам в строках «#!», находящихся в начале файлов сценариев в Unix
• Tools\visitor_cleanpyc.py - переработанная версия сценария удаления файлов с байт-кодом, использующая классы-обходчики
• Tools\visitor_bigpy.py - версия примера «Найди самый большой файл Python», приводившегося в начале главы, использующая классы-обходчики
Реализация большинства из них выглядит почти тривиально, как и реализация visitor_edit.py в примере 6.19, благодаря тому что все детали обхода деревьев каталогов автоматически скрываются за интерфейсом классов-обходчиков. Реализация отбора файлов, например, просто добавляет в список имена файлов, соответствующих критериям поиска, и позволяет переопределить список допустимых расширений имен файлов в каждом экземпляре - она напоминает комбинацию команд find и grep в Unix:
>>> from visitor_collect import CollectVisitor
>>> V = CollectVisitor('mimetypes', testexts=['.py', ‘.pyw’], trace=0)
>>> V.run(r'C:\temp\PP3E\Examples')
>>> for name in V.matches: print(name) # файлы .py и .pyw со строкой
... # ‘mimetypes’
C:\temp\PP3E\Examples\PP3E\Internet\Email\mailtools\mailParser.py
C:\temp\PP3E\Examples\PP3E\Internet\Email\mailtools\mailSender.py
C:\temp\PP3E\Examples\PP3E\Internet\Ftp\mirror\downloadflat.py
C:\temp\PP3E\Examples\PP3E\Internet\Ftp\mirror\downloadflat_modular.py
C:\temp\PP3E\Examples\PP3E\Internet\Ftp\mirror\ftptools.py
C:\temp\PP3E\Examples\PP3E\Internet\Ftp\mirror\uploadflat.py
C:\temp\PP3E\Examples\PP3E\System\Media\playfile.py
C:\...\PP4E\Tools> visitor_collect.py mimetypes C:\temp\PP3E\Examples # как
# сценарий
Основная логика сценария поиска наибольшего файла также выглядит достаточно просто и напоминает логику сценария в начале главы:
class BigPy(FileVisitor):
def __init__(self, trace=0):
FileVisitor.__init__(self, context=[], trace=trace)
def visitfile(self, filepath):
FileVisitor.visitfile(self, filepath) if filepath.endswith(‘.py’):
self.context.append((os.path.getsize(filepath), filepath))
Пример реализации удаления файлов байт-кода на основе классов-обходчиков также возвращает нас назад, демонстрируя альтернативное решение задачи, с которой мы уже сталкивались выше в этой главе. Это, по сути, тот же самый программный код, но он вызывает функцию os.remove при обнаружении файлов с расширением «.pyc».
Наконец, хотя классы-обходчики действительно являются всего лишь обертками вокруг функции os.walk, тем не менее они автоматизируют рутинные операции, выполняемые при обходе, и обеспечивают универсальный фундамент и альтернативную структуру на основе классов, которая может оказаться более естественной для некоторых решений, чем неструктурированные циклы. Кроме того, они наглядно демонстрируют, насколько хорошо поддержка ООП в языке Python позволяет отображать реальные структуры, такие как файловые системы. Приемы на основе функции os.walk хорошо подходят для одноразовых сценариев, тогда как лучшая расширяемость, уменьшенная избыточность и сокрытие, свойственные приемам ООП, могут быть основным вкладом в разработку действующих программ, которые могут развиваться в течение долгого времени с учетом наших потребностей.
Эти потребности действительно изменились с течением времени. Между третьим и четвертым изданиями этой книги из Python 3.X была исключена оригинальная функция os.path. walk, и функция os.walk стала единственным инструментом автоматизированного обхода деревьев в стандартной библиотеке. Это привело к тому, что примеры из предыдущего издания, использовавшие os.path.walk, оказались неработоспособными. Тогда как клиенты, реализованные на основе классов-обходчиков, использующих ту же функцию, не пострадали. Поскольку перевод классов-обходчиков на использование функции os.walk не отразился на их интерфейсе, инструменты, использующие их, сохранили работоспособность без переделки.
Это, пожалуй, один из самых ярких примеров преимуществ инкапсуляции в ООП. Будущее нельзя предсказать с достаточной степенью надежности, тем не менее на практике инструменты, определяемые пользователем, такие как классы-обходчики, обычно обеспечивают более полный контроль над изменениями в инструментах стандартной библиотеки, таких как os.walk. Можете поверить мне на слово - как человек, который обновлял три книги о языке Python на протяжении последних 15 лет, я могу с определенной долей уверенности сказать, что Python будет изменяться постоянно!
Проигрывание медиафайлов
В этой главе у нас еще осталось немного места, поэтому закроем ее небольшим развлекательным примером. Обратили ли вы внимание, что в сценариях поиска в двух предыдущих разделах мы жестко определяли расширения имен текстовых и двоичных файлов? Такой подход вполне оправдан для деревьев каталогов, к которым мы применяли их, но в общем случае его нельзя назвать законченным или переносимым. Было бы лучше, если бы мы могли автоматически определять тип файла по его имени. Такую возможность предоставляет модуль mimetypes. В этом разделе мы будем использовать его при создании сценария, который будет пытаться запускать файлы, опираясь на их типы, и по ходу дела разработаем универсальные инструменты для открытия медиафайлов переносимым способом, с использованием специализированных или универсальных программ-проигрывателей.
Как мы уже видели, в Windows эта задача решается тривиально просто - функция os.startfile открывает файл, используя реестр Windows, где хранятся соответствия между расширениями имен файлов и программами для работы с ними. На других платформах можно либо запускать определенные программы-проигрыватели для каждого типа файлов, либо возвращаться к использованию веб-броузера по умолчанию, открывая файлы с помощью модуля webbrowser. Воплощение этих идей в программный код приводится в примере 6.23.
Пример 6.23. PP4E\System\Media\playfile.py
#!/usr/local/bin/python
############################################################################## Пытается проигрывать медиафайлы различных типов. Позволяет определять специализированные программы-проигрыватели вместо использования универсального приема открытия файла в веб-броузере. В текущем своем виде может не работать в вашей системе; для открытия аудиофайлов в Unix используются фильтры и команды, в Windows используется команда start, учитывающая ассоциации с расширениями имен файлов (то есть для открытия файлов .au, например, она может запустить проигрыватель аудиофайлов или веб-броузер). Настраивайте и расширяйте сценарий под свои потребности. Функция playknownfile предполагает, что вы знаете, какой тип медиафайла пытаетесь открыть, а функция playfile пробует определить тип файла автоматически, используя модуль mimetypes; обе они пробуют запустить вебброузер с помощью модуля webbrowser, если тип файла не удается определить. ##############################################################################
import os, sys, mimetypes, webbrowser helpmsg = “””
Sorry: can’t find a media player for ‘%s’ on your system!
Add an entry for your system to the media player dictionary for this type of file in playfile.py, or play the file manually.
def trace(*args): print(*args) # с разделяющими пробелами
##############################################################################
# приемы проигрывания: универсальный и другие: дополните своими приемами ##############################################################################
class MediaTool:
def __init__(self, runtext=’’):
self.runtext = runtext
def run(self, mediafile, **options): # options обычно игнорируется
fullpath = os.path.abspath(mediafile) # cwd может быть любым
self.open(fullpath, **options)
class Filter(MediaTool):
def open(self, mediafile, **ignored): media = open(mediafile, ‘rb’)
player = os.popen(self.runtext, ‘w’) # запустить команду оболочки
player.write(media.read()) # отправить файл в stdin
class Cmdline(MediaTool):
def open(self, mediafile, **ignored):
cmdline = self.runtext % mediafile # запустить команду os.system(cmdline) # использовать %s для имени файла
class Winstart(MediaTool): # использует реестр Windows
def open(self, mediafile, wait=False, **other): # позволяет дождаться
if not wait: # окончания проигрывания файла
os.startfile(mediafile) # или os.system(‘start file’)
else:
os.system(‘start /WAIT ‘ + mediafile)
class Webbrowser(MediaTool):
# file:// требует указывать абсолютный путь def open(self, mediafile, **options):
webbrowser.open_new(‘file://%s’ % mediafile, **options)
##############################################################################
# медиа- и платформозависимые методы: измените или укажите один из имеющихся ##############################################################################
# соответствия платформ и проигрывателей: измените! audiotools = {
‘sunos5’: Filter(‘/usr/bin/audioplay’), # os.popen().write()
‘linux2’: Cmdline(‘cat %s > /dev/audio’), # по крайней мере в PDA Zaurus ‘sunos4’: Filter(‘/usr/demo/SOUND/play’), # да, даже такая древность! ‘win32’: Winstart() # startfile или system
#’win32’: Cmdline(‘start %s’)
}
videotools = {
‘linux2’: Cmdline(‘tkcVideo_c700 %s’), # PDA Zaurus
‘win32’: Winstart(), # предотвратить вывод окна DOS
}
imagetools = {
‘linux2’: Cmdline(‘zimager %s’), # PDA Zaurus
‘win32’: Winstart(),
}
texttools = {
‘linux2’: Cmdline(‘vi %s’), # PDA Zaurus
‘win32’: Cmdline(‘notepad %s’) # или попробовать PyEdit?
}
apptools = {
‘win32’: Winstart() # doc, xls, и др.: используйте
# на свой страх и риск!
}
# таблица соответствия между типами файлов и программами-проигрывателями
mimetable = {‘audio’: audiotools,
‘video’: videotools,
‘image’: imagetools,
‘text’: texttools, # не-html текст: броузер
‘application’: apptools}
##############################################################################
# интерфейсы высокого уровня
############################################################################## def trywebbrowser(filename, helpmsg=helpmsg, **options): пытается открыть файл в веб-броузере
как последнее средство, если тип файла или платформы неизвестен, а также для файлов типа text/html
trace(‘trying browser’, filename) try:
player = Webbrowser() # открыть в броузере
player.run(filename, **options) except:
print(helpmsg % filename) # никакой из способов не работает
def playknownfile(filename, playertable={}, **options):
проигрывает медиафайл известного типа: использует программы-проигрыватели для данной платформы или запускает веб-броузер, если для этой платформы не определено ничего другого; принимает таблицу соответствий расширений и программ-проигрывателей
if sys.platform in playertable: # известный
playertable[sys.platform].run(filename, **options) # инструмент
else: # универсальный
trywebbrowser(filename, **options) # прием
def playfile(filename, mimetable=mimetable, **options):
проигрывает медиафайл любого типа: использует модуль mimetypes для определения типа медиафайла и таблицу соответствий между расширениями и программами-проигрывателями; запускает веб-броузер для файлов с типом text/html, с неизвестным типом и при отсутствии таблицы соответствий
contenttype, encoding = mimetypes.guess_type(filename) # проверить имя if contenttype == None or encoding is not None: # не определяется
contenttype = ‘?/?’ # возм. .txt.gz
maintype, subtype = contenttype.split(‘/’, 1) # ‘image/jpeg’
if maintype == ‘text’ and subtype == ‘html’:
trywebbrowser(filename, **options) # спец. случай
elif maintype in mimetable:
playknownfile(filename, mimetable[maintype], **options) # по таблице else:
trywebbrowser(filename, **options) # другие типы
##############################################################################
# программный код самопроверки
##############################################################################
if __name__ == ‘__main__’:
# тип медиафайла известен
playknownfile(‘sousa.au’, audiotools, wait=True) playknownfile(‘ora-pp3e.gif’, imagetools, wait=True) playknownfile(‘ora-lp4e.jpg’, imagetools)
# тип медиафайла определяется
input(‘Stop players and press Enter’) playfile\ora-lp4e.jpg’) # image/jpeg
playfile\ora-pp3e.gif’) # image/gif
playfile(‘priorcalendar.html’) # text/html
playfile(‘lp4e-preface-preview.html’) # text/html
playfile\lp-code-readme.txt’) # text/plain
playfile(‘spam.doc’) # app
playfile(‘spreadsheet.xls’) # app
playfile(‘sousa.au’, wait=True) # audio/basic
input(‘Done’) # приостановиться, если
# сценарий запущен щелчком мыши
В наши дни медиафайлы большинства типов можно открыть с помощью веб-броузера, тем не менее этот модуль представляет собой простую основу для программ, открывающих медиафайлы с помощью более специализированных инструментов, предназначенных для обработки медиафайлов данного типа на данной платформе. Веб-броузер используется только в крайнем случае, при отсутствии других возможностей. В результате получился расширяемый сценарий проигрывания медиафайлов, специализированность и переносимость которого зависит от настроек в его таблицах соответствий.
Инструменты запуска программ, используемые этим сценарием, мы видели в предыдущих главах. Основным новшеством в этом сценарии является использование новых модулей: модуль webbrowser используется для открытия некоторых файлов в локальном веб-броузере, а модуль mimetypes применяется для определения типов медиафайлов по их именам. Поскольку они являются основой этого сценария, коротко познакомимся с ними, прежде чем запускать сценарий.
Модуль webbrowser
Модуль webbrowser, входящий в состав стандартной библиотеки и используемый в этом примере, предоставляет переносимый интерфейс для запуска веб-броузера из сценариев на языке Python. Он пытается отыскать подходящий веб-броузер на локальном компьютере, чтобы открыть указанный адрес URL (полное имя файла или веб-адрес). Интерфейс модуля достаточно прост:
>>> import webbrowser
>>> webbrowser.open_new(‘file://’ + fullfilename) # используйте
# os.path.abspath()
Этот программный код откроет указанный файл в новом окне броузера, который удастся обнаружить на локальном компьютере, или возбудит исключение. Имеется возможность явно перечислить броузеры, имеющиеся в системе, и определить порядок, в каком они будут использоваться, с помощью переменной окружения BROWSER и функции register. По умолчанию модуль webbrowser автоматически пытается обеспечить переносимость между платформами.
Чтобы открыть файл, находящийся на локальном компьютере или на веб-сервере, строка аргумента должна иметь вид «file://...» или «http://...» соответственно. Фактически можно передать строку URL любого вида, которую воспринимает броузер. Например, следующая инструкция откроет домашнюю страницу проекта Python в новом окне броузера:
>>> webbrowser.open_new(‘http://www.python.org’)
Кроме всего прочего, этот модуль обеспечивает простой способ отображения документов HTML, а также медиафайлов, как демонстрируется в примере из этого раздела. К тому же этот модуль может использоваться и как самостоятельный сценарий командной строки (здесь вам поможет ключ -m командной строки интерпретатора, включающий путь поиска модулей), и как импортируемый инструмент:
C:\Users\mark\Stuff\Websites\public_html> python -m webbrowser about-pp.html C:\Users\mark\Stuff\Websites\public_html> python -m webbrowser -n about-pp.html C:\Users\mark\Stuff\Websites\public_html> python -m webbrowser -t about-pp.html
C:\Users\mark\Stuff\Websites\public_html> python >>> import webbrowser
>>> webbrowser.open('about-pp.html') # повторное использование,
True # новое окно, новая вкладка
>>> webbrowser.open_newCabout-pp.html') # file:// не обязательно в Windows
True
>>> webbrowser.open_new_tabCabout-pp.html')
True
В обоих режимах применения различия между тремя формами заключаются в том, что в первом случае предпринимается попытка повторно использовать уже открытое окно броузера, если это возможно, во втором - выполняется попытка открыть новое окно, и в третьем - выполняется попытка открыть новую вкладку. Однако на практике поведение всех трех форм зависит от типа веб-броузера и в целом от типа платформы. Все три формы могут вести себя совершенно одинаково.
В Windows, например, все три просто вызывают функцию os.startfile по умолчанию, в результате чего создается новая вкладка в уже открытом окне Internet Explorer 8. Это объясняет, почему я не указывал полный префикс «file://» URL в предыдущем фрагменте. Формально, броузер Internet Explorer запускается, только если он зарегистрирован как инструмент открытия файлов указанного типа, в противном случае запускается специализированный инструмент для работы с такими файлами. Некоторые изображения, например, могут открываться в специализированных программах просмотра фотографий. На других платформах, таких как Unix и Mac OS X, поведение броузера отличается, и файлы, имена которых не являются полноценным адресом URL, могут не открываться, поэтому для переносимости используйте префикс «file://».
Мы еще вернемся к этому модулю далее в книге. Например, программа PyMailGUI в главе 14 будет использовать его как инструмент отображения сообщений электронной почты и вложений в формате HTML, а также отображения справки к программе. За дополнительной информацией обращайтесь к руководству по библиотеке Python. В главах 13 и 15 мы также встретим родственную функцию urllib.request.urlopen, которая извлекает текст веб-страницы, находящейся по указанному адресу URL, но не открывает его в броузере - этот текст можно проанализировать, сохранить и использовать как-то иначе.
Модуль mimetypes
Чтобы сделать этот модуль проигрывателя медиафайлов еще более удобным, мы использовали в нем модуль mimetypes, входящий в состав стандартной библиотеки Python, который автоматически определяет тип медиафайла по его имени. Если тип может быть определен, модуль возвращает строку типа содержимого вида type/subtype, или None - если тип не определяется:
>>> import mimetypes
>>> mimetypes.guess_type('spam.jpg')
(‘image/jpeg’, None)
>>> mimetypes.guess_type(‘TheBrightSideOfLife.mp3’)
(‘audio/mpeg’, None)
>>> mimetypes.guess_type('lifeofbrian.mpg')
(‘video/mpeg’, None)
>>> mimetypes.guess_type('lifeofbrian.xyz') # неизвестный тип (None, None)
Выделив первую часть строки типа содержимого, можно получить обобщенный тип медиафайла, который можно использовать для выбора универсальной программы-проигрывателя. Вторая часть (подтип) сообщает, например, является текст разметкой HTML или простым текстом:
>>> contype, encoding = mimetypes.guess_type('spam.jpg')
>>> contype.split('/')[0]
‘image’
>>> mimetypes.guess_type('spam.txt') # подтип ‘plain’
(‘text/plain’, None)
>>> mimetypes.guess_type('spam.html')
(‘text/html’, None)
>>> mimetypes.guess_type('spam.html')[0].split('/')[1]
‘html’
Тут есть одна тонкость: второй элемент кортежа, возвращаемого функцией определения типа из модуля mimetypes, является названием кодировки, которое мы не используем здесь. Тем не менее мы не должны забывать про него - если данный элемент имеет значение, отличное от
None, это означает, что файл был сжат (с помощью gzip или compress), даже если в первом элементе кортежа возвращается тип медиафайла. Например, если файл имеет такое имя, как spam.gif.gz, будет считаться, что это сжатое изображение, которое не следует пытаться открывать непосредственно:
>>> mimetypes.guess_type('spam.gz') # тип содержимого неизвестен
(None, ‘gzip’)
>>> mimetypes.guess_type('spam.gif.gz') # не открывать напрямую!
(‘image/gif’, ‘gzip’)
>>> mimetypes.guess_type('spam.zip') # архивы
(‘application/zip’, None)
>>> mimetypes.guess_type('spam.doc') # файлы офисных приложений
(‘application/msword’, None)
Если имя файла, передаваемое функции, содержит путь к каталогу, то эта часть имени будет игнорироваться (при определении типа используется только расширение). Этот модуль позволяет даже определять расширение имени файла по заданному типу, что можно использовать при создании имен файлов по известному типу содержимого:
>>> mimetypes.guess_type(r'C:\songs\sousa.au')
(‘audio/basic’, None)
>>> mimetypes.guess_extension('audio/basic')
‘.au’
Поэкспериментируйте с другими функциями из этого модуля, чтобы получить более полное представление о нем. Мы еще раз вернемся к модулю mimetypes в примерах FTP в главе 13, где будем определять тип передаваемых данных (текст или двоичные), а также в примерах работы с электронной почтой в главах 13, 14 и 16, где реализуем отправку, сохранение и открытие вложений.
В примере 6.23 модуль mimetypes используется для организации выбора платформозависимых команд запуска программ-проигрывателей для данного типа медиафайлов. То есть модуль выбирает проигрыватель из таблицы по указанному типу медиафайла, а затем выбирает из таблицы проигрывателей команду для данной платформы. На любом из двух этапах мы отступаем назад и запускаем веб-броузер, если не было найдено чего-то более определенного.
Использование модуля mimetypes в классе SearchVisitor
Чтобы задействовать этот модуль для управления выбором текстовых файлов в сценариях поиска, написанных нами выше в этой главе, можно просто извлекать и анализировать первый элемент кортежа, возвращаемого для заданного имени файла. Например, все расширения в следующем списке считаются расширениями имен текстовых файлов (кроме расширения «.pyw», которое можно считать особым случаем):
>>> for ext in ['.txt', '.py', '.pyw', '.html', '.c', '.h', '.xml']:
... print(ext, mimetypes.guess_type('spam' + ext))
.txt (‘text/plain’, None)
.py (‘text/x-python’, None)
.pyw (None, None)
.html (‘text/html’, None)
.c (‘text/plain’, None)
.h (‘text/plain’, None)
.xml (‘text/xml’, None)
Мы можем добавить этот прием в предыдущую реализацию класса SearchVisitor, переопределив метод candidate и заменив список расширений имен файлов, используемый по умолчанию, анализом возвращаемого типа модулем mimetypes - еще одно яркое свидетельство гибкости ООП:
C:\...\PP4E\Tools> python >>> import mimetypes
>>> from visitor import SearchVisitor # или PP4E.Tools.visitor, если не .
>>>
>>> class SearchMimeVisitor(SearchVisitor):
... def candidate(self, fname):
... contype, encoding = mimetypes.guess_type(fname)
... return (contype and
... contype.split('/')[0] == 'text' and
... encoding == None)
>>> V = SearchMimeVisitor('mimetypes', trace=0) # ключ поиска >>> V.run(r'C:\temp\PP3E\Examples') # корневой каталог
C:\temp\PP3E\Examples\PP3E\extras\LosAlamosAdvancedClass\day1-system\data.txt has mimetypes
C:\temp\PP3E\Examples\PP3E\Internet\Email\mailtools\mailParser.py has mimetypes C:\temp\PP3E\Examples\PP3E\Internet\Email\mailtools\mailSender.py has mimetypes C:\temp\PP3E\Examples\PP3E\Internet\Ftp\mirror\downloadflat.py has mimetypes C:\temp\PP3E\Examples\PP3E\Internet\Ftp\mirror\downloadflat_modular.py has mimetypes
C:\temp\PP3E\Examples\PP3E\Internet\Ftp\mirror\ftptools.py has mimetypes C:\temp\PP3E\Examples\PP3E\Internet\Ftp\mirror\uploadflat.py has mimetypes C:\temp\PP3E\Examples\PP3E\System\Media\playfile.py has mimetypes >>> V.scount, V.fcount, V.dcount
(8, 1429, 186)
Однако этот прием не обеспечивает абсолютную точность (в случае необходимости придется добавить логику обслуживания таких расширений, как «.pyw», которые не определяются модулем mimetypes) и подходит далеко не для всех клиентов (в некоторых случаях может потребоваться искать только определенные типы текстовых файлов), поэтому данная схема не использовалась в оригинальном классе. Использование и настройку его для ваших собственных нужд мы оставим в качестве самостоятельного упражнения.
Запускаем сценарий
Если теперь запустить сценарий из примера 6.23 и все пойдет как надо, программный код самопроверки в конце сценария откроет множество аудиофайлов, изображений, текста и других файлов, находящихся в каталоге сценария, используя либо специализированные программы-проигрыватели для данной платформы, либо веб-броузер. На моем ноутбуке с Windows 7 файлы GIF и HTML открываются в новых вкладках броузера IE; файлы JPEG - в программе Windows Photo Viewer; простые текстовые файлы - в программе Notepad; файлы DOC и XLS -в Microsoft Word и Excel; а аудиофайлы - в Windows Media Player.
Однако, поскольку набор используемых программ и их поведение могут значительно отличаться для разных компьютеров, вам будет лучше самостоятельно изучить реализацию сценария и опробовать его на собственном компьютере со своими тестовыми файлами, чтобы своими глазами увидеть, что произойдет. Как обычно, тестирование можно выполнить и в интерактивной оболочке (используйте путь к пакету, как в следующем фрагменте, чтобы импортировать из другого каталога, при этом предполагается, что корневой каталог PP4E находится в пути поиска модулей):
>>> from PP4E.System.Media.playfile import playfile
>>> playfile(r'C:\movies\mov10428.mpg') # video/mpeg
Мы еще будем использовать модуль playfile в главе 13 для открытия медиафайлов, загруженных по FTP. И снова вам может потребоваться настроить таблицы в сценарии, определив в них ассоциации со своими программами-проигрывателями. Кроме того, этот сценарий предполагает, что медиафайл находится на локальном компьютере (даже при том, что модуль webbrowser поддерживает удаленные файлы с именами, начинающимися с «http://») и в настоящее время не позволяет использовать различные программы-проигрыватели для большинства различных подтипов MIME (текстовые файлы являются особым случаем, где подтипы «plain» и «html» обрабатываются по-разному, но это не относится к другим типам). Этот сценарий является своего рода основой, предназначенной для дальнейшего расширения. Как обычно, изучайте и осваивайте - в конце концов, это Python.
Автоматизированный запуск программ (внешние примеры)
Наконец, кое-что для дополнительного чтения - в пакете с примерами для этой книги (доступном на сайтах, перечисленных в Предисловии) вы найдете дополнительные системные сценарии, описать которые здесь мы не можем из-за нехватки места:
• PP4E\Launcher.py - содержит инструменты, используемые некоторыми программами с графическим интерфейсом, рассматриваемыми далее в этой книге, для запуска программ Python без необходимости выполнять настройку окружения. Грубо говоря, этот модуль выполняет настройку системного пути поиска файлов и пути поиска импортируемых модулей, необходимых для запуска примеров, которые наследуются порождаемыми программами. Используя этот модуль для поиска файлов и автоматической настройки окружения, пользователи могут избежать или, по крайней мере, отсрочить необходимость изучать особенности настройки окружения вручную перед запуском программ. В этом примере вы найдете не так много нового с точки зрения системных интерфейсов, однако мы еще будем ссылаться на него позднее, когда будем исследовать программы с графическим интерфейсом, использующие эти инструменты, а также родственные им инструменты запуска, о которых рассказывалось в главе 5.
• PP4E\Launch_PyDemos.pyw и PP4E\Launch_PyGadgets_bar.pyw -используют Launcher.py для запуска основных примеров книги без необходимости выполнять настройку окружения. Поскольку все порождаемые процессы наследуют настройки, выполненные модулем запуска, все они выполняются с соответствующими настройками путей поиска. При непосредственном запуске сценарии PyDemos2. pyw и PyGadgets_bar.pyw (которые мы будем исследовать в конце главы 10) будут использовать общесистемные настройки. Другими словами, сценарий Launcher эффективно скрывает особенности настройки от графических интерфейсов, заключая их в настроенную программную оболочку.
• PP4E\LaunchBrowser.pyw - переносимым образом отыскивает и запускает веб-броузер на локальном компьютере для просмотра содержимого локального файла или удаленной веб-страницы. Поиск броузера в предыдущей версии выполнялся с помощью инструментов из Launcher.py. Изначальная реализация этого модуля может быть в значительной степени заменена модулем webbrowser из стандартной библиотеки, который появился уже после того, как этот пример был создан (питоны думают одинаково!). В этом издании модуль Launch-Browser просто анализирует аргументы командной строки для обратной совместимости и вызывает функцию open из модуля webbrowser. Примеры его использования вы найдете в справочном тексте внутри модуля или в примерах PyGadgets и PyDemos в главе 10.
На этом мы заканчиваем исследование системных инструментов. В следующей части книги мы оставим царство командной строки и перейдем к исследованию способов создания графических интерфейсов для наших программ. Позднее мы проделаем то же самое, но уже с использованием веб-интерфейсов. Тем не менее не будем забывать, что системные инструменты, с которыми мы познакомились в этой части книги, находят применение в самых разных программах. Например, мы будем использовать потоки выполнения для выполнения длительных операций в части книги, посвященной графическим интерфейсам; потоки выполнения и процессы будут использоваться для реализации серверов в части книги, посвященной программированию для Интернета; и на протяжении всей книги будем применять файлы и системные вызовы, связанные с файлами.
Будь то сценарии командной строки, многооконные графические интерфейсы или распределенные веб-сайты, действующие по схеме кли-ент/сервер, системные инструменты Python всегда будут играть важную роль в вашей карьере программиста на Python.
Программирование графических интерфейсов
Эта часть книги демонстрирует, как применять Python для создания переносимых графических интерфейсов пользователя, в первую очередь, с помощью стандартной библиотеки Python tkinter. Следующие главы всесторонне освещают эту тему:
Глава 7
Эта глава очерчивает возможности создания графических интерфейсов, доступные в языке Python, а затем представляет учебный материал, иллюстрирующий базовые понятия программирования с использованием tkinter.
Глава 8
Эта глава начинает обзор двух частей библиотеки tkinter - набора графических элементов и сопутствующих инструментов. В первой части обзора рассказывается о наиболее простых инструментах и графических элементах библиотеки: всплывающих окнах, различных видах кнопок, изображениях и так далее.
Глава9
Здесь продолжается обзор библиотеки, начатый в предыдущей главе. В этой главе представляется остальная часть библиотеки графических элементов tkinter, включая меню, текст, холст, полосы прокрутки, сетки, события таймера и анимацию.
Глава 10
В этой главе рассматриваются приемы программирования графических интерфейсов: здесь мы узнаем, как автоматически конструировать меню из шаблонов объектов, как запускать графический интерфейс в виде отдельной программы, как реализовать выполнение
продолжительных операций параллельно с основной программой с помощью потоков выполнения и очередей и многое другое.
Глава 11
Эта глава объединяет идеи из предыдущих глав для реализации набора интерфейсов пользователя. В ней будут представлены более крупные примеры графических интерфейсов - часов, текстовых редакторов, программ для рисования и просмотра графических изображений и других - которые также демонстрируют приемы программирования на Python в целом.
Как и в первой части книги, представленный здесь материал применим в целом ряде областей и будет снова использован в дальнейшем для создания настроенных на конкретные области применения интерфейсов в последующих главах книги. Так, примеры PyMailGUI и PyCalc в последующих главах предполагают, что вы знакомы с основами, охватываемыми здесь.
7
Графические интерфейсы пользователя
«Я здесь, я смотрю на тебя, детка»
Для большинства программных систем графический интерфейс пользователя (Graphical User Interface, GUI) стал непременной частью пакета. Даже если акроним «GUI» вам незнаком, вы, вероятно, знакомы с такими элементами, как окна, кнопки и меню, используемые при работе с программами. В действительности большая часть работы с компьютерами сегодня осуществляется с помощью того или иного графического интерфейса вида «укажи-и-щелкни». Программы, от веб-броузера до системных инструментов, стандартно оснащаются компонентами GUI, повышающими гибкость и простоту их использования.
В этой части мы узнаем, как заставлять сценарии Python порождать такие графические интерфейсы, изучая примеры программирования с помощью модуля tkinter - переносимой библиотеки GUI, являющейся стандартной частью системы Python и широко используемой многими программистами. Как будет показано, легкость программирования интерфейсов пользователя в сценариях Python обеспечивается как простотой языка, так и мощью его библиотек GUI. Дополнительным преимуществом графических интерфейсов, запрограммированных на Python с использованием tkinter, является то, что они автоматически переносимы на большинство компьютерных систем.
Темы программирования GUI
Поскольку графические интерфейсы представляют собой большую область, я хочу сказать еще несколько слов об этой части книги. Чтобы сделать усвоение проще, темы программирования GUI разделены между следующими пятью главами этой книги:
• Данная глава начинается с краткого учебника по библиотеке tkinter, знакомящего с основами ее использования. Здесь намеренно сохраняется простота интерфейсов, чтобы вы могли овладеть базовыми знаниями, прежде чем перейти к интерфейсам из следующей главы. С другой стороны, в этой главе полностью освещаются все основы: обработка событий, менеджер компоновки pack, использование наследования и композиции в GUI и многое другое. Как будет показано, объектно-ориентированное программирование (ООП) не является обязательным для tkinter, но оно делает графические интерфейсы структурированными и многократно используемыми.
• Главы 8 и 9 представляют обзор набора графических элементов (виджетов) в библиотеке tkinter.30 В общих чертах, в главе 8 представлены простые графические элементы, а в главе 9 - более сложные графические элементы и связанные с ними инструменты. Здесь рассматривается большинство привычных элементов интерфейсов: ползунки, меню, диалоги, изображения и тому подобное. Эти две главы не могут служить полным справочником по библиотеке tkinter (который вполне мог бы превратиться в весьма объемную книгу), но их должно хватить, чтобы начать создавать серьезные графические интерфейсы на языке Python. Примеры в этих главах сосредоточены на графических элементах и инструментах tkinter, но попутно исследуется поддержка повторного использования программного кода в Python.
• В главе 10 представлены более сложные приемы программирования GUI. Здесь будут исследованы приемы автоматизации типичных задач, решаемых в графических интерфейсах на языке Python. И хотя библиотека tkinter является полнофункциональной, тем не менее небольшое количество многократно используемого программного кода на языке Python сможет сделать интерфейсы еще более мощными и простыми в использовании.
• Глава 11 завершает эту часть книги представлением нескольких программ с графическим интерфейсом, в которых используются приемы программирования и графические элементы, показанные в четырех предшествующих главах. Здесь мы узнаем, как реализовать текстовые редакторы, средства просмотра графических изображений, часы и многое другое.
Поскольку графические интерфейсы являются инструментами, используемыми в самых разных областях, другие примеры их реализации будут появляться на протяжении всей оставшейся части книги. Например, позднее мы увидим законченные графические интерфейсы для работы с электронной почтой и калькуляторы, а также простой клиент FTP с графическим интерфейсом. Дополнительные примеры, такие как средства представления деревьев и броузеры таблиц, доступны в виде внешних примеров, входящих в состав пакета с примерами. В главе 11 приводится список ссылок на другие примеры использования tkinter в данной книге.
Закончив исследование графических интерфейсов, мы в четвертой части узнаем, как конструировать пользовательские интерфейсы внутри веб-броузера, используя HTML и сценарии на языке Python, выполняющиеся на веб-сервере, - совершенно иная модель со своими достоинствами и недостатками, понимать которые просто необходимо. Далее в этой главе описываются такие новейшие технологии, как RIA (Rich Internet Application - полнофункциональные интернет-приложения), основанные на модели веб-броузера и способные предложить еще более широкие возможности в конструировании интерфейсов.
А пока сосредоточимся на более традиционных графических интерфейсах, известных как «настольные» приложения или как «автономные» графические интерфейсы. Как мы увидим далее, в части книги, посвященной созданию сценариев для Интернета, когда встретимся с графическими интерфейсами клиентов FTP и электронной почты, такие программы часто устанавливают сетевые соединения, необходимые для их работы.
Запуск примеров
Сразу же хочу отметить одно обстоятельство: в большинстве своем графические интерфейсы являются динамическими и интерактивными, а лучшее, что я могу здесь сделать, - это показать статические снимки экрана, представляющие избранные состояния взаимодействий, реализуемых такими программами. Для большинства примеров это несправедливо. Если вы еще не работаете с примерами, настоятельно рекомендую запускать примеры графических интерфейсов в этой и последующей главах самостоятельно.
В Windows стандартная установка Python имеет встроенную поддержку tkinter, поэтому все эти примеры должны работать сразу. Mac OS X также поставляется со встроенной поддержкой tkinter в Python. В других системах Python с поддержкой tkinter либо уже входит в состав системы, либо доступен для установки (подробности смотрите в файле верхнего уровня README-PP4E.txt в дереве примеров для этой книги). Несмотря на то, что вам, возможно, потребуется установить дополнительные пакеты, чтобы обеспечить работоспособность tkinter, это стоит сделать, потому что возможность поэкспериментировать с этим про-
граммами является отличным способом изучения не только программирования графических интерфейсов, но и самого языка Python.
Смотрите также замечания о переносимости примеров к этой книге в Предисловии. Несмотря на то, что и сам язык Python, и библиотека tkinter в значительной степени являются нейтральными к платформе, на которой они используются, вам, возможно, придется столкнуться с некоторыми небольшими проблемами, если вы будете пытаться запускать примеры на платформах, которые не использовались в процессе работы над этой книгой. В Mac OS X, например, могут обнаружиться тонкие отличия в работе некоторых примеров. Обязательно загляните на веб-сайт книги, где можно найти дополнительные указания и исправления, которые помогут использовать примеры на других платформах.
Кто-нибудь заметил, что «GUI» совпадает с тремя первыми буквами в имени «GUIDO»?
Создатель Python, Гвидо ван Россум (Guido van Rossum), изначально не ставил своей целью создание инструмента для разработки GUI, но из-за простоты использования Python и краткости цикла разработки он выдвинулся на одну из первых ролей. С точки зрения реализации, графические интерфейсы в Python опираются на использование расширений на языке C, а расширяемость была одной из главных идей при создании Python. Когда сценарий создает кнопки и меню, он в конечном счете обращается к библиотеке C, а когда сценарий реагирует на пользовательское событие, библиотека C в конечном счете обращается обратно к Python. Это может рассматриваться как пример взаимодействия Python с внешними библиотеками.
С практической точки зрения графические интерфейсы являются жизненно важной частью современных систем и идеальной областью применения таких инструментов, как Python. Как будет показано далее, простота синтаксиса Python и его объектноориентированные возможности хорошо сочетаются с моделью GUI - каждый изображаемый на экране графический элемент естественным образом представляется в виде класса Python. Кроме того, краткость цикла разработки в Python позволяет программистам быстро экспериментировать с вариантами расположения элементов и их поведением, что невозможно при использовании обычных технологий разработки. На практике обычно можно за считаные секунды сделать изменения в GUI, созданном на Python, и посмотреть на их результат. Не пытайтесь добиться такой же скорости на C или C++ !
Различные возможности создания GUI в Python
Прежде чем погрузиться в tkinter, рассмотрим перспективные варианты разработки GUI в Python в целом. Поскольку Python показал себя вполне подходящим инструментом для работы с графическим интерфейсом, в последние годы в этой области наблюдалась высокая активность. На практике, хотя в качестве инструмента для создания GUI в Python чаще всего используется библиотека tkinter, на сегодняшний день существуют и другие способы программирования пользовательских интерфейсов в Python. Некоторые являются специфическими для Windows или X Window,31 другие представляют собой решения для нескольких платформ, и у всех них есть свои приверженцы и свои сильные стороны. Чтобы быть справедливыми ко всем вариантам, приведем краткий перечень инструментов создания графических интерфейсов, доступных программистам Python на момент написания этих строк:
tkinter
Библиотека для разработки графических интерфейсов, распространяемая с открытыми исходными текстами, ставшая де-факто стандартом для разработки переносимых графических интерфейсов на языке Python. Сценарии на языке Python, использующие tkinter для построения GUI, выполняются переносимым образом в Windows, X Window (Unix и Linux) и Macintosh OS X, создавая на каждой из этих платформ графический интерфейс, со свойственным им внешним видом. Кроме того, она может легко расширяться программным кодом на языке Python, а также имеет множество дополнительных пакетов, таких как Pmw (сторонняя библиотека виджетов); Tix (еще одна библиотек виджетов, ныне ставшая стандартной частью Python); PIL (расширение для обработки изображений) и ttk (библиотека виджетов Tk, поддерживающих темы оформления, также ставшая стандартной частью Python, начиная с версии 3.1). Подробнее о подобных расширениях рассказывается ниже в этом введении.
Библиотека Tk, на которой основана библиотека tkinter, является стандартом в мире открытого программного обеспечения в целом и используется также языками сценариев Perl, Ruby, PHP, Common Lisp и Tcl, благодаря чему количество пользователей этой библиотеки может исчисляться миллионами. Промежуточная библиотека, связывающая Python и Tk, дополняет последнюю простой объектной моделью Python - благодаря ей виджеты Tk из строковых команд превратились в легко настраиваемые объекты. Библиотека tkinter в Python 3.X приняла форму пакета с вложенными модулями, обеспечивающими группировку некоторых из ее инструментов по функциональности (ранее, в Python 2.X, эта библиотека имела форму модуля tkinter, но была переименована в соответствии с общепринятыми соглашениями об именовании и реструктурирована для обеспечения иерархической организации).
tkinter - зрелая, надежная, широко используемая и хорошо документированная библиотека. Она включает около 25 основных типов виджетов, а также различные диалоги и другие инструменты. Издана книга, посвященная описанию библиотеки, а кроме того, имеется огромное количество опубликованной документации с описанием tkinter и Tk. Также важно, что так как tkinter основана на библиотеке, разработанной для использования в языках сценариев, она является относительно легковесным набором инструментов и поэтому прекрасно сочетается с языком Python.
Благодаря таким характеристикам библиотека tkinter распространяется в составе Python как модуль стандартной библиотеки и стала основой стандартной интегрированной среды разработки IDLE с графическим интерфейсом. Фактически библиотека tkinter является единственным набором инструментов для создания графических интерфейсов, ставшим частью Python, - все остальные в этом списке являются сторонними расширениями. На некоторых платформах (включая Windows, Mac OS X и большинство Linux и Unix-подобных систем) библиотека Tk также распространяется в составе Python. Вы можете с достаточной степенью уверенности рссчитывать, что к моменту запуска сценария библиотека tkinter будет присутствовать на компьютере, а при необходимости вы сможете обеспечить это, скомпилировав свой графический интерфейс в автономный выполняемый файл с помощью таких инструментов, как PyInstaller и py2exe (подробности ищите в Интернете).
Несмотря на простоту библиотеки tkinter, ее текстовые и графические виджеты обеспечивают достаточно широкие возможности для реализации веб-страниц, трехмерных изображений и анимации. Кроме того, на сегодняшний день многие системы предоставляют построители графических интерфейсов для связки Python/tkinter, включая GUI Builder (ранее входивший в состав среды разработки Komodo IDE и родственной ей SpecTCL), Rapyd-Tk, xRope и другие (этот перечень имеет свойство значительно изменяться с течением времени; более полный перечень вы найдете на странице http://wiki. python.org/moin/GuiProgramming или поискав самостоятельно в Интернете). Однако, как будет показано далее, библиотека tkinter во многих случаях оказывается настолько удобна в использовании, что построители графических интерфейсов не получили широкого распространения. В справедливости этого утверждения мы убедимся, как только покинем область статических интерфейсов, которые обычно поддерживаются построителями.
wxPython
Интерфейс Python к библиотеке wxWidgets с открытыми исходными текстами (ранее называвшейся wxWindows), которая представляет собой переносимую структуру классов GUI, первоначально созданную для использования из программ на языке C++. Система wxPython является модулем расширения, служащим оболочкой для классов wxWidgets. По общему мнению эта библиотека превосходно подходит для создания сложных интерфейсов и сегодня является, вероятно, вторым по популярности инструментом создания графических интерфейсов в Python после tkinter. Графические интерфейсы, созданные с применением wxPython, переносимы на Windows и Unix-подобные платформы и Mac OS X.
Поскольку интерфейс wxPython опирается на библиотеку классов C++, многие полагают, что он более сложен в использовании, чем библиотека tkinter: он предоставляет доступ к сотням классов, для чего требуется прибегать к объектно-ориентированному стилю программирования, и имеет архитектуру, которая некоторым напоминает библиотеку классов MFC в Windows. Применение wxPython часто требует от программистов писать больше программного кода, отчасти потому, что этот интерфейс обладает более широкими функциональными возможностями, а отчасти потому, что именно такой образ мышления он унаследовал от библиотеки C++, лежащей в его основе.
Кроме того, часть документации wxPython ориентирована на программистов, использующих язык C++. Впрочем, недавно эта ситуация немного улучшилась - после выхода книги, посвященной wxPython. Библиотеке tkinter, напротив, посвящена книга, огромные разделы в других книгах о языке Python и еще масса литературы по библиотеке Tk, лежащей в ее основе. Однако, поскольку мир книг о языке Python в последние годы расширялся достаточно динамично, вам следует тщательно подходить к выбору литературы - некоторые книги со временем устаревают, но регулярно появляются новые.
В обмен на повышенную сложность библиотека wxPython обеспечивает набор мощных инструментов. В состав wxPython входит более богатый набор виджетов, чем в библиотеку tkinter, включая деревья и компоненты просмотра HTML - чтобы получить такие же компоненты при использовании tkinter, может потребоваться задействовать такие расширения, как Pmw, Tix или ttk. Кроме того, некоторым нравится, как выглядят графические интерфейсы, созданные с помощью wxPython. BoaConstructor и wxDesigner среди других возможностей предоставляют построители графических интерфейсов, которые генерируют программный код для wxPython. Некоторые инструменты в библиотеке wxWidgets также поддерживают операции, не имеющие отношения к графическим интерфейсам. Чтобы быстро посмотреть, как выглядят виджеты wxPython и соответствующий программный код, запустите демонстрационный пример, который поставляется вместе с wxPython (смотрите страницу http://wxpython.org/ или поищите в Интернете самостоятельно).
PyQt
Интерфейс Python к библиотеке Qt (ныне принадлежит Nokia, ранее принадлежала компании Trolltech), занимающей, пожалуй, третье место среди наиболее часто используемых инструментов GUI для Python. PyQt - это полноценная библиотека создания графических интерфейсов, которая на сегодняшний день переносима в Windows, Mac OS X, Unix и Linux. Подобно wxPython, библиотека PyQt в целом более сложна в использовании, чем tkinter, и при этом обладает более богатыми возможностями - она содержит сотни классов и тысячи функций и методов. Библиотека Qt зародилась и выросла в Linux, но со временем была перенесена и на другие системы. Вследствие своего происхождения расширения PyQt и PyKDE предоставляют доступ к библиотекам KDE (PyKDE требует библиотеку PyQt). Системы BlackAdder и Qt Designer предоставляют построители GUI для PyQt.
Самым важным, пожалуй, недостатком Qt в прошлом считалась неполная открытость библиотеки для коммерческого использования. Сегодня библиотека Qt распространяется не только под коммерческой лицензией, но и под открытыми лицензиями GPL и LGPL. Версии, распространяемые под LGPL и GPL, являются открытыми и следуют требованиям лицензии GPL (GPL накладывает требования, отсутствующие в лицензии BSD, под которой распространяется сам Python, - согласно GPL, например, вы должны сделать исходные тексты программ доступными для конечных пользователей).
PyGTK
Интерфейс Python к GTK, переносимой библиотеке GUI, первоначально использовавшейся как ядро оконной системы Gnome в Linux. Пакеты расширений gnome-python и PyGTK экспортируют функции в инструментальных наборах Gnome и GTK для использования в сценариях Python. К моменту написания этих строк интерфейс PyGTK поддерживал возможность работы в Windows и в POSIX-совместимых системах, таких как Linux и Mac OS X (согласно документации, в настоящее время требуется, чтобы в Mac OS был установлен X-сервер, при этом разрабатывается версия для Mac).
Jython
Jython (система, известная ранее, как JPython) является реализацией Python для Java, которая компилирует исходный программный код Python в байт-код Java и обеспечивает сценариям Python беспрепятственный доступ к библиотекам классов Java на локальном компьютере. Благодаря этому библиотеки для построения графических интерфейсов на языке Java, такие как swing и awt, дают еще один способ построения GUI на языке Python, выполняемом в системе JPython. Очевидно, такие решения являются специфическими для Java, и их переносимость ограничена переносимостью языка Java и его библиотек. Кроме того, следует отметить, что swing является самым крупным и самым сложным способом создания GUI в Python. Кроме того, существует новый пакет под названием jt-kinter, который является версией tkinter для Jython, использующей Java JNI, - если он установлен, сценарии на языке Python смогут также использовать tkinter для построения GUI в Jython. Еще раз с Jython мы встретимся в главе 12, когда будем знакомиться с его ролью в Интернете.
IronPython
Очень напоминающая Jython, система IronPython является реализацией языка Python для окружения .NET, которая, кроме всего прочего, компилирует программы на языке Python в байт-код .NET, что также позволяет сценариям Python использовать возможности конструирования графических интерфейсов, имеющиеся в .NET Framework. Вы пишете программный код на языке Python, но для конструирования интерфейсов и приложений в целом используете компоненты C#/.NET. Программный код на IronPython может выполняться в Windows, под управлением .NET, и в Linux, под управлением Mono, реализации .NET, и Silverlight, клиентской платформы полнофункциональных интернет-приложений (RIA) для вебброузеров (обсуждается далее).
PythonCard
Построитель и библиотека GUI с открытыми исходными текстами, реализованные поверх wxPython. Считается одним из самых близких Python-эквивалентов того вида построителей GUI, которые хорошо знакомы разработчикам на Visual Basic. PythonCard позиционируется разработчиками, как конструктор GUI для создания на языке Python кроссплатформенных приложений, способных выполняться в Windows, Mac OS X и Linux.
Dabo
Построитель графических интерфейсов с открытыми исходными текстами, также реализованный на основе wxPython, но не только. Dabo -это переносимый, трехуровневый, кроссплатформенный фреймворк для разработки настольных приложений на языке Python, созданный по образу и подобию Visual FoxPro. Трехуровневая организация обеспечивает возможность доступа к базе данных, реализации бизнес-логики и пользовательского интерфейса. Открытая архитектура способна поддерживать различные типы баз данных и механизмов создания графических интерфейсов (wxPython, tkinter и даже HTML через HTTP).
Полнофункциональные интернет-приложения (Rich Internet Applications, RIA)
Хотя веб-страницы, отображаемые с помощью HTML, также могут считаться своего рода пользовательским интерфейсом, они исторически обладают массой ограничений, что затрудняет их отнесение к категории универсальных графических интерфейсов. Тем не менее некоторые специалисты склонны расширять рамки этой категории и включать в нее системы, обеспечивающие интерфейсам на основе броузеров более высокую динамичность по сравнению с традиционными веб-страницами. Поскольку такие системы предоставляют комплекты виджетов, отображаемых веб-броузерами, они способны предложить те же преимущества переносимости, которые свойственны веб-страницам в целом.
Это новое поколение инструментов называется модным термином полнофункциональные интернет-приложения (Rich Internet Applications, RIA). В их число входят AJAX и фреймворки, ориентированные на широкое применение JavaScript на стороне клиента, такие как:
Flex
Фреймворк с открытыми исходными текстами от компании Adobe и часть платформы Flash*
Silverlight
Фреймворк от корпорации Microsoft, который также реализован в Linux в виде фреймворка Moonlight для Mono, - доступный из программного кода на языке Python при использовании описанной выше системы IronPython*
JavaFX
Платформа Java для построения RIA, которые способны выполняться на различных связанных между собой устройствах*
pyjamas
Версия фреймворка Google Web Toolkit, опирающегося на использование AJAX, реализованная на языке Python, в состав которой входит набор виджетов пользовательского интерфейса и компилятор с языка Python на язык JavaScript, что позволяет выполнять сценарии в броузере, на стороне клиента*
Свои решения в этой области предлагает и стандарт HTML5, находящийся в разработке.
Вообще говоря, веб-броузеры сами являются «настольными» приложениями с графическим интерфейсом, но они получили гораздо более широкое распространение, чем библиотеки GUI, и благодаря инструментам RIA способны отображать другие графические интерфейсы. С помощью таких фреймворков можно строить графические интерфейсы, основанные на использовании виджетов, но за ними стоят накладные расходы, связанные с необходимостью сетевых взаимодействий, и они часто подразумевают использование более тяжеловесного программного комплекса, чем традиционные инструменты создания графических интерфейсов. В действительности, чтобы превратить броузеры в универсальные платформы отображения графических интерфейсов, полнофункциональные интернет-приложения предполагают использование дополнительных программных уровней и зависимостей и даже нескольких языков программирования. Поэтому, а также потому, что далеко не все занимаются разработкой веб-приложений (независимо от того, что вы могли об этом слышать), мы не будем включать их в рассмотрение традиционных автономных/настольных графических интерфейсов в этой части книги.
Дополнительные сведения о полнофункциональных интернет-приложениях и о пользовательских интерфейсах на основе веб-броузеров вы найдете в части книги, посвященной разработке сценариев для Интернета. К тому же обязательно следите за новостями и веяньями по этой теме. Интерактивность, которую обеспечивают эти инструменты, является ключевой составляющей того, что иногда называют «Web 2.0», делая больший акцент на Web, а не на традиционные графические интерфейсы. Однако, так как здесь для нас больший интерес представляют последние (и поскольку взаимодействие с пользователем - это взаимодействие с пользователем, независимо от используемого профессионального жаргона), мы отложим дальнейшее обсуждение этой темы до следующей части книги.
Платформозависимые инструменты.
Помимо переносимых инструментов, таких как tkinter, wxPython и PyQt, и платформонезависимых решений, таких как полнофункциональные интернет-приложения, большинство основных платформ обладают также непереносимыми средствами создания графических интерфейсов на языке Python. Например, в Macintosh OS X имеется интерфейс PyObjC для Python, обеспечивающий доступ к фреймворку Objective-C/Cocoa компании Apple, который составляет основу разработки многих приложений для Mac. В Windows имеется расширение PyWin32 для Python, включающее обертки для доступа к фреймворку Microsoft Foundation Classes (MFC) (библиотека, включающая интерфейсные компоненты), а также Pythonwin - пример типичной программы на основе MFC, реализующей среду разработки на языке Python с графическим интерфейсом. Несмотря на то, что технически в Linux имеется поддержка .NET, тем не менее система IronPython, упоминавшаяся выше, предлагает дополнительные возможности, которые могут использоваться только в Windows.
За дополнительными подробностями обо всех перечисленных инструментах обращайтесь на веб-сайты этих проектов. Существуют и другие, менее известные инструментарии GUI для Python, а к тому времени, когда вы будете читать эту книгу, наверняка появятся новые (например, IronPython стал новинкой для третьего издания, а для четвертого издания новинкой стали инструменты реализации полнофункциональных интернет-приложений). Кроме того, перечень доступных пакетов постоянно изменяется. Свежий список имеющихся инструментов можно найти с помощью поисковых систем, а также на сайте http:// www.python.org и в каталоге PyPI пакетов сторонних разработчиков, поддерживаемом там же.
Обзор tkinter
Однако все эти способы создания графических интерфейсов сегодня значительно опережает библиотека tkinter как стандарт де-факто реализации переносимых пользовательских интерфейсов на Python, которой и посвящена эта часть книги. Доводы в пользу использования этого подхода уже приводились в главе 1 - я предпочел подробно описать один инструментарий вместо поверхностного обзора нескольких. Кроме того, большинство концепций программирования с использованием библиотеки tkinter, с которыми вы познакомитесь здесь, можно с легкостью перенести на любые другие инструменты GUI.
Практические преимущества tkinter
Но как бы то ни было, существуют более прагматичные причины, объясняющие, почему библиотека tkinter де-факто стала в мире Python стандартом разработки переносимых графических интерфейсов. Такие преимущества, как доступность, переносимость, простота получения, документированность и наличие расширений, делают ее наиболее широко используемым решением для Python в области GUI в течение многих лет:
Доступность
Библиотека tkinter в целом рассматривается как облегченный набор инструментов и одно из наиболее простых решений в области разработки графических интерфейсов для Python из имеющихся на сегодняшний день. В отличие от более крупных фреймворков, библиотека tkinter позволяет сразу же приступить к работе с ней, без необходимости предварительно осваивать значительно более крупные модели взаимодействия классов. Как будет показано далее, программист может создать с помощью tkinter простой интерфейс, написав всего несколько строк программного кода, и постепенно наращивать его возможности до достижения промышленного уровня. Несмотря на всю простоту прикладного интерфейса библиотеки tkinter, она позволяет добавлять новые виджеты, написанные на языке Python, или подключать дополнительные расширения, такие как Pmw, Tix и ttk.
Переносимость
Сценарий на языке Python, в котором графический интерфейс строится с помощью библиотеки tkinter, будет работать без изменений на всех основных современных оконных платформах: Microsoft Windows, X Window (в Unix и Linux) и Macintosh OS X (а также в классической версии Mac). Более того, этот сценарий создаст интерфейс, внешний вид которого будет привычен пользователям каждой из этих платформ. Эта особенность развивалась по мере того как библиотека Tk становилась все более зрелой. Графический интерфейс, реализованный сценарием Python/tkinter, в Windows выглядит, как должен выглядеть интерфейс программы для Windows; в Unix и Linux обеспечивает такое же взаимодействие с пользователем, но демонстрирует внешний вид, знакомый пользователям X Window; и на Mac он выглядит так, как должна выглядеть программа Mac.
Простота получения
tkinter является модулем стандартной библиотеки Python, поставляемой вместе с интерпретатором. Если Python установлен на вашем компьютере, то у вас есть доступ и к библиотеке tkinter. Более того, в большинство пакетов установки Python (включая стандартный пакет установки Python для Windows, пакет установки для Mac и пакеты установки для большинства дистрибутивов Linux) уже включена поддержка tkinter. Благодаря этому сценарии, написанные с использованием модуля tkinter, сразу могут работать с большинством интерпретаторов Python, не требуя дополнительных действий по установке. Библиотека tkinter также в целом лучше поддерживается, чем существующие сегодня альтернативные пакеты. Поскольку задействованная в ней библиотека Tk используется также языками программирования Tcl и Perl (и многими другими), ей уделяется больше внимания и усилий разработчиков, чем другим имеющимся инструментариям.
Естественно, при использовании инструментов разработки графических интерфейсов важную роль играют и другие факторы, такие как
наличие документации и расширений. Рассмотрим вкратце, что можно
в этом отношении сказать о библиотеке tkinter.
Документация tkinter
В данной книге исследуются основы использования tkinter и большинство виджетов, чего должно быть достаточно, чтобы приступить к созданию графических интерфейсов на языке Python. С другой стороны, книга не является исчерпывающим справочником по библиотеке tkinter или по расширениям к ней. К счастью, когда я пишу этот абзац, в продаже есть по крайней мере одна книга, посвященная использованию tkinter в Python, и готовятся к выходу другие (подробности ищите в Интернете). Кроме книг можно найти электронную документацию по tkinter - полный комплект руководств по tkinter в настоящее время присутствует на сайте http://www.pythonware.com/library.
Кроме того, поскольку инструментарий Tk, используемый в tkinter, также де-факто является стандартом в сообществе открытого программного обеспечения в целом, можно использовать и другие источники документации. Например, библиотека Tk принята также к использованию в языках программирования Tcl и Perl, поэтому книги и документация по Tk, написанные для этих двух языков, могут также непосредственно использоваться при использовании связки Python/tkinter (правда, при этом необходимо будет учитывать синтаксические различия).
Честно говоря, я изучал библиотеку tkinter по книгам и справочникам Tcl/Tk - просто замените строки Tcl объектами Python, и вы получите в свое распоряжение дополнительные библиотеки справочников (чтение документации по Tk облегчит руководство по преобразованию Tk в tkinter, представленное в виде табл. 7.2 в конце данной главы). Например, книга «Tcl/Tk Pocket Reference» («Карманный справочник по Tcl/ Tk»), выпущенная издательством O’Reilly, может служить прекрасным дополнением к учебному материалу по tkinter в данной части книги. Кроме того, поскольку понятия Tk знакомы большому числу программистов, поддержку по Tk можно легко получить в Сети.
После того как вы изучите основы, вы также сможете немало почерпнуть из примеров. В Интернете можно найти множество примеров демонстрационных программ, использующих tkinter, помимо тех, что будут представлены в этой книге. Даже в составе дистрибутива с исходными текстами Python имеется несколько демонстрационных программ, в подкаталоге Demos\tkinter. Среда разработки IDLE с графическим интерфейсом, упоминающаяся в следующем разделе, также представляет интерес для изучения.
Расширения для tkinter
Благодаря широкому использованию библиотеки tkinter, программистам доступны готовые расширения, предназначенные для работы с ней или дополняющие ее. На момент написания этих строк некоторые из них еще не были доступны для версии Python 3.X. Например:
Pmw
Python Mega Widgets является расширением, предназначенным для создания составных виджетов высокого уровня в Python с помощью модуля tkinter. Он расширяет прикладной интерфейс tkinter набором более сложных графических элементов для разработки улучшенных графических интерфейсов, и предоставляет основу для создания собственных виджетов. В число готовых и расширяемых графических элементов, имеющихся в пакете, входят блокноты, комбинированные списки, элементы выбора, панели, окна с прокруткой, диалоговые окна, виджеты группировки кнопок, всплывающие подсказки и интерфейс к пакету Blt для построения графиков.
Прикладной интерфейс графических элементов («мегавиджетов») Pmw напоминает интерфейс базовых графических элементов tkinter, поэтому в сценариях на языке Python могут совместно использоваться элементы Pmw и стандартные элементы tkinter. Кроме того, расширение Pmw написано исключительно на языке Python и потому не требует наличия компилятора с языка C или установки дополнительных инструментов. Чтобы ознакомиться с виджетами из этого расширения, а также посмотреть на программный код их реализации, запустите сценарий demos\All.py, входящий в дистрибутив Pmw. Получить Pmw можно по адресу: http://pmw.sourceforge.net.
Tix
Tix - это коллекция из более чем 40 улучшенных виджетов, изначально написанных для Tcl/Tk, но теперь доступных для использования в программах Python/tkinter. В настоящее время этот пакет входит в состав стандартной библиотеки Python под названием tkinter.tix. Подобно Tk, библиотека Tix, используемая модулем, распространяется в составе дистрибутива Python для Windows. Другими словами, во время установки Python в Windows одновременно устанавливается и библиотека Tix с дополнительными виджетами.
Пакет Tix содержит множество тех же графических элементов, которые входят в состав Pmw, включая счетчики, деревья, блокноты с вкладками, всплывающие подсказки, панели и многие другие. За дополнительной информацией обращайтесь к разделу о пакете Tix в руководстве по библиотеке Python. Чтобы быстро посмотреть, как выглядят виджеты из этого пакета, а также взглянуть, как они используются в программном коде, воспользуйтесь демонстрационной программой tixwidgets.py в каталоге Demo\tix, в дистрибутиве с исходными текстами Python (этот каталог не устанавливается по умолчанию в Windows и часто изменяется, но его можно отыскать после распаковки дистрибутива с исходными текстами, полученного с сайта проекта Python.org).
ttk
Библиотека ttk виджетов Tk, поддерживающих темы оформления, -это относительно новый набор виджетов, в которых предпринята попытка отделить реализацию поведения от реализации их внешнего вида. Классы виджетов сохраняют информацию о своем состоянии и поддерживают систему обратных вызовов, при этом внешний вид элементов реализуется отдельно, с применением тем оформления. Подобно Tix, это расширение начинало свое существование как отдельная библиотека, но совсем недавно, в версии Python 3.1, было интегрировано в стандартную библиотеку Python как модуль tkinter.ttk.
Кроме того, подобно Tix, это расширение включает улучшенные виджеты, часть из которых отсутствует в стандартной библиотеке tkinter. Точнее, ttk содержит 17 виджетов, из которых 11 уже присутствуют в библиотеке и предназначены для замены некоторых стандартных виджетов, а 6 - являются новыми: Combobox, Notebook, Progressbar, Separator, Sizegrip и Treeview. В двух словах: чтобы задействовать новые виджеты ttk, сценарии должны импортировать их из модуля ttk после импортирования модуля tkinter и вместо настройки самих виджетов настроить объекты стилей, которые могут использоваться совместно несколькими виджетами.
Как будет показано далее в этой главе, имеется возможность обеспечить единство оформления с виджетами из стандартной библиотеки tkinter - за счет создания подклассов виджетов с применением обычных приемов ООП (смотрите раздел «Настройка виджетов с помощью классов» ниже). При этом ttk предлагает дополнительные возможности оформления и улучшенные типы виджетов. За дополнительной информацией о виджетах ttk обращайтесь к соответствующему разделу в руководстве по библиотеке Python или поищите в Интернете - эта книга описывает основы использования tkinter, а расширения tix и ttk слишком большие, чтобы их можно было охватить с достаточной степенью подробности.
PIL
Python Imaging Library (PIL) является расширением с открытыми исходными текстами, добавляющим в Python дополнительные средства для работы с графикой. Помимо всего прочего, он добавляет инструменты для создания миниатюр изображений, их трансформации и преобразования, расширяет базовый набор графических объектов tkinter и обеспечивает поддержку отображения многих типов графических файлов. Расширение PIL, например, позволяет графическим интерфейсам на базе tkinter отображать изображения в форматах JPEG, TIFF и PNG, не поддерживаемых базовыми инструментами tkinter (без дополнительных расширений, библиотека tkinter поддерживает только формат GIF и некоторые растровые форматы). Более подробное описание и примеры использования этого расширения вы найдете в конце главы 8 - мы будем использовать это расширение в некоторых примерах, связанных с обработкой изображений. Расширение PIL можно найти на странице проекта http:// www.pythonware.com или выполнив поиск в Интернете.
IDLE
Интегрированная среда разработки на языке Python IDLE сама написана на Python и tkinter. Она поставляется и устанавливается вместе с пакетом Python (если у вас свежий интерпретатор Python, то должна быть и среда IDLE, - в Windows щелкните на кнопке Пуск (Start), выберите пункт меню Все программы (ALL Programs), щелкните на элементе меню Python и вы увидите ее). Как среда разработки IDLE предоставляет текстовые редакторы с подсветкой синтаксиса, интерфейс отладки «указал-и-щелкнул» и многое другое. Эта среда может служить примером использования tkinter.
Другие
Многие расширения, предоставляющие инструменты визуализации для Python, основаны на библиотеке tkinter и ее виджете холста. Дополнительные примеры расширений библиотеки tkinter можно найти на веб-сайте PyPI или воспользовавшись поисковыми системами.
Если вы собираетесь заниматься коммерческой разработкой графических интерфейсов на основе tkinter, вам, вероятно, следует ознакомиться с такими расширениями, как Pmw, PIL, Tix и ttk, после изучения основ tkinter в данной книге. Они помогут сэкономить время разработки и добавить блеска в ваши интерфейсы. Самые последние новости и ссылки смотрите на сайтах, посвященных Python, указанных выше.
Структура tkinter
С технической точки зрения, библиотека tkinter является интегрирующей системой, требующей некоторой особой организации программ. Что это означает, мы увидим чуть ниже, а пока кратко познакомимся с некоторыми терминами и понятиями, лежащими в основе программирования графических интерфейсов на языке Python.
Структура реализации
Строго говоря, tkinter является просто названием интерфейса к Tk - библиотеке GUI, первоначально написанной для использования с языком программирования Tcl и разработанной создателем Tcl Джоном Оустер-хаутом (John Ousterhout). Модуль tkinter обращается к библиотеке Tk, которая в свою очередь обращается к оконной системе: Microsoft Windows, X Window в Unix или к графической подсистеме Macintosh. Переносимость библиотеки tkinter фактически зависит от переносимости библиотеки Tk.
tkinter - программный слой поверх Tk, позволяющий сценариям на языке Python обращаться к библиотеке Tk, конструирующей и настраивающей интерфейсы и возвращающей управление обратно в сценарии Python, которые обрабатывают события, генерируемые пользователем (например, щелчки мышью). Таким образом, обращения к графическому интерфейсу из сценария Python направляются в tkinter, а затем в Tk; события, возникающие в графическом интерфейсе, направляются из Tk в tkinter, а затем обратно в сценарий Python. В главе 20 мы встретимся с этими переходами под именами, которые они имеют в интеграции с языком C: расширение и встраивание.
Технически в настоящее время библиотека tkinter организована как комбинация файлов пакета tkinter на языке Python и модуля расширения с именем _tkinte r, который написан на языке C. Модуль _tkinte r обращается к библиотеке Tk, используя инструменты расширений, и производит обратные вызовы объектов Python, используя инструменты встраивания, - модуль tkinter просто добавляет объектно-ориентированный интерфейс поверх _tkinter. Однако вам в своих сценариях практически всегда придется импортировать модуль tkinter, а не _tkinter - последний, являясь модулем реализации, предназначен исключительно для внутреннего использования (и получил такое необычное название именно по этой причине).
Программная структура
К счастью, программистам на языке Python обычно не нужно беспокоиться обо всей этой интеграции и маршрутизации вызовов, реализуемыми внутренними механизмами: они просто создают виджеты и регистрируют функции на языке Python для обработки событий этих элементов. Однако из-за имеющейся в итоге структуры обработчики событий обычно называют обработчиками обратного вызова, потому что библиотека GUI «делает обратный вызов» программного кода на языке Python, когда происходят события.
Ниже мы увидим, что программы Python/tkinter полностью управляются событиями: они создают графические интерфейсы и регистрируют обработчики событий, а затем ничего не делают и только ждут, когда произойдут события. Во время этого ожидания библиотека Tk выполняет цикл событий, который следит за щелчками мыши, нажатием клавиш и так далее. Вся обработка, выполняемая прикладной программой, происходит в зарегистрированных обработчиках, вызываемых в ответ на происходящие события. Кроме того, вся информация, необходимая одновременно разным событиям, должна храниться по ссылкам с длительным сроком жизни, например в глобальных переменных и атрибутах экземпляров классов. Представление об обычной линейной логике выполнения программы неприменимо к графическим интерфейсам - здесь нужно мыслить на языке небольших фрагментов программного кода.
В языке Python библиотека Tk становится объектно-ориентированной просто потому, что сам Python является объектно-ориентированным языком: слой tkinter экспортирует прикладной интерфейс библиотеки Tk как классы Python. При работе с библиотекой tkinter можно использовать простой подход, основанный на вызовах функций, создающих виджеты и интерфейсы, или объектно-ориентированные приемы, такие как наследование и композиция, для настройки и расширения классов из базового набора tkinter. Большие графические интерфейсы на базе tkinter обычно строятся как деревья связанных между собой графических элементов и часто реализуются в виде классов Python, чтобы обеспечить структурированность и сохранность информации о состоянии в промежутках между событиями. В этой части книги мы увидим, что графические интерфейсы на базе tkinter, реализация которых представляется классами, почти по умолчанию становятся многократно используемыми программными компонентами.
Взбираясь по кривой обучения программированию графических интерфейсов
Теперь перейдем к программированию. Начнем с нескольких небольших примеров, иллюстрирующих основные понятия, и покажем, как создаются окна на экране компьютера. По ходу изложения примеры будут становиться более сложными, но для начала - об основных принципах.
«Hello World» в четыре строки (или меньше)
Обычно первым делом при изучении особенностей создания графических интерфейсов демонстрируется пример, выводящий в окне строку «Hello World». Пример 7.1 делает это в четырех строках.
Пример 7.1. PP4E\Gui\Intro\gui1.py
from tkinter import Label # импортировать виджет
widget = Label(None, text='Hello GUI world!’) # создать его
widget.pack() # разместить
widget.mainloop() # запустить цикл событий
Это законченная программа на языке Python, реализующая графический интерфейс с помощью библиотеки tkinter. При запуске этого сценария получается простое окно с меткой посередине. Его вид, как оно выглядит в Windows 7 на моем ноутбуке, показан на рис. 7.1 (я специально растягивал некоторые окна, изображения которых приводятся в этой книге, по горизонтали, чтобы заголовки окон были видны полностью; внешний вид окон у вас может немного отличаться, в зависимости от используемой платформы).
Пока здесь нечем особенно похвастать, но обратите внимание, что это независимое полнофункциональное окно на экране компьютера. Его можно распахнуть на весь экран, свернуть и спрятать на системной панели, изменить его размер. Щелкните на кнопке «X» в правом верхнем углу окна, чтобы закрыть его и завершить программу.
Рис. 7.1. «Hello World» (gui1) в Windows
Кроме того, сценарий, создающий это окно, полностью переносим. Запустите его на своем компьютере, чтобы увидеть окно, создаваемое им. При запуске этого файла в Linux создается аналогичное окно, но ведет оно себя в соответствии с работающим в Linux менеджером окон. Даже в одной и той же системе один и тот же программный код на языке Python в разных оконных системах (например, в KDE и Gnome) может воспроизводить окна, выглядящие по-разному. Тот же сценарий будет воспроизводить окна, отличающиеся внешним видом, в Macintosh и других Unix-подобных системах. Однако на всех платформах его поведение будет одним и тем же.
Основы использования tkinter
Сценарий gui1 является тривиальным примером, но он иллюстрирует шаги, которые выполняются большинством программ, использующих библиотеку tkinter. Этот сценарий делает следующее:
1. Загружает класс виджета из модуля tkinter*
2. Создает экземпляр импортированного класса Label*
3. Упаковывает (размещает) новый объект Label в его родительском элементе*
4. Вызывает функцию mainloop, чтобы показать окно и начать цикл событий tkinter*
Метод mainloop, вызываемый последним, помещает метку на экран и входит в состояние ожидания, в котором отслеживаются события графического интерфейса, генерируемые пользователем. Внутри функции mainloop библиотека tkinter следит за такими вещами, как клавиатура или мышь, чтобы обнаружить порожденные пользователем события. Функционально функция mainloop в библиотеке tkinter напоминает следующий псевдокод:
def mainloop():
пока главное окно не закрыто: если возникло событие:
вызвать соответствующий обработчик
В этой модели вызов mainloop в примере 7.1 никогда не вернет управление сценарию, пока графический интерфейс отображается на экране.32 Как мы увидим, добравшись до больших сценариев, единственным способом выполнять какие-либо операции после вызова mainloop является регистрация обработчиков обратного вызова, реагирующих на события.
Это называется разработкой программ, управляемых событиями, и, возможно, это один из самых необычных аспектов графических интерфейсов. Программы с графическим интерфейсом принимают форму набора обработчиков событий, которые совместно используют хранящуюся информацию, а не линейного потока выполнения. Как это выглядит в действующем программном коде, мы увидим в последующих примерах.
Обратите внимание, что для создания графического интерфейса в этом сценарии действительно необходимо выполнить шаги 3 и 4. А чтобы отобразить окно, нужно вызвать mainloop - для вывода виджетов внутри окна они должны быть скомпонованы (то есть размещены), чтобы менеджер компоновки tkinter знал о них. На самом деле, если вызвать только mainloop или только pack, не вызывая второго из них, окно будет показывать не то, что нужно: mainloop без pack выведет пустое окно, а pack без mainloop не выведет ничего, потому что сценарий не войдет в состояние ожидания событий (можете попробовать). Иногда вызывать функцию mainloop необязательно, например, при программировании в интерактивной оболочке, но в общем случае вам не следует полагаться на это.
Поскольку понятия, иллюстрируемые этим простым примером, лежат в центре большинства программ tkinter, рассмотрим их несколько глубже, прежде чем двинуться дальше.
Создание виджетов
При создании графических элементов в tkinter можно указать, как они должны быть настроены. Сценарий gui1 передает два аргумента конструктору класса Label:
• Первый аргумент определяет объект родительского виджета, к которому нужно прикрепить новую метку. В данном случае None означает «прикрепить новый виджет Label к установленному по умолчанию окну верхнего уровня данной программы». Позднее в этом аргументе мы будем передавать фактические виджеты, чтобы прикреплять метки к другим объектам-контейнерам.
• Второй аргумент служит параметром настройки для Label. Он имеет форму именованного аргумента: параметр text определяет строку текста, которая должна появиться в виде метки. Большинство конструкторов виджетов принимают несколько именованных аргументов, определяющих различные параметры (цвет, размер, обработчики событий и так далее). Однако большинство параметров настройки виджетов имеют вполне разумные значения по умолчанию для каждой платформы, чем в значительной мере объясняется простота tkinter. Большинство параметров требуется определять, только если необходимо выполнить нестандартные настройки.
Как будет показано далее, аргумент, определяющий родительский виджет, является основой для построения сложных графических интерфейсов в виде деревьев виджетов. Библиотека tkinter действует по принципу «что построишь, то и получишь» - деревья объектов виджетов создаются как модели того, что мы хотим видеть на экране, а затем мы просим дерево изобразить себя с помощью вызова mainloop.
Менеджеры компоновки
Метод pack виджетов, к которому обращается сценарий gui1, вызывает менеджер компоновки - один из трех способов управления организацией графических элементов в окне. Менеджеры компоновки в библиотеке tkinter просто организуют один или несколько виджетов внутри контейнера (который иногда называется родителем или владельцем). Контейнерами могут служить окна верхнего уровня и фреймы (особая разновидность виджетов, с которой мы познакомимся далее), при этом сами контейнеры могут вкладываться внутрь других контейнеров, образуя иерархические отображения.
Для автоматического размещения виджетов в окне менеджер компоновки использует ограничивающие параметры. Сценарии передают высокоуровневые инструкции (например, «прикрепить данный виджет к верхней части контейнера и растянуть по вертикали до заполнения пространства»), а не абсолютные координаты в пикселях. Поскольку такие ограничения весьма абстрактны, менеджер компоновки предоставляет мощную и простую в использовании систему размещения элементов. В действительности вам даже не обязательно задавать ограничения - если не передавать аргументы методу pack, будет выполнено размещение по умолчанию, когда виджет прикрепляется к верхнему краю контейнера.
Мы неоднократно будем возвращаться к менеджеру компоновки в этой главе и использовать его во многих примерах книги. В главе 9 мы также познакомимся с альтернативным менеджером компоновки grid и системой размещения виджетов в контейнере в табличном виде (то есть по строкам и колонкам). Третий вариант, менеджер компоновки placer, описывается в документации Tk и не описывается в данной книге - он менее популярен, чем менеджеры pack и grid, и его использование может оказаться непростым делом при создании крупных графических интерфейсов.
Запуск программ с графическим интерфейсом
Как и любой другой программный код на языке Python, модуль из примера 7.1 может быть запущен несколькими способами: путем запуска как самостоятельного сценария:
C:\...\PP4E\Gui\Intro> python gui1.py
с помощью операции импортирования из интерактивного сеанса Python или из другого файла модуля:
>>> import gui1
путем запуска его, как выполняемого файла Unix, если добавить в начало файла особую строку, начинающуюся с #!:
% gui1.py &
или любым другим способом, которым программы Python могут быть запущены на вашей платформе. Например, этот сценарий можно также запустить щелчком мыши на имени файла в проводнике Windows, или его код может быть введен в интерактивной оболочке, в ответ на приглашение >>>.33 Можно даже выполнить его из программы на языке C, вызвав соответствующую функцию прикладного интерфейса встраивания (подробности об интеграции с программами на языке C можно найти в главе 20).
Иными словами, практически нет специальных правил, которым требуется следовать, чтобы запустить графический интерфейс, реализованный на языке Python. Интерфейс tkinter (и сама библиотека Tk) связан с интерпретатором Python. Когда программа на языке Python вызывает функции GUI, они просто за кулисами передаются встроенной графической подсистеме. Это облегчает написание инструментов командной строки, которые вызывают появление всплывающих окон, -они выполняются так же, как обычные текстовые сценарии, которые изучались в предыдущей части книги.
Как избежать появления окна консоли DOS в Windows
В главах 3 и 6 отмечалось, что если имя программы имеет расширение .pyw, а не .py, запуск сценария Python в Windows не вызывает появления окна консоли DOS, которое обслуживает стандартные потоки ввода-вывода сценария, запускаемого щелчком мыши на ярлыке. Теперь, когда мы наконец-то начали создавать собственные окна, этот прием с именем файла становится еще более полезным.
Чтобы видеть только окна, создаваемые сценарием, независимо от способа его запуска, дайте файлам своих сценариев с графическим интерфейсом расширение .pyw, если они будут выполняться в Windows. Например, щелчок на файле примера 7.2 в проводнике Windows создает только окно, изображенное на рис. 7.1.
Пример 7.2. PP4E\Gui\Intro\gui1.pyw ...то же, что gui1.py...
Избежать появления всплывающих окон DOS в Windows можно также, запуская программу с выполняемым файлом pythonw.exe вместо python.exe (в действительности файлы .pyw просто зарегистрированы для открытия посредством pythonw). В Linux расширение .pyw не мешает, но и не является необходимым - в Unix-подобных системах нет понятия всплывающих окон для подключения потоков ввода-вывода. С другой стороны, если в будущем потребуется выполнять ваши сценарии с графическим интерфейсом в Windows, добавление «w» в конце имени может освободить вас от необходимости каких-то дополнительных действий по переносу. В данной книге имена файлов .py иногда используются для вызова окон консоли, чтобы видеть сообщения, выводимые в Windows.
Альтернативные приемы использования tkinter
Как можно предполагать, есть разные способы реализации примера gui1. Например, если желательно более явным образом описать в сценарии импортируемые из tkinter элементы, импортируйте весь модуль и добавляйте имя модуля ко всем относящимся к нему именам, как в примере 7.3.
Пример 7.3. PP4E\Gui\Intro\gui1b.py - import против from
import tkinter
widget = tkinter.Label(None, text='Hello GUI world!’)
widget.pack()
widget.mainloop()
В действующих примерах это может быть утомительным - библиотека tkinter экспортирует десятки классов графических переменных и констант, которые повсюду встречаются в сценариях с графическим интерфейсом на языке Python. На самом деле обычно проще использовать спецификатор *, чтобы одним махом импортировать все, находящееся в модуле tkinter. Это показано в примере 7.4.
Пример 7.4. PP4E\Gui\Intro\gui1c.py - константы и функции вместе
from tkinter import * root = Tk()
Label(root, text=’Hello GUI world!’).pack(side=TOP) root.mainloop()
Модуль tkinter старается экспортировать только то, что действительно необходимо, поэтому он один из немногих, для которых формат импорта со спецификатором * можно применять относительно безопасно.34 К примеру, константа TOP в вызове функции pack является одной из многих, экспортируемых модулем tkinter. Это просто имя переменной (TOP="top"), которой заранее присвоено значение в модуле constants, автоматически загружаемом пакетом tkinter.
При размещении графических элементов можно указать, к какому краю родительского контейнера они должны быть прикреплены, - TOP, BOTTOM, LEFT или RIGHT. Если параметр side не передается функции pack (как в предшествующих примерах), виджет по умолчанию прикрепляется к верхнему краю (TOP). В целом, более крупные графические интерфейсы на базе tkinter могут конструироваться как набор прямоугольников, прикрепляемых к надлежащим сторонам других, охватывающих их прямоугольников. Как будет показано позднее, tkinter располагает графические элементы в прямоугольнике, в соответствии с очередностью их размещения и параметром side. Если виджеты располагаются по сетке, им присваиваются номера строк и колонок. Однако все это имеет смысл, только если в окне присутствует больше одного виджета, поэтому продолжим наши исследования.
Обратите внимание, что в этой версии метод pack вызывается сразу после создания метки, которая не присваивается никакой переменной. Если нет необходимости сохранять виджет, можно разместить его таким способом на месте, и этим сэкономить строку программного кода. Мы будем использовать этот прием, если графический элемент прикрепляется к более крупной структуре и нигде в программном коде больше не используется. Сложности могут возникнуть, если присваивать результат, возвращаемый pack, но объяснение этого откладывается до того времени, когда будут изучены еще некоторые основные понятия.
Мы также используем здесь в качестве родителя экземпляр класса Tk виджета вместо None. Объект Tk представляет главное («корневое») окно программы - которое открывается вместе с запуском программы. Автоматически созданный объект Tk используется также как родительский виджет по умолчанию, когда в вызовы других методов виджетов не передается никакого родителя или когда в качестве родителя передается None. Иными словами, по умолчанию виджеты просто прикрепляются к главному окну программы. В данном сценарии это поведение по умолчанию реализуется явно, путем создания и передачи самого объекта Tk. В главе 8 будет показано, как для создания новых всплывающих окон, действующих независимо от главного окна программы, используются виджеты Toplevel.
Некоторые методы виджетов в tkinter экспортируются также в виде функций, что позволяет сократить пример 7.5 до трех строчек кода.
Пример 7.5. PP4E\Gui\Intro\gui1d.py - минимальная версия
from tkinter import *
Label(text=’Hello GUI world!’).pack() mainloop()
Функцию mainloop из модуля tkinter можно вызывать относительно виджета или непосредственно (то есть как метод или как функцию). В этом варианте мы не передавали конструктору Label аргумент родителя: если он опущен, то по умолчанию будет использоваться значение None (что, в свою очередь, по умолчанию означает автоматически создаваемый объект Tk). Но использование этого значения по умолчанию становится менее удобным при создании более крупных графических интерфейсов. Такие элементы, как метки, чаще прикрепляются к другим контейнерам виджетов.
Основы изменения размеров виджетов
Размер окон верхнего уровня - таких как окно, создававшееся во всех продемонстрированных до сих пор вариантах, обычно может изменяться пользователем - нужно просто растянуть окно с помощью мыши. На рис. 7.2 показано, как выглядит увеличенное в размерах окно.
Это не очень хорошо - метка сохраняет положение у верхнего края родительского окна, вместо того чтобы оказаться в середине, но положение легко исправить с помощью пары параметров метода pack, как показано в примере 7.6.
Пример 7.6. PP4E\Gui\Intro\gui1e.py - растягивание окна
from tkinter import *
Label(text=’Hello GUI world!’).pack(expand=YES, fill=BOTH) mainloop()
Рис. 7.2. Увеличенное окно сценария gui1
При размещении виджетов можно указывать, должен ли виджет увеличиться в размерах, чтобы заполнить все свободное пространство, и если да, то как он должен измениться, чтобы заполнить все это пространство. По умолчанию виджеты не увеличиваются вслед за родителем. Но в данном сценарии имена YES и BOTH (импортированные из модуля tkinter) указывают, что метка должна увеличиваться вместе со своим родителем, то есть с главным окном. Так оно и происходит, как видно на рис. 7.3.
Рис. 7.3. Сценарий gui1e c виджетом, изменяющим размер
Технически, менеджер компоновки назначает размер каждому отображаемому виджету, исходя из его содержимого (длины текстовой строки и так далее). По умолчанию виджет может занимать только отведенное ему пространство и не может быть больше назначенного ему размера. Параметры expand и fill позволяют более точно определять правила автоматического изменения размеров:
Параметр expand=YES
Предлагает менеджеру компоновки выделять виджету все свободное пространство в родительском контейнере, не занятое другими виджетами.
Параметр fill
Может использоваться для растяжения виджета, чтобы он занял все выделенное ему пространство.
Сочетания этих двух параметров производят различные эффекты расположения и изменения размеров, при этом некоторые из них имеют смысл только при наличии в окне нескольких графических элементов. Например, использование параметра expand без fill приводит к размещению виджета в центре занимаемого им пространства, а параметр fill может определять возможность изменения размеров только по вертикали (fill=Y), только по горизонтали (fill=X) или по обеим осям одновременно (fill=BOTH). Определяя эти ограничения и стороны прикрепления для всех виджетов в графическом интерфейсе наряду с порядком размещения, можно довольно точно управлять их взаимным расположением. В последующих главах будет показано, что менеджер компоновки grid использует совершенно другой протокол изменения размеров, но при необходимости может обеспечивать похожий порядок размещения.
Впервые столкнувшись с этим, можно запутаться, и мы вернемся к этому позднее. Но если вы не уверены в том, какой результат будет иметь некоторая комбинация параметров expand и fill, просто попробуйте, что получится, - в конце концов, это Python. А пока запомните, что комбинация expand=YES и fill=BOTH встречается, вероятно, чаще всего и означает «изменить размеры отведенного мне места, чтобы оно занимало все свободное пространство, и растянуть меня так, чтобы заполнить освободившееся пространство во всех направлениях». Для нашего примера «Hello World» итоговым результатом будет рост метки при увеличении размеров окна, поэтому метка всегда остается в центре.
Настройка параметров графического элемента и заголовка окна
До сих пор мы сообщали библиотеке tkinter, что должно выводиться в метке, передавая ее текст в именованном аргументе при вызове конструктора метки. Оказывается, существует еще два способа определения параметров метки. В примере 7.7 параметр text метки определяется после ее создания путем присвоения ключу text виджета - виджеты перегружают операции индексирования, чтобы доступ к параметром можно было осуществлять по ключам, подобно словарям.
Пример 7.7. PP4E\Gui\Intro\gui1f.py - параметры
from tkinter import * widget = Label()
widget[‘text’] = ‘Hello GUI world!’ widget.pack(side=TOP)
mainloop()
Но чаще параметры виджетов устанавливаются после их создания путем вызова метода config, как в примере 7.8.
Пример 7.8. PP4E\Gui\Intro\gui1g.py - методы config и title
from tkinter import *
root = Tk()
widget = Label(root)
widget.config(text=’Hello GUI world!’)
widget.pack(side=TOP, expand=YES, fill=BOTH)
root.title(‘gui1g.py’)
root.mainloop()
Метод config (допускается также использовать его синоним configure) можно вызвать в любой момент после создания виджета, чтобы на лету изменить его внешний вид. Например, можно было бы вызвать метод config еще раз, дальше в сценарии, чтобы изменить текст, который выводится в метке. Примеры такого динамического изменения параметров можно найти в последующих примерах в этой части книги.
Обратите также внимание, что в этой версии вызывается метод root.ti-tle - этот метод устанавливает текст в заголовке окна, как показано на рис. 7.4. Вообще говоря, окна верхнего уровня, такие как виджет root типа Tk, в этом примере экспортируют интерфейсы менеджера окон, имеющие отношение к рамке окна, а не к его содержимому.
Рис. 7.4. Сценарий gui1g c виджетом, изменяющим размер, и заголовком окна
Развлечения ради в этой версии метка также центрируется при изменении размеров окна путем установки значений параметров expand и fill. На самом деле здесь почти все делается явно, и это отражает типичный способ создания меток в полноценных интерфейсах - с указанием родителя, политики автоматического изменения размеров и способа прикрепления, без использования значений по умолчанию.
Еще одна версия в память о былых временах
Наконец, если вы склонны к минимализму и испытываете ностальгию по старому стилю программирования на языке Python, сценарий «Hello World» можно записать, как показано в примере 7.9.
Пример 7.9. PP4E\Gui\Intro\gui1-old.py - использование словаря
from tkinter import *
Label(None, {‘text’: ‘Hello GUI world!’, Pack: {‘side’: ‘top’}}).mainloop()
В этом примере для создания окна хватило двух строк, хотя выглядит он ужасно! Эта схема основана на старом стиле программирования, широко использовавшемся до выхода версии Python 1.3, когда параметры настройки передавались не как именованные аргументы, а в виде словаря.35 В этой схеме параметры менеджера компоновки могут передаваться как значения по ключу Pack (имя класса в модуле tkinter).
Схема вызова с использованием словаря по-прежнему действует, и ее можно обнаружить в старых сценариях на языке Python, но лучше ею не пользоваться. Для передачи параметров применяйте в своих сценариях, использующих tkinter, именованные аргументы и явный вызов метода pack. Единственная причина, по которой я не выкинул этот пример, заключается в том, что словари все еще могут быть полезны, когда требуется динамически вычислить и передать набор параметров.
С другой стороны, теперь можно использовать синтаксическую конструкцию func(*pargs, **kargs), которая также позволяет передать явный словарь именованных аргументов в третьей позиции:
options = {‘text’: ‘Hello GUI world!’} layout = {‘side’: ‘top’}
Label(None, **options).pack(**layout) # ключи должны быть строками
Даже в динамических сценариях, где параметры виджетов определяются во время выполнения, нет веских причин использовать формат вызова со словарем, который использовался с версиями, предшествовавшими tkinter 1.3.
Добавление виджетов без их сохранения
В сценарии gui1c.py из примера 7.4 я начал добавлять метки, не сохраняя их в переменных. Этот прием действует и является совершенно допустимым, но поскольку при первом взгляде такой программный код может смутить начинающих программистов, необходимо более подробно объяснить здесь, почему он работает.
В tkinter объекты классов Python соответствуют объектам, выводимым на экран, - мы заставляем объект Python создать объект на экране и вызываем методы объекта Python, чтобы настроить этот экранный объект. Благодаря такому соответствию срок жизни объекта Python должен в целом соответствовать сроку жизни соответствующего ему объекта на экране.
К счастью, сценариям на языке Python обычно не требуется беспокоиться о времени жизни объекта. Обычно они вообще не обязаны сохранять ссылки на создаваемые объекты виджетов, если только не собираются в дальнейшем изменять параметры настройки этих объектов. Например, при программировании с использованием tkinter часто сразу же после создания виджет размещают в интерфейсе, если в дальнейшем ссылка на него не понадобится:
Label(text=’hi’).pack() # ОК
Эта инструкция выполняется как обычно, слева направо. Она сначала создает новую метку и затем немедленно вызывает метод pack нового объекта, чтобы установить его расположение при отображении на экране. Обратите, однако, внимание, что в этом выражении объект Label является временным: так как он не присваивается переменной, в обычной ситуации он должен был бы быть утилизирован сборщиком мусора сразу после выполнения метода pack.
Однако поскольку при создании объектов библиотека tkinter обращается к библиотеке Tk, метка будет нарисована на экране, как положено, несмотря на то, что мы не сохранили в своем сценарии ссылку на соответствующий объект Python. В действительности внутри tkinter объекты виджетов связываются в долгоживущее дерево, которое используется для представления интерфейса, отображаемого на экране, поэтому ссылка на объект Label, созданный этой инструкцией, сохраняется, хотя и не внутри нашего сценария.36
Иными словами, сценариям обычно не нужно беспокоиться о сроке жизни объектов виджетов, и вполне допустимо создавать виджеты и сразу же размещать их одной и той же инструкцией, не сохраняя ссылки на них в переменных.
Но это не значит, что можно писать такой код:
widget = Label(text=’hi’).pack() # неверно!
...использование графического элемента...
На первый взгляд, эта инструкция должна присвоить только что размещенную в интерфейсе метку переменной widget, но это не так. На самом деле это известная ошибка новичков в tkinter. Метод pack размещает виджет, но не возвращает его. Метод pack возвращает объект None - после этой операции переменная widget будет хранить ссылку на None и все дальнейшие операции с виджетом, использующие эту переменную, окажутся безуспешными. Например, по той же причине следующая команда потерпит неудачу:
Label(text=’hi’).pack().mainloop() # неверно!
Метод pack возвращает None, поэтому попытка обратиться к его атрибуту mainloop возбудит исключение (как и должно быть). Если вы действительно хотите разместить виджет и сохранить ссылку на него, используйте такой способ:
widget = Label(text=’hi’) # тоже правильно
widget.pack()
...использование графического элемента...
Такой способ несколько многословнее, но он более надежен, чем размещение виджета в той же инструкции, которая его создает, и позволяет сохранить ссылку на виджет для последующих операций с ним. Кроме того, такой способ чаще используется на практике при создании более сложных конфигураций и схем размещения виджетов.
С другой стороны, сценарии, занимающиеся компоновкой внешнего вида, часто добавляют виджеты, размещая их раз и навсегда и не нуждаясь в последующей их настройке, - сохранение долгоживущих ссылок в такой программе не имеет смысла и является необязательным.
В главе 8 мы встретимся с двумя исключениями из этого правила. Сценарии должны вручную получать ссылки на объекты изображений, потому что фактические данные, составляющие изображение, будут уничтожены, как только сборщик мусора в Python утилизирует объект изображения. Объекты класса Variable из библиотеки tkinter также временно сбрасывают связанные с ними переменные из библиотеки Tk при утилизации, но это случается редко и не так опасно.
Добавление кнопок и обработчиков
Пока мы научились только выводить текст в метках и попутно познакомились с базовыми понятиями tkinter. Метки хороши для обучения основам, но от пользовательских интерфейсов обычно требуется нечто большее - способность реагировать на действия пользователя. Эту способность демонстрирует программа из примера 7.10, которая создает окно, изображенное на рис. 7.5.
Пример 7-10. PP4E\Gui\Intrd\gui2.py
import sys
from tkinter import *
widget = Button(None, text=’Hello widget world’, command=sys.exit)
widget.pack()
widget.mainloop()
Рис. 7.5. Кнопка вверху
Здесь мы создаем вместо метки экземпляр класса Button. Как и прежде, он прикрепляется по умолчанию к верхнему краю TOP окна верхнего уровня. Но главное, на что нужно обратить внимание, это аргументы с параметрами кнопки: в качестве значения параметра с именем command используется функция sys.exit.
В кнопках параметр command определяет функцию обратного вызова, которая должна вызываться в дальнейшем при нажатии кнопки. Фактически с помощью параметра command регистрируется действие, которое должна вызвать библиотека tkinter, когда в виджете произойдет событие. Функция обратного вызова, использованная здесь, не представляет большого интереса: как мы узнали в главе 5, встроенная функция sys. exit просто прекращает выполнение вызвавшей ее программы. В данном случае это означает, что при нажатии на эту кнопку окно исчезнет.
Так же как и в случае с метками, есть разные способы создания кнопок. Пример 7.11 является версией, в которой кнопка размещается в интерфейсе немедленно, без сохранения ссылки на нее в переменной. Она явно прикрепляется к левому краю родительского окна, и в качестве обработчика для нее определяется root.quit - стандартный метод объекта Tk, закрывающий главное окно и тем самым завершающий программу. В действительности метод quit завершает выполнение функции mainloop цикла событий и всей программы в целом - когда мы начнем использовать сразу несколько окон верхнего уровня в главе 8, мы узнаем, что метод quit обычно закрывает все окна, а родственный ему метод destroy закрывает только одно окно.
Пример 7.11. PP4E\Gui\Intro\gui2b.py
from tkinter import * root = Tk()
Button(root, text=’press’, command=root.quit).pack(side=LEFT) root.mainloop()
Эта версия создает окно, изображенное на рис. 7.6. Мы не потребовали от кнопки, чтобы она автоматически изменяла свои размеры и занимала все свободное пространство, - она этого и не делает.
Рис. 7.6. Кнопка слева
В двух последних примерах нажатие на кнопку завершает выполнение программы. В более старых сценариях, использующих tkinter, иногда можно увидеть, как параметру command присваивается строка exit, что также вызывает закрытие окна при нажатии на кнопку. В этом случае используется инструмент, имеющийся в библиотеке Tk, но такой прием менее характерен для Python, чем sys.exit или root.quit.
Еще раз об изменении размеров виджетов: растягивание
Даже для такого простого интерфейса есть множество способов определить его внешний вид с помощью основанного на ограничениях менеджера компоновки pack. Например, чтобы поместить кнопку в центре окна, добавьте в вызов метода pack параметр expand=YES в примере 7.11, как показано ниже:
Button(root, text=’press’, command=root.quit).pack(side=LEFT, expand=YES)
В этом случае менеджер компоновки отдаст кнопке все свободное пространство, но не растянет ее. В результате получится окно, как на рис. 7.7.
Рис. 7.7. pack(side=LEFT, expand=YES)
Если необходимо, чтобы кнопке было отдано все свободное пространство и она была растянута по горизонтали, добавьте в вызов pack именованные аргументы expand=YES и fill=X. В результате получится то, что изображено на рис. 7.8.
Рис. 7.8. pack(side=LEFT, expand=YES, fill=X)
Кнопка первоначально займет все окно (выделенное ей место расширено, а сама она растянута, чтобы заполнить выделенное пространство). При этом кнопка будет растягиваться с увеличением размеров родительского окна. Как показано на рис. 7.9, кнопка в этом окне будет растягиваться при растягивании родителя, но только по горизонтальной оси X.
Рис. 7.9. Изменение размера при expand=YES, fill=X
Чтобы кнопка растягивалась в обоих направлениях, укажите в вызове pack параметры expand=YES и fill=BOTH - теперь при изменении размеров окна кнопка будет растягиваться во все стороны, как показано на рис. 7.10. Если раскрыть окно на весь экран, получится одна очень большая кнопка tkinter.
Рис. 7.10. Изменение размера при expand=YES, fill=BOTH
В более сложных интерфейсах такая кнопка будет растягиваться, только когда автоматическое изменение размеров задано для всех содержащих ее виджетов. Здесь единственным родителем кнопки является корневое окно Tk программы, поэтому вопрос об автоматическом изменении размеров родителя пока не стоит - в последующих сценариях нам потребуется также делать автоматически расширяемыми объемлющие виджеты Frame. Мы еще вернемся к менеджеру компоновки, когда встретимся с интерфейсами, содержащими несколько виджетов, и еще раз -когда будем изучать альтернативную функцию grid в главе 9.
Добавление пользовательских обработчиков
В простых примерах с кнопкой из предыдущего раздела обработчиком событий служила уже существующая функция, завершающая программу. Однако ничуть не сложнее зарегистрировать собственный обработчик, который выполняет что-нибудь более полезное. В примере 7.12 определяется собственный обработчик обратного вызова на языке Python.
Пример 7.12. PP4E\Gui\Intro\gui3.py
import sys
from tkinter import *
def quit(): # собственный обработчик событий
print(‘Hello, I must be going...’)
sys.exit() # закрыть окно и завершить процесс
widget = Button(None, text=’Hello event world’, command=quit)
widget.pack()
widget.mainloop()
Окно, создаваемое этим сценарием, изображено на рис. 7.11. Этот сценарий и воспроизводимый им графический интерфейс почти совпадают с предыдущим примером. Но здесь в параметре command передается функция, которая определена локально. При нажатии кнопки библиотека tkinter вызовет для обработки события функцию quit в этом файле. Внутри quit вызов функции print выведет сообщение в поток stdout программы, и процесс завершится, как ранее.
Рис. 7.11. Кнопка, нажатие на которую вызывает функцию Python
Как обычно, роль потока вывода stdout играет окно, из которого была запущена программа, если только он не был перенаправлен в файл.
Это будет всплывающее окно консоли DOS, если запустить программу щелчком на файле в Windows; добавьте вызов input перед sys.exit, если всплывающее окно исчезает прежде чем удается посмотреть сообщение. Ниже показано, как выглядит вывод в стандартный поток вывода при нажатии кнопки - он генерируется функцией на языке Python, которую автоматически вызывает библиотека tkinter:
C:\...\PP4E\Gui\Intro> python gui3.py
Hello, I must be going...
C:\...\PP4E\Gui\Intro>
Обычно такие сообщения должны выводиться в графическом интерфейсе, но мы еще не добрались до того, как это сделать. Конечно, функции обратного вызова обычно выполняют больше действий (и могут даже вызывать появление новых независимых окон), но основы их использования продемонстрированы в данном примере.
Вообще говоря, обработчиками событий могут быть любые вызываемые объекты - функции; анонимные функции, создаваемые с помощью lambda-выражений; связанные методы классов или экземпляров типов или экземпляры классов, наследующие метод перегрузки оператора
__call__. Обработчики нажатия кнопки Button не получают никаких
аргументов (кроме self, который автоматически передается связанным методам) - любые данные, необходимые обработчику события, должны быть доступны другими способами: в виде глобальных переменных, атрибутов экземпляра класса, дополнительных аргументов, передаваемых косвенным путем, и так далее.
lambda-выражения как обработчики событий
Напомню, что lambda-выражения в языке Python при выполнении генерируют новые объекты анонимных функций. Если необходимо, чтобы в функцию обработчика передавались дополнительные данные, можно зарегистрировать lambda-выражение, откладывающее вызов фактической функции, и определить в нем необходимые дополнительные данные.
Как этим воспользоваться, будет показано далее в этой части книги, но для иллюстрации основных идей в примере 7.13 демонстрируется, как будет выглядеть приложение 7.12, если задействовать в нем инструкцию lambda вместо def.
Пример 7.13. PP4E\Gui\Intro\gui3b.py
import sys
from tkinter import * # lambda-выражение генерирует функцию
widget = Button(None, # но содержит всего лишь выражение
text=’Hello event world’,
command=(lambda: print(‘Hello lambda world’) or sys.exit()) )
widget.pack()
widget.mainloop()
В этом примере есть небольшая хитрость: lambda-выражения могут содержать только одно выражение, поэтому здесь используется оператор or, чтобы заставить выполниться два выражения (функция print вызывается первой, а поскольку в Python 3.X она стала функцией, нам не требуется использовать sys.stdout непосредственно).
Отложенные вызовы с применением инструкций lambda и ссылок на объекты
Очень часто lambda-выражения используются для передачи дополнительных данных в обработчик события (для простоты я опустил вызовы функций pack и mainloop в следующем фрагменте):
def handler(A, B): # обычно вызывается без аргументов ...использование A и B...
X = 42
Button(text='ni', command=(lambda: handler(X, 'spam'))) # lambda добавляет
# аргументы
Библиотека tkinter вызывает обработчики command, не передавая им никаких аргументов, тем не менее с помощью такого lambda-выражения можно создать косвенную анонимную функцию, которая будет играть роль оболочки для действительного обработчика и передавать ему информацию, существовавшую в момент создания графического интерфейса. Вызов фактического обработчика откладывается, благодаря чему мы получаем возможность добавлять необходимые аргументы. В данном случае значение глобальной переменной X и строка “spam” будут переданы в аргументах A и B даже при том, что библиотека tkinter вызывает функции обратного вызова без аргументов. Таким образом, инструкция lambda может использоваться для отображения вызова без аргументов в вызов с аргументами, которые поставляются самим lambda-выражением.
Если такой синтаксис приводит вас в замешательство, запомните, что такое lambda-выражение, как показано выше, обычно может быть реализовано в виде простой инструкции def. Вторая функция в следующем фрагменте выполняет ту же операцию, что и lambda-выражение в предыдущем фрагменте, - ссылка на нее в операции создания кнопки фактически откладывает вызов действительного обработчика, чтобы ему можно было передать дополнительные аргументы:
def handler(A, B): # обычно вызывается без аргументов ...использование A и B...
X = 42
def func(): # косвенная функция-обертка, добавляющая аргументы handler(X, 'spam')
Button(text='ni', command=func)
Чтобы более отчетливо понять, зачем необходимы отложенные вызовы, обратите внимание, что произойдет, если в операцию создания кнопки вставить вызов самого обработчика с аргументами без использования lambda-выражения или другой промежуточной функции, - обработчик будет вызван немедленно, в момент создания кнопки, а не когда на ней будет выполнен щелчок. Именно для того чтобы отложить вызов обработчика, обращение к нему требуется обернуть промежуточной функцией:
def handler(name): print(name)
Button(command=handler(‘spam’)) # ОШИБКА: обработчик будет вызван немедленно!
Использование lambda-выражений или ссылок на вызываемые объекты позволяет отложить вызов обработчика до появления события. Например, использование lambda-выражения для передачи дополнительных данных с помощью определения встроенной функции, вызов которой откладывается:
def handler(name): print(name)
Button(command=(lambda: handler(‘spam’))) # OK: обертывание lambda-выражением
# откладывает вызов
всегда эквивалентно более длинной и, по мнению некоторых, менее удобной форме с двумя функциями:
def handler(name): print(name)
def temp():
handler(‘spam’)
Button(command=temp) # OK: ссылка на функцию, а не ее вызов
Нам достаточно применять только какой-то один прием - либо lambda-выражение без аргументов, либо ссылку на вызываемый объект, не принимающий аргументов, но не оба сразу. Бессмысленно использовать lambda-выражение, просто вызывающее функцию, которая не принимает дополнительных аргументов, так как в этом случае будет выполняться один лишний вызов:
def handler(name): print(name)
def temp():
handler(‘spam’)
Button(command=(lambda: temp())) # БЕССМЫСЛЕННО: добавляет лишний вызов!
Как будет показано далее, допускается также использовать ссылки на другие вызываемые объекты, такие как связанные методы и вызываемые экземпляры классов, которые сохраняют необходимую информацию в своих атрибутах. Если они не принимают аргументов, их имена можно просто указывать на этапе создания виджетов и их не требуется обертывать лишними lambda-выражениями.
Проблемы с областями видимости обработчиков
Использование lambda-выражения или промежуточной функции позволяет отложить вызов обработчика и передать ему дополнительные аргументы, тем не менее эти приемы влекут за собой некоторые проблемы, связанные с областью видимости, незаметные на первый взгляд. Это сфера базовых особенностей языка, но данные проблемы довольно часто встречаются на практике при создании графических интерфейсов.
Аргументы и глобальные переменные
Например, обратите внимание, что первая версия обработчика из предыдущего раздела сама могла бы обратиться к переменной X непосредственно, так как она является глобальной (и будет определена к моменту, когда будет вызван обработчик). Благодаря этому мы могли бы написать обработчик, принимающий единственный аргумент, и передавать ему в lambda-выражении только строку ‘spam’:
def handler(A): # X находится в глобальной области видимости
...использование глобальной переменной X и аргумента A...
X = 42
Button(text=’ni’, command=(lambda: handler('spam')))
Аргумент A также можно было бы перенести в глобальную область видимости, чтобы полностью устранить необходимость использования lambda-выражения; в этом случае мы сможем регистрировать сам обработчик и убрать промежуточную функцию.
Несмотря на всю простоту этого тривиального примера, на практике предпочтительнее использовать аргументы, а не глобальные переменные, потому что они делают внешние зависимости более очевидными, благодаря чему программный код проще будет понять и изменить. Один и тот же обработчик мог бы использоваться и в других контекстах, если не привязывать его к глобальным переменным. Пока мы не приступили к изучению крупных примеров, предъявляющих более сложные требования к сохранению информации о состоянии, вам придется принять на веру, что отказ от использования глобальных переменных в функциях обратного вызова и в графическом интерфейсе в целом, делает их более доступными для повторного использования и обеспечивает поддержку нескольких экземпляров в одной и той же программе. Причем такой подход рекомендутся применять не только в графических интерфейсах.
Передача значений из объемлющей области видимости с помощью аргументов со значениями по умолчанию
Еще более тонкая проблема: обратите внимание, что если создание кнопки в этом примере будет выполняться внутри функции, а не на верхнем уровне сценария, имя X перестанет быть глобальным и окажется в локальной области видимости объемлющей функции. Может создаться ощущение, что переменная X исчезнет сразу после выхода из функции, еще до того, как возникнет событие, которое вызовет выполнение lambda-выражения:
def handler(A, B):
...использование A и B...
def makegui():
X = 42
Button(text=’ni’, command=(lambda: handler(X, ‘spam’))) # запоминает X
makegui()
mainloop() # в этой точке область видимости функции makegui прекратила # существование
К счастью, модель ссылок в объемлющую область видимости, реализованная в Python, автоматически сохранит значение X, находящееся в локальной области видимости объемлющей функции, где используется lambda-выражение, и обеспечит его доступность в обработчике, когда он будет вызван по событию нажатия кнопки. Обычно этот прием действует именно так, как нам хотелось бы, и автоматически обслуживает подобные ссылки на переменные.
Однако такое использование объемлющей области видимости можно сделать более явным, применив аргументы со значениями по умолчанию, которые также сохраняют значения переменных из локальной области видимости объемлющей функции после выхода из нее. Например, в следующем фрагменте аргумент с именем X (слева в выражении X=X) сохранит объект 42, потому что переменная с именем X (справа в выражении X=X) используется не только в объемлющей области видимости, но и в сгенерированной функции, которая позднее будет вызываться без аргументов:
def handler(A, B): # аргументы со значениями по умолчанию обеспечивают
...использование A и B... # сохранение информации о состоянии
def makegui():
X = 42
Button(text=’ni’, command=(lambda X=X: handler(X, 'spam')))
Так как значения по умолчанию аргументов вычисляются и сохраняются на этапе выполнения инструкции lambda (а не на этапе вызова функции, сгенерированной этой инструкцией), они обеспечивают явный способ сохранения объектов, доступ к которым будет осуществляться уже в процессе обработки события. Позднее библиотека вызовет lambda-функцию без аргументов, поэтому все ее аргументы получат значения по умолчанию.
В оригинальной версии этого примера не было никаких проблем, потому что переменная X находилась в глобальной области видимости и потому была доступна функции, сгенерированной lambda-выражением. Однако при использовании внутри функции переменная X может исчезнуть после выхода из объемлющей функции.
Передача значений из объемлющей области видимости с помощью автоматических ссылок
Аргументы со значениями по умолчанию способны более четко обозначить внешние зависимости, тем не менее можно обойтись и без них (начиная с версии Python 2.2, по крайней мере), и в современной практике они обычно не используются для этих целей. Вместо этого просто создается lambda-выражение, которое откладывает вызов действительного обработчика и передает ему дополнительные аргументы. Переменные из объемлющей области видимости, используемые в lambda-выражении, автоматически сохраняются даже после выхода из объемлющей функции.
Предыдущий фрагмент, например, в наши дни можно записать, как мы уже делали это выше - имя X в обработчике автоматически будет отображено в переменную X из объемлющей области видимости, что фактически приводит к сохранению значения, которое имела переменная X на момент создания кнопки:
def makegui(): # X запоминается
X = 42 # автоматически
Button(text=’ni’, command=(lambda: handler(X, 'spam'))) # аргументы по
# умолчанию не
# нужны
Далее мы увидим более конкретные примеры использования этого приема. При использовании классов для создания графического интерфейса, например, аргумент self является для методов локальной переменной и потому автоматически становится доступным в теле lambda-выражения. Нет никакой необходимости передавать его явно, в виде аргумента со значением по умолчанию:
class Gui:
def handler(self, A, B):
...использование self, A и B...
def makegui(self):
X = 42
Button(text=’ni’, command=(lambda: self.handler(X, 'spam')))
Gui().makegui()
mainloop()
Однако при использовании классов в качестве источника дополнительной информации для функций обратного вызова можно использовать атрибуты экземпляров и отказаться от дополнительных аргументов. Как это делается, мы увидим чуть ниже. Но сначала нам следует отклониться от темы и рассмотреть правила областей видимости в Python, чтобы понять, почему аргументы со значениями по умолчанию иногда все же бывают необходимы для передачи значений во вложенные lambda-функции, особенно в графических интерфейсах.
Но иногда вместо объемлющих областей видимости
все же необходимо использовать аргументы со значениями
по умолчанию
В давно написанных сценариях Python все еще можно увидеть, как аргументы со значениями по умолчанию используются для передачи ссылок в объемлющую область видимости, но в настоящее время предпочтение отдается приему автоматического получения ссылок. Может сложиться впечатление, что новые правила поиска во вложенных областях видимости, реализованные в Python, автоматизируют и делают ненужной ручную операцию передачи значений из объемлющей области видимости в виде аргументов со значениями по умолчанию.
Все это так, но не совсем. Есть одна особенность. Оказывается, что внутри lambda-выражения (или внутри инструкции def) ссылки на переменные в объемлющей области видимости разрешаются в момент вызова сгенерированной функции, а не в момент ее создания. Вследствие этого, когда функция будет вызвана позднее, такие ссылки будут отражать последние значения переменных, присвоенные им где бы то ни было в объемлющей области видимости, которые не обязательно будут совпадать со значениями, присвоенными переменным на момент создания функции. Это справедливо не только для вложенных функций обратного вызова, но и для находящихся в глобальной области видимости модуля. В любом случае, все ссылки на переменные в объемлющей области видимости разрешаются в момент вызова функции, а не в момент ее создания.
Аргументы со значениями по умолчанию отличаются тем, что их значения определяются в момент создания функции, а не в момент ее вызова. Вследствие этого они по-прежнему могут быть полезным способом сохранения значений переменных из объемлющей области видимости, имевших место на момент создания функции. В отличие от ссылок на переменные в объемлющей области видимости, аргументы со значениями по умолчанию не получат другое значение, даже если переменная в объемлющей области видимости изменится между моментами создания и вызова функции. (Фактически именно этим объясняется, почему изменяемые объекты, такие как списки, передаваемые по умолчанию, сохраняются между вызовами - они создаются только один раз, в момент создания функции, и присоединяются к самой функции.)
Обычно это отличие не вызывает проблем, потому что в большинстве случаев используются ссылки на переменные в объемлющей области видимости, значения которым присваиваются только один раз (примером может служить аргумент self в методах классов). Но при непонимании этого отличия можно допустить программные ошибки, особенно если функции создаются в цикле, - при использовании в этих функциях ссылок на переменную цикла все они будут получать значение, полученное в последней итерации. Напротив, при использовании значений по умолчанию каждая функция будет получать текущее значение переменной цикла, а не последнее.
Из-за этого отличия одних только ссылок на переменные в объемлющей области видимости может оказаться недостаточно для сохранения значений, и аргументы со значениями по умолчанию все еще могут оказаться востребованными. Посмотрим, что это означает с точки зрения программного кода. Взгляните на следующую вложенную функцию (фрагменты программного кода для этого раздела вы найдете в файле defaults.py в дереве примеров на случай, если у вас появится желание поэкспериментировать с ними).
def simple(): spam = ‘ni’ def action():
print(spam) # ссылка на переменную в объемлющей функции return action
act = simple() # создать и вернуть вложенную функцию
act() # затем вызвать ее: выведет ‘ni’
Это простейший случай ссылки на переменную в объемлющей области видимости, и он одинаково действует для вложенных функций, сгенерированных с помощью инструкций def и lambda. Но обратите внимание, что он будет действовать точно так же, если значение переменной spam будет присвоено после определения вложенной функции:
def normal(): def action():
return spam # поиск переменной будет выполняться в момент вызова spam = ‘ni’
return action
act = normal()
print(act()) # также выведет ‘ni’
Из этого примера следует, что разрешение имен в объемлющей области видимости не выполняется в момент создания вложенной функции -фактически в этот момент переменная вообще не была определена. Разрешение имени выполняется в момент вызова вложенной функции. То же справедливо и для lambda-выражений:
def weird(): spam = 42
return (lambda: spam * 2) # запомнит ссылку на spam в объемлющей # области видимости
act = weird()
print(act()) # выведет 84
Пока все неплохо. Ссылка на переменную spam внутри вложенной lambda-функции сохраняет значение, полученное переменной в объемлющей области видимости, которое остается доступным даже после выхода из объемлющей функции. Этот пример соответствует зарегистрированному обработчику в графическом интерфейсе, который будет вызываться позднее, по событиям. И снова ссылка из вложенной области видимости разрешается не в тот момент, когда в lambda-выражение создает функцию, а когда сгенерированная функция будет вызвана. Следующий фрагмент более наглядно демонстрирует действие этого правила:
def weird():
tmp = (lambda: spam * 2) # запоминает ссылку на spam, даже при том, spam = 42 # что здесь она еще не установлена
return tmp
act = weird()
print(act()) # выведет 84
Здесь вложенная функция ссылается на переменную, которой на момент создания функции еще не было присвоено значение. Действительно, при каждом вызове вложенной функции ссылки в объемлющую область видимости возвращают последние значения, присвоенные переменным. Взгляните, что происходит в следующем фрагменте:
def weird(): spam = 42
handler = (lambda: spam * 2) # функция не сохраняет текущее значение 42 spam = 50
print(handler()) # выведет 100: поиск spam выполняется именно сейчас spam = 60
print(handler()) # выведет 120: поиск spam снова выполняется именно сейчас
weird()
Теперь значение ссылки на spam внутри lambda-функции изменяется при каждом вызове сгенерированной функции! Фактически ссылка на переменную возвращает последнее значение, присвоенное в объемлющей области видимости на момент вызова вложенной функции, потому что ссылки разрешаются в момент вызова функции, а не в момент ее создания.
С точки зрения графических интерфейсов, это становится существенным чаще всего, когда функции обработчиков генерируются в циклах и при этом используются ссылки в объемлющую область видимости для сохранения дополнительных данных, создаваемых внутри циклов. Если вы собираетесь генерировать функции внутри цикла, вы должны учитывать, что продемонстрированные выше особенности поведения применяются и к переменной цикла:
def odd(): funcs = [] for c in ‘abcdefg’:
funcs.append((lambda: c)) # поиск переменной c будет выполнен позднее return funcs # не сохраняет текущее значение c
for func in odd():
print(func(), end=’ ‘) # Опа!: выведет 7 символов g, а не a,b,c,... !
Здесь список func имитирует зарегистрированные обработчики событий графического интерфейса, подключенные к виджетам. Этот пример работает совсем не так, как могли бы ожидать многие из вас. Переменная c внутри вложенной функции здесь всегда будет иметь значение 'g', то есть значение, установленное последней итерацией цикла в объемлющей области видимости. В результате все семь сгенерированных lambda-функций будут получать при вызове одно и то же значение.
Аналогичная реализация использования дополнительных данных в lambda-функциях, вызывающих действительные обработчики графического интерфейса, будет испытывать похожие проблемы. Например, все обработчики событий от кнопок, созданных в цикле, могут в конечном итоге давать один и тот же результат! Чтобы исправить положение, необходимо передавать значения вложенным функциям в виде значений аргументов по умолчанию, которые сохраняют текущее значение переменной цикла (а не то, которое будет в будущем):
def odd(): funcs = [] for c in ‘abcdefg’:
funcs.append((lambda c=c: c)) # запомнить текущее значение c return funcs # значения по умолчанию вычисляются
# немедленно
for func in odd():
print(func(), end=’ ‘) # OK: теперь выведет a,b,c,...
Теперь мы получили ожидаемый результат благодаря тому что значения по умолчанию, в отличие от ссылок во внешнюю область видимости, вычисляются в момент создания функции, а не в момент ее вызова. При таком подходе сохраняется значение, которое переменная в объемлющей области видимости имела на момент создания функции, а не последнее, присвоенное ей значение. То же правило действует, даже если объемлющей областью видимости для функции является модуль, а не какая-то другая функция - если в следующем фрагменте не использовать аргумент со значением по умолчанию, при обращении к переменной цикла все семь функций получат одно и то же значение:
funcs = [] # объемлющая область видимости - модуль
for c in ‘abcdefg’: # запомнить текущее значение c,
funcs.append((lambda c=c: c)) # иначе снова выведет 7 символов g
for func in funcs:
print(func(), end=’ ‘) # OK: выведет a,b,c,...
Из всего вышеизложенного следует вывод, что ссылка на переменную в объемлющей области видимости может служить заменой передачи данных в виде аргумента со значением по умолчанию, но только при условии, что эта переменная не получит новое значение, которое вам не нужно, после создания вложенной функции. Вы вообще не должны использовать внутри вложенных функций ссылки на переменные циклов в объемлющей области видимости, потому что они изменяются в процессе выполнения цикла. Однако в большинстве других случаев переменные в объемлющей области видимости могут принимать только одно значение, поэтому ссылки на них можно использовать без опаски.
Мы еще будем сталкиваться с этим явлением в последующих примерах, создающих более сложные графические интерфейсы. А пока запомните, что ссылки в объемлющую область видимости не могут служить полной заменой аргументов со значениями по умолчанию - в некоторых ситуациях значения по умолчанию незаменимы для передачи значений функциям обратного вызова. Кроме того, имейте в виду, что зачастую классы обеспечивают более простой способ сохранения информации для использования в обработчиках, чем вложенные функции. Поскольку информация в классах сохраняется более явным способом, им не свойственны описанные проблемы областей видимости. Следующие два раздела детально рассказывают об использовании классов.
Связанные методы как обработчики событий
Вернемся к теме программирования графических интерфейсов. Во многих случаях вполне можно ограничиться функциями и lambda-выражениями, однако связанные методы класса тоже прекрасно справляются с ролью обработчиков событий в графических интерфейсах - они запоминают не только экземпляр, которому было послано событие, но и связанный с ним метод, который должен быть вызван. Рассмотрим пример 7.14, где приводится переработанная версия примеров 7.12 и 7.13, регистрирующая связанный метод класса вместо функции или результата lambda-выражения.
Пример 7.14. PP4E\Gui\Intro\gui3c.py
import sys
from tkinter import *
class HelloClass:
def __init__(self):
widget = Button(None, text='Hello event world’, command=self.quit) widget.pack()
def quit(self):
print(‘Hello class method world’) # self.quit - связанный метод sys.exit() # хранит пару self+quit
HelloClass()
mainloop()
При нажатии кнопки библиотека tkinter вызовет метод q u it этого класса как обычно, без аргументов. Но в действительности он получит один аргумент - оригинальный объект self - хотя tkinter не передает его явно. Поскольку связанный метод self.quit хранит обе ссылки, self и quit, он совместим с вызовом простой функции - интерпретатор Python автоматически передаст аргумент self функции метода. Напротив, регистрация несвязанного метода экземпляра в виде HelloClass.quit работать не станет, потому что в этом случае не будет объекта self, который можно передать потом при возникновении события.
Позднее мы увидим, что приемы использования классов в качестве обработчиков событий также предоставляют естественное место для сохранения данных, используемых при возникновении событий, - достаточно просто присвоить их атрибутам экземпляра self:
class someGuiClass:
def __init__(self):
self.X = 42 self.Y = ‘spam’
Button(text=’Hi’, command=self.handler)
def handler(self):
...использование self.X, self.Y...
Поскольку событие будет отправлено методу этого класса со ссылкой на оригинальный объект экземпляра, аргумент self позволит обращаться к атрибутам, содержащим исходные данные. В действительности атрибуты экземпляра сохраняют информацию для использования в процессе обработки события. Этот прием обеспечивает большую гибкость, чем глобальные переменные или дополнительные аргументы, добавляемые с помощью lambda-выражений, особенно заметную в больших графических интерфейсах.
Объекты вызываемых классов как обработчики событий
Поскольку объекты экземпляров классов в языке Python могут вызываться как функции, если они наследуют метод__call__для перехвата
этой операции, их также можно использовать в качестве обработчиков событий. В примере 7.15 демонстрируется класс, реализующий необходимый интерфейс.
Пример 7.15. PP4E\Gui\Intro\gui3d.py
import sys
from tkinter import * class HelloCallable:
def __init__(self): # __init__ вызывается при создании объекта
self.msg = ‘Hello __call__ world’
def __call__(self):
print(self.msg) # __call__ вызывается при попытке обратиться
sys.exit() # к объекту класса как к функции
widget = Button(None, text=’Hello event world’, command=HelloCallable())
widget.pack()
widget.mainloop()
Здесь экземпляр класса HelloCallable, зарегистрированный в command, тоже может вызываться как обычная функция - Python вызовет его
метод__call__для обработки операции вызова, выполняемой в tkinter
при нажатии кнопки. В данном случае обобщенный метод__call__
фактически замещает связанный метод. Обратите внимание, что здесь для хранения информации, используемой при обработке событий, задействуется атрибут self, msg - self, являющийся ссылкой на исходный экземпляр класса, который автоматически передается при вызове специального метода__call__.
Все четыре версии gui3 создают одинаковые окна (рис. 7.11), но при нажатии на кнопку выводят в stdout различные сообщения:
C:\...\PP4E\Gui\Intro> python gui3.py Hello, I must be going...
C:\...\PP4E\Gui\Intro> python gui3b.py
Hello lambda world
C:\...\PP4E\Gui\Intro> python gui3c.py
Hello class method world
C:\...\PP4E\Gui\Intro> python gui3d.py
Hello __call__ world
Существуют свои основания для использования каждого из приемов определения обработчиков событий (функция, lambda-выражение, метод класса, вызываемый класс), но необходимо перейти к более крупным примерам, чтобы выйти из области чистого теоретизирования.
Другие протоколы обратного вызова в tkinter
Запомните также на будущее, что использование параметров command для перехвата генерируемых пользователем событий нажатия кнопки является лишь одним из способов регистрации обработчиков в библиотеке tkinter. На самом деле существуют различные способы перехвата событий в сценариях tkinter:
Параметр command кнопки
Как только что было показано, событие нажатия кнопки перехватывается путем передачи вызываемого объекта в параметре command виджета. То же относится к другим виджетам, похожим на кнопки, с которыми мы познакомимся в главе 8 (например, переключателям, флажкам и ползункам).
Параметры, command меню
В последующих главах обзора библиотеки tkinter будет показано, что параметр command используется также для передачи обработчиков событий выбора пунктов меню.
Протоколы полос прокрутки
Виджеты полос прокрутки тоже регистрируют обработчики с помощью параметра command, но обладают особым протоколом событий, позволяющим им быть взаимно связанными с виджетом, для прокрутки которого они предназначены (например, окна списков, текстовые окна и холсты): перемещение ползунка на полосе прокрутки автоматически перемещает содержимое виджета и наоборот.
Обобщенные методы bind виджетов
Имеется возможность использовать более универсальный механизм метода bind для регистрации низкоуровневых обработчиков событий, таких как нажатия клавиш, перемещения и щелчки мышью и так далее. В отличие от обработчиков, зарегистрированных с помощью параметра command, обработчики, зарегистрированные методом bind, получают в качестве аргумента объект события (экземпляр класса Event из библиотеки tkinter), который предоставляет контекст события - виджет, к которому относится событие, экранные координаты и так далее.
Протоколы менеджера окон
Кроме того, сценарии могут перехватывать события менеджера окон (например, запрос на закрытие окна) путем внедрения в механизм метода protocol менеджера окон, который доступен для оконных объектов верхнего уровня. Например, установив обработчик события WM_DELETE_WINDOW, можно перехватить событие от кнопки закрытия окна.
Обработчики планируемых событий
Наконец, в сценарии, использующем библиотеку tkinter, можно также зарегистрировать обработчики, которые должны вызываться в особых случаях, например при срабатывании таймера, поступлении входных данных и холостом состоянии цикла событий. Сценарии могут также приостанавливаться и ожидать событий, связанных с изменением состояния окон и специальных переменных. С этими типами событий мы более подробно познакомимся в конце главы 9.
Связывание событий
Из всех перечисленных протоколов наиболее универсальным, но, вероятно, и наиболее сложным является метод bind. Более подробно мы изучим его потом, но чтобы получить первоначальное представление, рассмотрим пример 7.16, который создает тот же графический интерфейс, что и примеры из предыдущего раздела, но для перехвата события нажатия кнопки использует метод bind, а не параметр command.
Пример 7.16. PP4E\Gui\Intro\gui3e.py
import sys
from tkinter import * def hello(event):
print(‘Press twice to exit’) # одиночный щелчок левой кнопкой
def quit(event): # двойной щелчок левой кнопкой
print(‘Hello, I must be going...’) # event дает виджет, координаты и т.д. sys.exit()
widget = Button(None, text=’Hello event world’) widget.pack()
widget.bind(‘’, hello) # привязать обработчик щелчка
widget.bind(‘’, quit) # привязать обработчик двойного щелчка
widget.mainloop()
В этой версии параметр command для кнопки вообще не определяется. Вместо этого выполняется установка низкоуровневых обработчиков событий одинарных () и двойных щелчков левой кнопкой () внутри области отображения кнопки. Метод bind принимает большую группу таких идентификаторов событий в разнообразных форматах, с которыми мы познакомимся в главе 8.
При выполнении этого сценария снова создается то же самое окно (рис. 7.11). При одиночном щелчке на кнопке программа выводит сообщение, но не завершается - чтобы завершить программу, нужно щелкнуть на кнопке дважды. Ниже приводятся сообщения, выводимые после двух одиночных щелчков и одного двойного (двойной щелчок сначала запускает обработчик события одиночного щелчка):
C:\...\PP4E\Gui\Intro> python gui3e.py
Press twice to exit Press twice to exit Press twice to exit Hello, I must be going...
Щелчки мышью на кнопке в этом сценарии перехватываются вручную, поэтому конечный результат примерно такой же - специальные протоколы виджетов, такие как параметр command кнопки, в действительности являются просто интерфейсами более высокого уровня к событиям, которые могут быть перехвачены с помощью метода bind.
Рис. 7.11. Кнопка, нажатие на которую вызывает функцию Python
Более подробно мы разберем работу метода bind и все другие способы установки обработчиков событий, предоставляемые библиотекой tkinter, далее в этой книге. Однако сначала займемся построением более крупных графических интерфейсов, состоящих не только из одной кнопки, и другими способами использования классов в графических интерфейсах.
Добавление нескольких виджетов
Настало время строить интерфейсы пользователя с несколькими виджетами. Сценарий в примере 7.17 создает окно, изображенное на рис. 7.12.
Пример 7.17. PP4E\Gui\Intro\gui4.py
from tkinter import *
def greeting():
print(‘Hello stdout world!...’) win = Frame()
win.pack()
Label(win, text=’Hello container world’).pack(side=TOP) Button(win, text=’Hello’, command=greeting).pack(side=LEFT) Button(win, text=’Quit’, command=win.quit).pack(side=RIGHT)
win.mainloop()
Рис. 7.12. Окно с несколькими виджетами
Этот сценарий создает виджет Frame (еще один класс из библиотеки tkinter), к которому прикрепляются три других виджета - Label и два Button - путем передачи объекта Frame в первом аргументе. На языке tkinter это означает, что виджет Frame становится родителем для трех других виджетов. Обе кнопки этого интерфейса вызывают следующие обработчики:
• Щелчок на кнопке HeLLo запускает функцию greeting, определенную внутри этого файла, которая производит вывод в поток stdout.
• Щелчок на кнопке Quit вызывает стандартный метод tkinter quit, который виджет win наследует от класса Frame (Frame.quit имеет тот же эффект, что и использованный ранее метод Tk. quit).
Ниже приводится текст, который выводится в stdout при щелчке на кнопке HeLLo, какими бы ни были стандартные потоки ввода-вывода для этого сценария:
C:\...\PP4E\Gui\Intro> python gui4.py Hello stdout world!...
Hello stdout world!...
Hello stdout world!...
Hello stdout world!...
Понятие прикрепления виджетов к контейнерам оказывается в сердцевине всех структур в библиотеке tkinter. Однако прежде чем подробно вникать в эту тему, обсудим небольшую деталь.
Еще раз об изменении размеров: обрезание
Ранее мы видели, как заставить виджеты расширяться вместе с родительским окном, передавая параметры expand и fill менеджеру компоновки pack. Теперь, когда у нас в окне имеется несколько виджетов, я открою вам один из полезных секретов компоновщика. Как правило, при уменьшении размеров окна виджеты, добавленные первыми, обрезаются в последнюю очередь. Это означает, что порядок добавления элементов определяет, какие из них окажутся скрытыми, если окно сделается слишком маленьким, - элементы, добавленные последними, обрезаются в первую очередь. Например, на рис. 7.13 показано, что произойдет, если окно сценария gui4 уменьшить в интерактивном режиме.
Рис. 7.13. Уменьшение размеров gui4
Попробуйте изменить порядок создания метки и кнопок в сценарии и посмотреть, что произойдет при сжатии окна: виджет, добавленный первым, всегда исчезает последним. Например, если метка добавляется последней, то, как видно на рис. 7.14, она будет обрезана первой, даже если прикреплена к верхнему краю: параметр side и порядок добавления виджетов вместе влияют на общую структуру, но только порядок упаковки имеет значение, когда окно уменьшается. Ниже показан измененный порядок создания виджетов:
Button(win, text=’Hello’, command=greeting).pack(side=LEFT)
Button(win, text=’Quit’, command=win.quit).pack(side=RIGHT)
Label(win, text=’Hello container world’).pack(side=TOP)
Рис. 7.14. Метка добавляется последней, а обрезается первой
Это обусловлено тем, что библиотека tkinter запоминает порядок добавления. Сценарии могут заранее готовиться к сжатию окон, вызывая вначале метод pack для более важных виджетов. Например, в предстоящем обзоре библиотеки tkinter мы встретим сценарий, который создает меню и панели инструментов в верхней и нижней части окна. Чтобы обеспечить их исчезновение при сжатии окна в последнюю очередь, они добавляются первыми, перед теми компонентами, которые размещаются в середине. Аналогично полосы прокрутки, содержащиеся в интерфейсах, обычно добавляются раньше, чем прокручиваемые ими элементы (например, текстовые окна или списки), чтобы сохраняться при сжатии окна.
Прикрепление виджетов к фреймам
Наиболее важным нововведением в этом примере является использование фреймов: виджеты Frame служат просто контейнерами для других виджетов, благодаря чему возникает представление о графических интерфейсах как об иерархиях, или деревьях виджетов. Здесь роль охватывающего окна для трех других элементов играет виджет win. Однако в целом, прикрепляя виджеты к фреймам, а фреймы к другим фреймам, можно строить графические интерфейсы с произвольной структурой. Просто поделите графический интерфейс на ряд прямоугольников уменьшающегося размера, реализуйте каждый из них как Frame и прикрепите к фреймам простые виджеты.
В данном сценарии, когда виджет win передается в первом аргументе конструкторам Label и Button, библиотека tkinter прикрепляет их к виджету Frame (они становятся дочерними для win). Сам объект win по умолчанию прикрепляется к окну верхнего уровня, потому что конструктору Frame не был передан родитель. Когда мы предлагаем виджету win начать выполнение (вызывая метод mainloop), библиотека tkinter отображает все графические элементы в построенном нами дереве.
Три дочерних виджета также позволяют указывать параметры pack: аргументы side говорят о том, к какой части содержащего их фрейма (то есть win) должен быть прикреплен новый виджет. Метка подвешивается к верхнему краю, а кнопки прикрепляются к боковым сторонам. TOP, LEFT и RIGHT являются строковыми переменными с предварительно присвоенными значениями, которые импортируются из tkinter. Размещение виджетов происходит немного сложнее, чем простое указание сторон, к которым они прикрепляются, но чтобы узнать почему, придется сделать краткое отступление и обсудить детали работы менеджера компоновки.
Порядок компоновки и прикрепление к сторонам
При отображении дерева виджетов дочерние виджеты появляются внутри родительских и располагаются в соответствии с порядком и параметрами компоновки. По этой причине порядок добавления элементов не только определяет порядок их обрезания, но также определяет, как будут учитываться значения параметра side в общей картине.
Вот как работает система компоновки элементов:
1. Компоновщик начинает с пустого доступного пространства, в которое входит весь родительский контейнер (например, весь фрейм или окно верхнего уровня).
2. Когда виджет прикрепляется к какому-либо краю, ему отдается весь запрашиваемый край в оставшемся пустом пространстве, и пустое пространство сокращается.
3. Последующие виджеты получают все, что осталось от этого края после добавления предыдущих виджетов.
4. После того как виджетам будет отдано все пустое пространство, expand делит оставшееся пространство, а fill и anchor растягивают и устанавливают виджеты внутри выделенной им области.
Например, изменим в сценарии gui4 логику создания дочерних виджетов, как показано ниже:
Button(win, text=’Hello’, command=greeting).pack(side=LEFT)
Label(win, text=’Hello container world’).pack(side=TOP)
Button(win, text=’Quit’, command=win.quit).pack(side=RIGHT)
В итоге получится совсем другой интерфейс, изображенный на рис. 7.15, и это всего лишь из-за перемещения инструкции создания метки на одну строку вниз (сравните с рис. 7.12).
Рис. 7.15. Метка была добавлена второй
Теперь, несмотря на значение параметра side, метка не захватывает весь верх окна, и чтобы разобраться в причине, нужно представить себе сокращающиеся пустые пространства. Так как первой в интерфейс добавляется кнопка Hello, ей выделяется весь левый край фрейма. После этого метка получает весь верх того, что осталось. Наконец, кнопка Quit получает правый край остатка - прямоугольник, находящийся справа от кнопки Hello и под меткой. При сжатии этого окна графические элементы обрезаются в порядке, противоположном их добавлению: первой исчезает кнопка Quit, за ней следует метка.37
В первоначальной версии этого примера (рис. 7.12) метка занимает весь верхний край только потому, что она добавляется первой, а не благодаря значению параметра side. Если внимательнее рассмотреть рис. 7.14, можно заметить, что он иллюстрирует действие тех же самых правил -метка находится между кнопками, потому что они уже полностью заняли левый и правый край.
Снова о параметрах expand и fill компоновки
Помимо порядка добавления на взаимное расположение виджетов оказывает влияние также уже знакомый параметр fill, позволяющий растягивать виджет так, чтобы он занимал все пространство вдоль выделенного ему пустого края, а все пустое пространство, оставшееся после расстановки элементов, поровну распределять между виджетами, при добавлении которых был указан параметр expand=YES. Например, следующий фрагмент создает окно, изображенное на рис. 7.16 (сравните с рис. 7.15).
Button(win, text=’Hello’, command=greeting).pack(side=LEFT,fill=Y)
Label(win, text=’Hello container world’).pack(side=TOP)
Button(win, text=’Quit’, command=win.quit).pack(side=RIGHT, expand=YES,fill=X)
Рис. 7.16. Компоновка с параметрами expand и fill
Чтобы все эти элементы увеличивались вместе с окном, необходимо сделать содержащий их контейнер расширяемым - виджеты расширяются за пределы своего первоначального положения, только если расширяются все их родители. Ниже демонстрируются изменения в gui4.py:
win = Frame()
win.pack(side=TOP, expand=YES, fill=BOTH)
Button(win, text=’Hello’, command=greeting).pack(side=LEFT, fill=Y)
Label(win, text=’Hello container world’).pack(side=TOP)
Button(win, text=’Quit’, command=win.quit).pack(side=RIGHT, expand=YES,fill=X)
При выполнении этого фрагмента фрейм получит весь верхний край родительского окна, как и раньше (то есть верхний участок корневого окна). Однако теперь он настроен так, что должен расширяться и заполнять неиспользуемое пространство своего родителя в обоих направлениях, поэтому он и все прикрепленные к нему дочерние элементы расширяются вместе с окном, как показано на рис. 7.17.
Рис. 7.17. Расширяемый фрейм в увеличенном окне gui4
Использование якорей вместо растягивания
Как если бы это не обеспечивало достаточной гибкости, механизм компоновки дополнительно предоставляет для размещения графических элементов в отведенной для них области параметр anchor помимо заполнения пространства с помощью fill. Параметр anchor принимает константы из библиотеки tkinter, указывающие восемь направлений (N, NE, NW, S и так далее), или константу CENTER (например, anchor=NW). Компоновщику при этом предписывается разместить виджет в желательном месте внутри отведенного для него пространства, если это пространство больше, чем требуется для изображения данного графического элемента.
По умолчанию параметр anchor получает значение CENTER, поэтому виджеты выводятся в центре отведенного им пространства (выделенного им края пустого пространства), если только для них не определено иное местоположение с помощью параметра anchor или они не растянуты с помощью параметра fill. Для демонстрации изменим сценарий gui4, как показано ниже:
Button(win, text=’Hello’, command=greeting).pack(side=LEFT, anchor=N)
Label(win, text=’Hello container world’).pack(side=TOP)
Button(win, text=’Quit’, command=win.quit).pack(side=RIGHT)
Новым здесь является только то, что кнопка HeLLo закреплена на северной стороне отведенного ей пространства. Так как эта кнопка была добавлена первой, она получила весь левый край родительского фрейма. Места оказалось больше, чем необходимо кнопке, поэтому по умолчанию она оказывается в середине этого края, как показано на рис. 7.15 (то есть закреплена в центре). После установки якоря в значение N она смещается вверх по левому краю, как показано на рис. 7.18.
Рис. 7.18. Закрепление кнопки на севере
Имейте в виду, что параметры fill и anchor начинают приниматься во внимание только после того как виджету будет выделено место у края пустого пространства, определяемого параметром side, в соответствии с порядком добавления, и запроса дополнительного пространства expand. Путем варьирования порядка добавления, а также значений параметров, определяющих край, направление заполнения и закрепления, можно получить массу эффектов расположения и обрезания, и стоит потратить некоторое время, экспериментируя с разными вариантами, если вы этого еще не сделали. Например, в исходной версии этого примера метка занимает весь верхний край только потому, что была добавлена первой.
Как будет показано ниже, фреймы можно вкладывать в другие фреймы, благодаря чему можно создавать довольно сложные структуры. В действительности, каждый родительский контейнер является отдельным пустым пространством, поэтому возникает некоторый механизм обхода для алгоритма выделения пустого пространства компоновщиком: чтобы точнее управлять местом, где будет отображаться некоторая группа виджетов, просто скомпонуйте их во вложенном фрейме и прикрепите этот фрейм как пакет к более крупному контейнеру. Например, ряд расположенных рядом кнопок проще поместить в отдельный фрейм, чем смешивать с остальными виджетами.
Наконец, имейте в виду, что дерево виджетов, создаваемое в этих примерах, в действительности является неявным - библиотека tkinter внутри ведет учет связей, которые образуются в результате передачи аргументов родительских виджетов. На языке ООП это называется композицией - фрейм содержит метку и несколько кнопок. А теперь рассмотрим другой вид связи - наследование.
Настройка виджетов с помощью классов
В сценариях, использующих библиотеку tkinter, совсем необязательно применять приемы ООП, но они определенно могут оказаться полезными. Как мы только что видели, графические интерфейсы на базе tkinter строятся, как деревья объектов экземпляров классов. Ниже демонстрируется еще один способ применения ООП для моделирования графического интерфейса: специализация виджетов посредством наследования. Сценарий в примере 7.18 создает окно, изображенное на рис. 7.19.
Рис. 7.19. Подкласс кнопки в действии
Пример 7.18. PP4E\Gui\Pntro\gui5.py
from tkinter import *
class HelloButton(Button):
def __init__(self, parent=None, **config): # регистрирует метод callback
Button.__init__(self, parent, **config) # и добавляет себя в интерфейс
self.pack() # можно использовать старый
self.config(command=self.callback) # стиль аргумента config
def callback(self): # действие по умолчанию при нажатии
print(‘Goodbye world...’) # переопределить в подклассах
self.quit()
if__name__== ‘__main__’:
HelloButton(text=’Hello subclass world’).mainloop()
В этом примере нет ничего необычного: он просто отображает одну кнопку, при нажатии на которую программа выводит сообщение и завершается. Но на этот раз мы сами создали виджет кнопки. Класс Hel-loButton наследует все свойства и методы класса Button, а также добавляет метод callback и логику в конструкторе, устанавливая параметру command значение self.callback - связанный метод экземпляра. При нажатии на кнопку теперь вызывается не просто функция, а метод callback нового класса виджета.
Здесь аргумент **config собирает в словарь все дополнительные именованные аргументы, которые затем передаются конструктору Button. Конструкция **config в вызове конструктора Button распаковывает словарь в список именованных аргументов (в действительности в этом нет необходимости, благодаря поддержке устаревшей формы вызова со словарем, встречавшейся нам ранее, но и вреда никакого не будет). Мы уже встречались с вызовом метода config виджетов в конструкторе HelloBut-ton: это просто альтернативный способ передачи параметров настройки после создания виджета (вместо передачи аргументов конструктору).
Стандартизация поведения и внешнего вида
Какой же смысл в создании подклассов виджетов? В двух словах, благодаря такому подходу появляется возможность создавать виджеты, выглядящие и действующие одинаково, путем создания подклассов, и использовать преимущества модели ООП в языке Python. Этот прием может оказаться достаточно мощным, чтобы использовать его в крупных программах.
Общие черты поведения
Сценарий в примере 7.18 стандартизирует поведение - он демонстрирует возможность настройки виджетов путем создания подклассов вместо передачи параметров. Экземпляр класса HelloButton является настоящей кнопкой - при ее создании параметры настройки, такие как text, передаются как обычно. Но можно также определить обработчик событий, переопределив в подклассе метод callback, как показано в примере 7.19.
Пример 7.19. PP4E\Gui\Intro\gui5b.py
from gui5 import HelloButton
class MyButton(HelloButton): # подкласс класса HelloButton
def callback(self): # переопределяет метод обработчика
print("Ignoring press!...”) # события нажатия кнопки
if__name__== ‘__main__’:
MyButton(None, text=’Hello subclass world’).mainloop()
Этот сценарий создает то же самое окно, но вместо завершения программы при нажатии кнопки MyButton происходит вывод сообщения в поток stdout и программа продолжает работу. Ниже показаны сообщения, выведенные в стандартный поток вывода после нескольких нажатий:
C:\...\PP4E\Gui\Intro> python gui5b.py
Ignoring press!...
Ignoring press!...
Ignoring press!...
Ignoring press!...
Решить, как проще настраивать графические элементы - создавая подклассы или путем передачи им параметров, - это дело вкуса. Но нужно отметить, что библиотека Tk приобретает в Python настоящие объектноориентированные черты, поскольку объектно-ориентированным является сам язык Python - используя привычные приемы ООП, мы можем создавать свои подклассы виджетов. Такой подход позволяет определять не только общие черты поведения, но и общий внешний вид.
Общий внешний вид
Например, хотя мы и не будем углубляться в изучение параметров настройки виджетов до следующей главы, тем не менее подобный класс кнопки мог бы обеспечить стандартизацию внешнего вида, отличного от внешнего вида, придаваемого библиотекой tkinter по умолчанию, для каждого своего экземпляра, и приблизиться к реализации таких понятий, как «стили» или «темы», используемых в некоторых других инструментах создания графических интерфейсов:
class ThemedButton(Button): # настраивает стиль
def __init__(self, parent=None, **configs): # для всех экземпляров
Button.__init__(self, parent, **configs) # описание параметров
self.pack() # смотрите в главе 8
self.config(fg=’red’, bg=’black’,
font=(‘courier’, 12), relief=RAISED, bd=5)
B1 = ThemedButton(text=’spam’, command=onSpam) # обычные виджеты кнопок B2 = ThemedButton(text=’eggs’) # но наследуют общий стиль
B2.pack(expand=YES, fill=BOTH)
Этот фрагмент приводится лишь для предварительного ознакомления - полную версию вы найдете в файле gui5b-themed.py в дереве примеров, а дополнительные сведения о параметрах настройки виджетов -в главе 8. Но он иллюстрирует возможность придания общего внешнего вида за счет создания подклассов виджетов - все кнопки, созданные из этого класса, будут выглядеть одинаково, и автоматически будут изменять внешний вид при любых изменениях в классе.
Прием создания подклассов - это, безусловно, инструмент программиста, но мы можем сделать возможность настройки доступной и для пользователей графических интерфейсов. В крупных программах, демонстрируемых далее в этой книге (например, PyEdit, PyClock и PyMail-GUI), мы иногда будем добиваться похожего эффекта за счет импортирования настроек из модулей и применения их к виджетам, как если бы они были встроенными настройками. Если такие внешние настройки использовать в подклассах виджетов, таких как наш класс ThemedBut-ton выше, они будут применяться ко всем экземплярам и подклассам (для справки: полная версия следующего фрагмента находится в файле gui5b-themed-user.py):
from user_preferences import bcolor, bfont, bsize # получить настройки
class ThemedButton(Button):
def __init__(self, parent=None, **configs):
Button.__init__(self, parent, **configs)
self.pack()
self.config(bg=bcolor, font=(bfont, bsize))
ThemedButton(text=’spam’, command=onSpam) # обычные виджеты кнопок, но
ThemedButton(text=’eggs’, command=onEggs) # наследуют настройки пользователя
class MyButton(ThemedButton): # подклассы также наследуют
def __init__(self, parent=None, **configs): # настройки пользователя
ThemedButton.__init__(self, parent, **configs)
self.config(text='subclass')
MyButton(command=onSpam)
Напомню, что подробнее о параметрах настройки виджетов будет рассказываться в следующей главе, а здесь я хотел лишь донести общую мысль, что настройка виджетов путем создания подклассов позволяет определять не только поведение, но и внешний вид всего набора виджетов. Следующий пример демонстрирует еще один способ настройки -создание настраиваемых и присоединяемых пакетов виджетов, обычно известных, как компоненты.
Повторно используемые компоненты и классы
Крупные графические интерфейсы часто строятся как подклассы Frame с реализацией обработчиков событий в виде методов. Благодаря такой структуре возникает естественное место для хранения информации между событиями: атрибуты экземпляров классов. Она позволяет также специализировать графические интерфейсы за счет переопределения методов в новых подклассах и прикреплять их к более крупным структурам интерфейса, чтобы повторно использовать в качестве общих компонентов. Например, текстовый редактор с графическим интерфейсом, реализованный как подкласс Frame, можно прикреплять к любому числу других графических интерфейсов и настраивать с их помощью - при правильном использовании такой текстовый редактор можно встроить в любой интерфейс пользователя, где требуются средства редактирования текста.
С таким текстовым редактором в виде компонента мы встретимся в главе 11. А пока проиллюстрируем идею простым примером 7.20. Сценарий gui6.py создает окно, изображенное на рис. 7.20.
Пример 7.20. PP4E\Gui\Intro\gui6.py
from tkinter import *
class Hello(Frame): # расширенная версия класса Frame
def __init__(self, parent=None):
Frame.__init__(self, parent) # вызвать метод __init__ суперкласса
self.pack() self.data = 42
self.make_widgets() # прикрепить виджеты к себе
def make_widgets(self):
widget = Button(self, text=’Hello frame world!’, command=self.message) widget.pack(side=LEFT)
def message(self): self.data += 1
print(‘Hello frame world %s!’ % self.data) if __name__ == ‘__main__’: Hello().mainloop()
Рис. 7.20. Нестандартный фрейм в действии
Этот сценарий выводит окно с единственной кнопкой. При ее нажатии вызывается связанный метод self, message, который снова выводит сообщение в stdout. Ниже показаны сообщения, выведенные после четырехкратного нажатия кнопки - обратите внимание, что атрибут self.data (в данном случае простой счетчик) сохраняет информацию о состоянии между нажатиями:
C:\...\PP4E\Gui\Intro> python gui6.py Hello frame world 43!
Hello frame world 44!
Hello frame world 45!
Hello frame world 46!
Это может показаться окольным методом отображения кнопки типа Button (в примерах 7.10, 7.11 и 7.12 то же достигалось меньшим числом строк). Но класс Hello предоставляет контейнерную организационную структуру для построения графического интерфейса. В примерах, предшествовавших предыдущему разделу, графические интерфейсы создавались с применением процедурного подхода: мы вызывали конструкторы виджетов, как если бы они были функциями, и связывали виджеты воедино, указывая родителя при вызове конструктора. Не было никакого представления о внешнем контексте, помимо глобальной области видимости файла модуля, содержащего вызовы методов виджетов. Такой подход годится для простых графических интерфейсов, но при построении структур более крупных интерфейсов служит причиной хрупкости кода.
При создании подкласса, наследующего класс Frame, как было продемонстрировано, этот класс становится охватывающим контекстом графического интерфейса:
• Виджеты добавляются путем прикрепления объектов к self, экземпляру подкласса контейнера Frame (например, Button).
• Обработчики событий регистрируются как связанные методы объекта self, вследствие чего вызовы направляются обратно в реализацию класса (например, self.message).
• Информация о состоянии сохраняется между событиями путем присвоения атрибутам объекта self и доступна всем обработчикам событий в классе (например, self.data).
• Легко можно создать несколько экземпляров такого компонента графического интерфейса, даже внутри одного и того же процесса, потому что каждый экземпляр класса является отдельным пространством имен.
• Классы обладают естественной возможностью настройки благодаря возможности наследования и композиции.
В некотором смысле графические интерфейсы целиком становятся специализированными объектами Frame с расширениями, соответствующими их применению. Классы также позволяют реализовать протоколы построения виджетов (например, метод make_widgets в данном случае), выполнять стандартные задачи настройки (например, установка параметров настройки менеджера окон) и так далее. Одним словом, подклассы Frame дают простой способ организации совокупностей объектов других классов виджетов.
Прикрепление классов компонентов
Более важно, вероятно, что подклассы Frame являются настоящими виджетами: их можно и дальше расширять и модифицировать, создавая подклассы, и прикреплять к контейнерным виджетам. Например, чтобы прикрепить весь пакет виджетов, создаваемых классом, к чему-либо еще, нужно создать экземпляр класса, передав ему родительский виджет. Это иллюстрируется примером 7.21, при запуске которого создается окно, изображенное на рис. 7.21.
Пример 7.21. PP4E\Gui\Intro\gui6b.py
from sys import exit
from tkinter import * # импортировать классы виджетов Tk
from gui6 import Hello # импортировать подкласс фрейма
parent = Frame(None) # создать контейнерный виджет
parent.pack()
Hello(parent).pack(side=RIGHT) # прикрепить виджет Hello, не запуская его
Button(parent, text=’Attach’, command=exit).pack(side=LEFT) parent.mainloop()
Рис. 7.21. Прикрепленный компонент класса справа
В этом сценарии кнопка Hello добавляется к правому краю родителя parent - контейнера Frame. На самом деле, кнопка в правой части этого окна является встроенным компонентом: его кнопка действительно представляет прикрепленный объект класса Python. Нажатие кнопки встроенного класса справа, как и ранее, выводит сообщение; нажатие новой кнопки закрывает окно вызовом sys.exit:
C:\...\PP4E\Gui\Intro> python gui6b.py
Hello frame world 43!
Hello frame world 44!
Hello frame world 45!
Hello frame world 46!
В более сложных интерфейсах можно прикреплять большие подклассы Frame к другим компонентам-контейнерам и разрабатывать каждый из них независимо. В примере 7.22 демонстрируется еще один специализированный подкласс класса Frame, который прикрепляет экземпляр класса Hello более объектно-ориентированным способом. При запуске в виде самостоятельного сценария он создает окно, идентичное изображенному на рис. 7.21.
Пример 7.22. PP4E\Gui\Intro\gui6c.py
from tkinter import * # импортировать классы виджетов Tk
from gui6 import Hello # импортировать подкласс фрейма
class HelloContainer(Frame):
def __init__(self, parent=None):
Frame.__init__(self, parent)
self.pack()
self.makeWidgets()
def makeWidgets(self):
Hello(self).pack(side=RIGHT) # прикрепить объект класса Hello к себе Button(self, text=’Attach’, command=self.quit).pack(side=LEFT)
if __name__ == ‘__main__’: HelloContainer().mainloop()
Выглядит и действует этот сценарий в точности как gui6b, но в качестве обработчика события добавленной кнопки он регистрирует метод self. quit, который является стандартным методом quit виджетов, унаследованным от Frame. На этот раз окно демонстрирует действие двух классов Python - виджеты встроенного компонента справа (оригинальная кнопка Hello) и графические элементы контейнера слева.
Конечно, это простой пример (мы прикрепили здесь только одну кнопку). Но в более практических примерах набор прикрепляемых таким способом виджетов может быть значительно больше. Представьте себе, что мы заменили вызов конструктора Hello в этом сценарии вызовом, прикрепляющим готовый и полностью отлаженный объект калькулятора, и мощь данной парадигмы станет вам более понятна. Если все свои компоненты графического интерфейса создавать как классы, они автоматически образуют библиотеку многократно используемых виджетов, которые всегда можно будет вставить в другие приложения.
Расширение классов компонентов
При построении графических интерфейсов с помощью классов существует ряд способов повторного их использования в других приложениях. Чтобы расширить класс Hello, а не прикреплять его, можно переопределить некоторые его методы в новом подклассе (который сам станет специализированным виджетом Frame). Этот прием демонстрируется в примере 7.23.
Пример 7.23. PP4E\Gui\Intro\gui6d.py
from tkinter import * from gui6 import Hello
class HelloExtender(Hello):
def make_widgets(self): # расширение метода
Hello.make_widgets(self)
Button(self, text=’Extend’, command=self.quit).pack(side=RIGHT) def message(self):
print(‘hello’, self.data) # переопределение метода if __name__ == ‘__main__’: HelloExtender().mainloop()
Метод make_widgets этого подкласса сначала создает виджеты обращением к методу суперкласса, а затем добавляет справа вторую кнопку Extend, как показано на рис. 7.22.
Рис. 7.22. Модифицированные виджеты класса слева
Поскольку этот подкласс переопределяет метод message, нажатие кнопки исходного суперкласса, расположенной слева, теперь выводит в stdout другую строку (когда осуществляется поиск вверх по дереву наследования, начиная от объекта self, первым обнаруживается атрибут message в этом подклассе, а не в суперклассе):
C:\...\PP4E\Gui\Intro> python gui6d.py
hello 42
hello 42
hello 42
hello 42
Но нажатие новой кнопки Extend справа, добавленной этим подклассом, приводит к немедленному выходу из приложения, потому что обработчиком событий от добавленной кнопки является метод quit (унаследованный от Hello, который в свою очередь наследует его от Frame). Таким образом, этот класс модифицирует исходный класс, добавляя новую кнопку и изменяя поведение метода message.
Это довольно простой пример, но он наглядно демонстрирует технологию, обеспечивающую широкие возможности на практике: чтобы изменить поведение графического интерфейса, можно не изменять существующую реализацию, а написать новый класс, который модифицирует некоторые части интерфейса. Основная реализация отлаживается только один раз, а затем модифицируется с помощью подклассов, когда возникают особые потребности.
Мораль заключается в том, что графические интерфейсы, использующие библиотеку tkinter, можно программировать вообще без создания новых классов, но использование классов для структурирования программного кода в конечном итоге значительно расширяет возможности его повторного использования. При правильном подходе можно не только прикреплять уже отлаженные компоненты к новым интерфейсам, но и изменять их поведение в новых внешних подклассах в соответствии с особыми требованиями. В любом случае первоначальные затраты, связанные с использованием классов, должны в итоге окупиться за счет сокращения времени разработки.
Автономные классы-контейнеры
Прежде чем двинуться дальше, хочу отметить, что большая часть перечисленных выше преимуществ от создания компонентов на основе классов может быть получена в результате создания автономных классов, не являющихся производными от класса Frame или других классов виджетов из библиотеки tkinter. Так, класс из примера 7.24 создает окно, изображенное на рис. 7.23.
Пример 7.24. PP4E\Gui\Intro\gui7.py
from tkinter import *
class HelloPackage: # не является подклассом виджета
def __init__(self, parent=None):
self.top = Frame(parent) # встроить фрейм Frame
self.top.pack() self.data = 0
self.make_widgets() # прикрепить виджеты к self.top
def make_widgets(self):
Button(self.top, text=’Bye’, command=self.top.quit).pack(side=LEFT) Button(self.top, text=’Hye’, command=self.message).pack(side=RIGHT)
def message(self): self.data += 1
print(‘Hello number’, self.data) if __name__ == ‘__main__’: HelloPackage().top.mainloop()
Рис. 7.23. Автономный класс в действии
Если запустить этот сценарий, кнопка Hye будет производить вывод в stdout, а Bye - закрывать окно и завершать работу программы, как и раньше:
C:\...\PP4E\Gui\Intro> python gui7.py
Hello number 1
Hello number 2
Hello number 3
Hello number 4
Так же как и раньше, атрибут self.data сохраняет информацию о состоянии между событиями, а для обработки событий вызывается метод self.message, имеющийся в этом классе. Но в отличие от того, что было раньше, сам класс HelloPackage не является подклассом виджета Frame.
Он вообще не является подклассом какого-либо виджета - он служит только для создания пространства имен, хранящего действительные объекты виджетов и информацию о состоянии. По этой причине виджеты прикрепляются к объекту self.top (встроенному фрейму Frame), а не к self. Более того, все ссылки на объект как на виджет должны передаваться вниз, встроенному фрейму, как, например, вызов метода top. mainloop для запуска интерфейса в конце сценария.
Это приводит к тому, что внутри класса приходится писать чуть больше программного кода, но устраняет возможные конфликты имен между атрибутами, добавляемыми к self в структуре tkinter и существующими методами виджетов tkinter. Например, если определить в своем классе метод config, он замаскирует вызов config, экспортируемый библиотекой tkinter. Для автономных классов, как в этом примере, доступны будут только те методы и атрибуты экземпляров, которые определены в этих классах.
В действительности в библиотеке tkinter используется не очень много имен, поэтому обычно это не создает больших проблем.38 Конечно, такая вероятность существует, но, честно говоря, за 18 лет программирования на языке Python я не встречался с конфликтами имен tkinter в подклассах виджетов. Кроме того, использование автономных классов не лишено своих недостатков. Хотя в целом их можно прикреплять и создавать производные от них классы, они не вполне совместимы с действительными объектами виджетов. Например, вызовы настройки, выполняемые в примере 7.21 для подкласса Frame, будут терпеть неудачу в примере 7.25.
Пример 7.25. PP4E\Gui\Intro\gui7b.py
from tkinter import *
from gui7 import HelloPackage # или from gui7c, где добавлен __getattr__
frm = Frame() frm.pack()
Label(frm, text=’hello’).pack() part = HelloPackage(frm)
part.pack(side=RIGHT) # НЕУДАЧА! Должно быть part.top.pack(side=RIGHT)
frm.mainloop()
Этот сценарий вообще не будет работать, потому что part не является настоящим виджетом. Чтобы работать с ним как с виджетом, нужно спуститься в part.top, прежде чем настраивать интерфейс, и рассчитывать на то, что имя top не будет изменено разработчиком класса. Другими словами, требуется знать внутреннее устройство класса. Лучше всего эти действия реализовать в самом классе, определив метод, всегда направляющий обращения к неизвестным атрибутам встроенному объекту класса Frame, как показано в примере 7.26.
Пример 7.26. PP4E\Gui\Intro\gui7c.py
import gui7
from tkinter import *
class HelloPackage(gui7.HelloPackage): def __getattr__(self, name):
return getattr(self.top, name) # передать вызов настоящему виджету
if __name__ == ‘__main__’: HelloPackage().mainloop() # вызовет __getattr__!
Этот сценарий создает такое же окно, как на рис. 7.23. Однако изменения в примере 7.25, выражающиеся в импортировании расширенной версии класса HelloPackage из модуля gui7c, обеспечивают корректную работу интерфейса, изображенного на рис. 7.24.
Рис. 7.24. Автономный класс в действии
Перенаправление операций обращения к атрибутам вложенных виджетов обеспечивает нормальную работу этого примера, но при этом требуется писать еще больше программного кода в автономных классах. Впрочем, как обычно, значимость всех таких компромиссов зависит от конкретного приложения.
Завершение начального обучения
В данной главе мы изучили основы использования библиотеки tkinter в сценариях на языке Python и познакомились с рядом простых виджетов - метками, кнопками, фреймами, а также с менеджером компоновки. Этого достаточно для создания простых интерфейсов, но в действительности мы лишь поверхностно ознакомились с набором виджетов tkinter.
В следующих двух главах мы будем применять полученные знания для изучения оставшейся части библиотеки tkinter и приемов ее использования для создания интерфейсов, встречающихся в реальных программах с графическим интерфейсом. В качестве предварительного обзора и предлагаемого маршрута в табл. 7.1 перечислены виджеты, которые нам там встретятся, примерно в том порядке, в котором они будут появляться. Обратите внимание, что в этой таблице перечислены только классы виджетов. Мы также встретимся с некоторыми дополнительными темами, относящимися к виджетам, которых нет в этой таблице.
Таблица 7.1. Классы виджетов tkinter
Классы виджетов
Описание
Label
Простая область для вывода текста
Button
Простая кнопка с меткой
Frame
Контейнер для прикрепления и размещения других виджетов
Toplevel, Tk
Новое окно, управляемое менеджером окон
Message
Метка с несколькими строками
Entry
Простое однострочное поле ввода текста
Checkbutton
Кнопка с двумя состояниями; обычно используется для организации для выбора нескольких вариантов
Radiobutton
Кнопка с двумя состояниями; обычно используется для организации выбора одного варианта из нескольких
Scale
Ползунок со шкалой
PhotoImage
Объект графического изображения, используемый для вывода полноцветных изображений на других виджетах
BitmapImage
Объект графического изображения, используемый для вывода растровых изображений на других виджетах
Menu
Набор вариантов выбора, связанных с Menubutton или с окном верхнего уровня
Таблица 7.1 (продолжение)
Классы виджетов
Описание
Menubutton
Кнопка, открывающая меню или подменю с вариантами выбора
Scrollbar
Элемент управления для прокрутки содержимого других виджетов (например, списка, холста, текста)
Listbox
Список имен, доступных для выбора
Text
Виджет для просмотра/редактирования многострочного текста, поддерживающий шрифты и так далее
Canvas
Область для изображения графики с поддержкой возможности рисования линий, окружностей, фотографий, текста и так далее.
В этой главе мы уже встречались с виджетами Label, Button и Frame. Для облегчения усвоения оставшийся материал разбит на две главы: глава 8 освещает элементы в верхней части табл. 7.1, вплоть до Menu, а в главе 9 представлены виджеты, находящиеся в нижней части таблицы.
Помимо классов виджетов, представленных в табл. 7.1, в библиотеке tkinter содержатся дополнительные классы и инструменты, многие из которых также будут исследованы в двух следующих главах:
Управление компоновкой
pack, grid, place
Связанные переменные tkinter
StringVar, IntVar, DoubleVar, BooleanVar Улучшенные виджеты. Tk
Spinbox, LabelFrame, PanedWindow Составные виджеты.
Dialog, ScrolledText, OptionMenu Планируемые обратные вызовы
Методы виджетов after, wait и update Прочие инструменты.
Стандартные диалоги, буфер обмена, bind и Event, параметры настройки виджетов, пользовательские и модальные диалоги, анимационные эффекты
Большинство виджетов tkinter принадлежит к числу знакомых интерфейсных элементов. Некоторые из них обладают очень богатой функциональностью. Например, класс Text реализует сложный виджет многострочного текста, поддерживающий шрифты, цвета и спецэффекты, мощности которого достаточно для реализации веб-броузера. Аналогично класс Canvas предоставляет множество инструментов, достаточно мощных для создания приложений отображения и обработки изображений. Кроме того, расширения для библиотеки tkinter, такие как Pmw, Tix и ttk, добавляют в инструментарий разработчика графических интерфейсов виджеты с еще более богатыми возможностями.
Соответствие между Python/tkinter и Tcl/Tk
В начале этой главы я упомянул, что библиотека tkinter является интерфейсом Python к библиотеке Tk, первоначально написанной для языка Tcl. В помощь читателям, переходящим на Python с Tcl, и для подведения итогов некоторых основных тем, встретившихся в этой главе, в данном разделе сравниваются интерфейсы Python и Tcl к Tk. Кроме того, такое сопоставление сделает для разработчиков программ на языке Python более полезными справочники по Tk, написанные для других языков.
Вообще говоря, ориентированность Tcl на применение строковых команд сильно отличается от подхода к программированию на языке Python, основанного на объектах. Однако, что касается использования Tk, синтаксические различия невелики. Ниже приводятся некоторые главные отличия интерфейса Python к tkinter:
Создание
Виджеты создаются как экземпляры классов при вызове конструктора класса виджета.
Владельцы (родители)
Родителями являются ранее созданные объекты, передаваемые конструкторам классов виджетов.
Параметры виджетов
Параметры являются именованными аргументами конструктора или метода config либо ключами словарей.
Операции
Операции виджетов (действия) становятся методами объектов классов виджетов tkinter.
Обратные вызовы
Обработчиком события может быть любой вызываемый объект: функция, метод, lambda-выражение и так далее.
Расширение
Виджеты расширяются с использованием механизма наследования классов в языке Python.
Композиция
Интерфейсы конструируются путем прикрепления объектов, а не конкатенации имен.
Связанные переменные (следующая глава)
Переменные, ассоциируемые с виджетами, являются объектами классов tkinter с методами.
Команды создания виджетов в языке Python (например, button) являются именами классов, начинающимися с заглавной буквы (например, Button), операции с виджетами, состоящие из двух слов (например, add command), становятся одним именем метода с подчеркиванием внутри (например, add_command), а метод «configure» можно кратко записывать «config», как в Tcl. В главе 8 будет также показано, что «переменные» библиотеки tkinter, ассоциируемые с виджетами, принимают форму объектов экземпляров классов (например, StringVar, IntVar) с методами get и set, а не просто именами переменных Python или Tcl. В табл. 7.2 более конкретно приведены основные соответствия между языками.
Таблица 7.2. Соответствие между Tk и tkinter
Операция
Tcl/Tl
Python/tkinter
Создание
Frame .panel
panel = Frame()
Владелец
button .panel.quit
quit = Button(panel)
Параметры
button .panel.go -fg black
go = Button(panel, fg=' black’)
Настройка
.panel.go config -bg red
g o. c o n f i g (b g=’ r e d ’) go[‘bg’] = ‘red’
Действия
.popup invoke
popup.invoke()
Компоновка
pack .panel -side left -fill x
panel.pack(side=LEFT, fill=X)
Конечно, некоторые из этих различий касаются не только синтаксиса. Например, Python строит внутреннее дерево объектов графических элементов, исходя из аргументов, определяющих родителя и передаваемых конструктору, не требуя объединения строк путей к виджетам. После создания виджета к нему можно обращаться непосредственно, по ссылке. При программировании на языке Tcl иногда можно спрятать записанные через точку имена путей вручную в переменных, но это не то же самое, что чисто объектно-ориентированная модель Python.
Как только вы напишете на языке Python несколько сценариев, использующих библиотеку tkinter, отличия объектов Python наверняка будут казаться вам тривиальными. В то же время, поддержка объектноориентированных приемов в языке Python вносит совершенно новую составляющую в разработку для Tk: вы получаете те же самые виджеты плюс поддержку возможности структурирования и многократного использования программного кода.
8
Экскурсия по tkinter, часть 1
«Виджеты, гаджеты, графические интерфейсы... Бог мой!»
В этой главе будет продолжено рассмотрение приемов программирования графических интерфейсов на языке Python. В предыдущей главе рассматривались простые виджеты - кнопки, метки и другие - демонстрирующие основы использования библиотеки tkinter в сценариях на языке Python. Такое упрощение было намеренным: легче охватить взглядом картину графического интерфейса целиком, если не приходится вникать в детали интерфейса виджетов. Но теперь, после знакомства с основами, в этой и следующей главе мы переходим к представлению более сложных объектов виджетов и средств, предоставляемых библиотекой tkinter.
Вы увидите, как разработка сценариев с графическим интерфейсом станет полезным и интересным делом. В этих двух главах мы познакомимся с классами, участвующими в построении элементов интерфейса, которые встречаются в настоящих программах, - ползунков, флажков, меню, прокручиваемых списков, диалогов, графики и так далее. За этими главами последует еще одна, завершающая, посвященная графическим интерфейсам и рассматривающая еще более крупные примеры, в которых применяются приемы и интерфейсы, демонстрировавшиеся во всех предшествующих главах, в которых говорилось о создании графических интерфейсов. В этих же двух главах примеры будут небольшими и самодостаточными, чтобы позволить сосредоточиться на особенностях виджетов.
Темы этой главы
Формально мы уже использовали ряд простых виджетов в главе 7. Пока мы познакомились с классами Label, Button, Frame и Tk и попутно изучили понятия управления компоновкой в методе pack. Несмотря на свою простоту, все эти классы достаточно полно представляют интерфейсы библиотеки tkinter в целом и служат рабочими лошадками в типичных графических интерфейсах. Например, контейнеры Frame служат основой иерархической структуры отображения.
В этой и следующей главах мы исследуем дополнительные параметры уже знакомых графических элементов и, отойдя от основ, расскажем об остальной части набора виджетов tkinter. Ниже перечислены некоторые виджеты и темы, которые будут рассматриваться в данной главе:
• Виджеты Toplevel и Tk
• Виджеты Message и Entry
• Виджеты Checkbutton, Radiobutton и Scale
• Изображения: объекты PhotoImage и BitmapImage
• Параметры настройки виджетов и окон
• Диалоги: стандартные и пользовательские
• Низкоуровневое связывание событий
• Объекты связанных переменных tkinter
• Использование библиотеки Python обработки изображений - расширения PIL (Python Imaging Library) - для работы с изображениями других типов
Глава 9 завершает краткий рассказ, представляя остальные элементы инструментария библиотеки tkinter: меню, текст, холсты, анимацию и другие.
Чтобы сделать этот обзор интереснее, я также попутно введу некоторые идеи повторного использования компонентов. Например, некоторые более поздние примеры будут написаны с использованием компонентов, реализованных для предыдущих примеров. Хотя эти две главы знакомят с интерфейсами, основанными на виджетах, тем не менее данная книга написана также о программировании на языке Python в целом -как будет показано, программирование с использованием библиотеки tkinter в сценариях на языке Python может быть значительно более содержательным, чем просто рисование кружков и стрелок.
Настройка внешнего вида виджетов
До сих пор все кнопки и метки в наших примерах выводились с оформлением по умолчанию, стандартном для соответствующей платформы. В Windows это обычно означает, что они выводятся серым цветом, как в цветовой схеме, установленной на моем компьютере. Однако библиотека tkinter позволяет придавать виджетам любой другой внешний вид с помощью ряда параметров настройки виджетов и компоновки.
Поскольку обычно я не могу устоять перед соблазном определить для виджетов в примерах собственные настройки, хочу осветить эту тему в самом начале обзора. В примере 8.1 приводятся некоторые параметры настройки, доступные в tkinter.
Пример 8.1. PP4E\Gui\Tour\config-label.py
from tkinter import * root = Tk()
labelfont = (‘times’, 20, ‘bold’) # семейство, размер, стиль widget = Label(root, text=’Hello config world’) widget.config(bg=’black’, fg=’yellow’) # желтый текст на черном фоне widget.config(font=labelfont) # использовать увеличенный шрифт
widget.config(height=3, width=20) # начальный размер: строк,символов
widget.pack(expand=YES, fill=BOTH) root.mainloop()
Запомните, что с помощью метода config виджета можно в любой момент переопределить значения его параметров, что позволяет не передавать их все конструктору объекта. В данном случае мы используем эту возможность, чтобы установить параметры, которые определяют окно, изображенное на рис. 8.1.
Рис. 8.1. Нестандартный внешний вид метки
Если запустить сценарий на компьютере (увы, я не могу показать здесь в цвете, как это выглядит), то вы увидите, что текст метки выводится желтым цветом на черном фоне, причем шрифт сильно отличается от того, что мы до сих пор видели. Этот сценарий настраивает следующие параметры отображения метки:
Цвет
Установкой параметра bg метки определяется черный цвет ее фона. Аналогично параметр fg изменяет цвет переднего плана (текста) метки на желтый. Эти параметры цвета присутствуют у большинства виджетов tkinter, и в них указывается простое название цвета (например, ‘blue’) или шестнадцатеричная строка. Поддерживается большинство знакомых названий цветов (если только вам не довелось работать для компании Crayola39). Чтобы более точно определить значение цвета, в этих параметрах можно также передавать строки с шестнадцатеричными значениями - они должны начинаться с символа # и содержать значения насыщенности красного, зеленого и голубого цветов с одинаковым количеством битов для каждого. Например, строка ‘#ff0000’ содержит по восемь битов для каждого цвета и определяет чистый красный цвет - «f» означает в шестнадцатеричном виде четыре единичных бита. Мы еще вернемся к шестнадцатеричному формату, когда встретимся с диалоговым окном выбора цвета далее в этой главе.
Размер
Для метки определяется точный размер в виде количества строк в высоту и символов в ширину путем установки параметров height и width. С помощью этих параметров можно увеличивать размеры метки по сравнению с теми, что устанавливаются менеджером компоновки по умолчанию.
Шрифт
В этом сценарии выбирается нестандартный шрифт для текста метки путем записи в параметр font кортежа из трех элементов, определяющих семейство шрифта, его размер и стиль (в данном случае: Times, 20 пунктов, полужирный). Стиль шрифта может принимать значения normal, bold, roman, italic, underline, overstrike и их сочетания (например, “bold italic”). Библиотека tkinter гарантирует возможность использования названий семейств шрифтов Times, Courier и Helvetica на всех платформах, однако в некоторых системах могут использоваться и другие (например, system - системный шрифт в Windows). Такие настройки шрифта будут действовать для всех виджетов, содержащих текст, например меток, кнопок, полей ввода, списков и Text (последний может одновременно выводить текст, отображаемый различными шрифтами, с помощью «тегов»). Параметр font сохраняет возможность определять шрифт с помощью более старых определений в стиле X Window - длинных строк с дефисами и звездочками, однако более новая форма определения параметров шрифта в виде кортежа более независима от платформы.
Параметры, компоновки
Наконец, метка может быть сделана расширяемой и растягиваемой в целом путем установки параметров компоновщика pack, таких как expand и fill, с которыми мы познакомились в предыдущей главе: метка увеличивается вместе с окном. При распахивании окна черный фон заполняет весь экран, а желтый текст помещается в центр -можете попробовать.
В данном сценарии итоговым результатом настроек является метка, по своему внешнему виду коренным образом отличающаяся от тех, что мы создавали до сих пор. Она больше не следует стандартам внешнего вида Windows, но такая согласованность не всегда важна. Для справки отмечу, что библиотека tkinter предоставляет дополнительные способы настройки внешнего вида, не используемые в данном сценарии, но которые могут встретиться вам в других сценариях:
Границы и рельефность
Параметр bd=N виджета можно использовать для установки ширины границы, а параметр relief=S - ее стиля. S может принимать значения FLAT, SUNKEN, RAISED, GROOVE, SOLID или RIDGE - все эти константы экспортирует модуль tkinter.
Курсор
Параметр cursor позволяет определять внешний вид указателя мыши при наведении его на виджет. Например, cursor=’gumby’ изменяет стрелку на фигурку зеленого человечка. В число других имен указателей, часто используемых в этой книге, входят watch, pencil, cross и hand2.
Состояние
Некоторые виджеты поддерживают понятие состояния, влияющее на их внешний вид. Например, виджет с параметром state=DISABLED обычно рисуется на экране закрашенным (окрашивается в серый цвет) и делается неактивным. Значение NORMAL делает его обычным. Некоторые виджеты поддерживают также состояние READONLY, когда сам виджет отображается, как обычно, но он никак не откликается на попытки изменения.
Отступы (padding)
Вокруг многих виджетов (кнопок, меток и текста) можно добавить дополнительное пустое пространство с помощью параметров padx=N и pady=N. Интересно, что эти параметры можно определять и в вызовах метода pack (тогда пустое пространство добавляется вокруг виджета в целом), и в самом объекте виджета (в результате увеличивается сам графический элемент).
Чтобы проиллюстрировать некоторые из этих дополнительных настроек, в примере 8.2 создается кнопка, изображенная на рис. 8.2, и изменяется форма указателя мыши, когда он помещается над кнопкой.
Пример 8.2. PP4E\Gui\Tour\config-button.py
from tkinter import *
widget = Button(text=’Spam’, padx=10, pady=10) widget.pack(padx=20, pady=20) widget.config(cursor=’gumby’)
widget.config(bd=8, relief=RAISED) widget.config(bg=’dark green’, fg=’white’) widget.config(font=(‘helvetica’, 20, ‘underline italic’)) mainloop()
Рис. 8.2. Параметры кнопки в действии
Чтобы увидеть эффект, создаваемый этими двумя параметрами, попробуйте поиграть с ними на своем компьютере. Большинству виджетов можно придать новый внешний вид таким же способом, и в этой книге мы будем неоднократно встречаться с такими параметрами. Мы встретимся также с операционными параметрами, такими как focus (передает фокуса ввода), и другими. У виджетов могут быть десятки параметров, большинство из которых имеет разумные значения по умолчанию, создающие принятый на каждой оконной платформе внешний вид, что является одной из причин простоты использования tkinter. Но при необходимости tkinter позволяет создавать значительно более индивидуальные изображения.
Дополнительные способы применения параметров настройки, обеспечивающих типичный внешний вид виджетов, можно увидеть в разделе «Настройка виджетов с помощью классов» в предыдущей главе и особенно в примерах ThemedButton. Теперь, когда вы больше знаете о настройках, вам будет проще понять, как настройки в этих примерах, выполняемые в подклассах виджетов, наследуются всеми экземплярами и подклассами. Новое расширение ttk, описываемое в главе 7, также реализует дополнительные способы настройки виджетов, вводя понятие тем оформления. Больше подробностей и ссылки на ресурсы, посвященные ttk, вы найдете в предыдущей главе.
Окна верхнего уровня
Графические интерфейсы, построенные на базе tkinter, всегда имеют корневое окно, которое создается по умолчанию или явно с помощью конструктора объекта Tk. Это главное корневое окно открывается при запуске программы и обычно служит для размещения наиболее важных виджетов. Помимо этого окна сценарии, использующие библиотеку tkinter, могут порождать любое число независимых окон, которые создаются и открываются по требованию, в результате создания объектов виджетов Toplevel.
Каждый объект Toplevel порождает на экране новое окно и автоматически добавляет его в поток обработки цикла событий программы (для активации новых окон не нужно вызывать метод mainloop). В примере 8.3 создается корневое окно и два дополнительных окна.
Пример 8.3. PP4E\Gui\Tour\toplevel0.py
import sys
from tkinter import Toplevel, Button, Label win1 = Toplevel() # два независимых окна
win2 = Toplevel() # являющихся частью одного и того же процесса
Button(win1, text=’Spam’, command=sys.exit).pack()
Button(win2, text=’SPAM’, command=sys.exit).pack()
Label(text=’Popups’).pack() # по умолчанию добавляется в корневое окно Tk() win1.mainloop()
Сценарий toplevel0 получает корневое окно по умолчанию (к которому прикрепляется метка Label, потому что для нее не указан родитель) и создает два самостоятельных окна Toplevel, которые появляются и действуют независимо от корневого окна, как показано на рис. 8.3.
Рис. 8.3. Два окна Toplevel и корневое окно
Два окна Toplevel в правой части являются полноценными окнами - они могут независимо сворачиваться, распахиваться на весь экран и так далее. Обычно окна Toplevel используются для реализации многооконных интерфейсов, а также модальных и немодальных диалогов (подробнее о диалогах рассказывается в следующем разделе). Они сохраняются до тех пор, пока не будут явно закрыты или пока создавшее их приложение не завершит работу.
Согласно реализации примера щелчок на кнопке с крестиком в правом верхнем углу любого из окон Toplevel закрывает только это окно. С другой стороны, щелчок на любой из кнопок или на крестике главного окна закроет все остальные и завершит программу (подробнее о протоколе завершения рассказывается чуть ниже).
Важно знать, что, хотя окна Toplevels и действуют независимо, они не являются независимыми процессами - если программа завершится, автоматически будут закрыты все ее окна, включая все окна Toplevel, которые она могла создать. Позднее будет показано, как обойти это правило путем запуска независимых программ с графическим интерфейсом.
Виджеты Toplevel и Tk
Окно Toplevel напоминает Frame тем, что отщепляется в самостоятельное окно и обладает дополнительными методами, позволяющими работать со свойствами окна верхнего уровня. Виджет Tk в общем похож на виджет Toplevel, но используется для представления корневого окна приложения. Окна Toplevel имеют родителя, тогда как окно Tk - нет. Оно является настоящим корнем иерархии виджетов, создаваемых при конструировании графических интерфейсов с помощью библиотеки tkinter.
В примере 8.3 корневое окно Tk было получено даром, потому что для виджета Label был использован родитель по умолчанию, назначаемый при отсутствии первого аргумента в вызове конструктора:
Label(text=’Popups’).pack() # корневое окно Tk() по умолчанию
Передача значения None в первом аргументе конструктора виджета (или в именованном аргументе master) также приводит к назначению родителя по умолчанию. В других сценариях корневое окно Tk создается явно, например:
root = Tk()
Label(root, text=’Popups’).pack() # явное создание корневого окна Tk() root.mainloop()
В действительности, из-за того, что графические интерфейсы tkinter строятся в виде иерархии, по умолчанию всегда создается хотя бы одно корневое окно Tk, явно, как в данном примере, или нет. Хотя это и не типично, тем не менее в приложении вручную может создаваться несколько корневых окон Tk, при этом программа завершается только после закрытия всех окон Tk. Первое созданное корневое окно Tk - явно, в программном коде, или автоматически, интерпретатором, - используется как родитель по умолчанию для виджетов и других окон, при создании которых родитель не указывается.
В целом корневое окно Tk должно использоваться для отображения какой-либо информации верхнего уровня. Если не прикрепить графические элементы к корневому окну, при запуске сценария оно будет выведено как странное пустое окно (часто это происходит из-за забывчивости, когда программист создает виджеты, использующие родителя по умолчанию, но забывает вызвать метод компоновщика, выполняющий размещение виджетов). Технически можно подавить создание корневого окна по умолчанию и создать несколько корневых окон с помощью виджета Tk, как показано в примере 8.4.
Пример 8.4. PP4E\Gui\Tour\toplevel1.py
import tkinter
from tkinter import Tk, Button tkinter.NoDefaultRoot()
win1 = Tk() # два независимых корневых окна
win2 = Tk()
Button(win1, text=’Spam’, command=win1.destroy).pack()
Button(win2, text=’SPAM’, command=win2.destroy).pack() win1.mainloop()
Если запустить этот сценарий, он создаст только два окна, изображенные на рис. 8.3 (третье корневое окно не будет создано). Но чаще корневой объект Tk используется как главное окно, а виджеты Toplevel - как всплывающие окна приложения.
Обратите внимание: чтобы закрыть только одно окно, вместо функции sys.exit, которая завершает работу всей программы, вызывается метод destroy этого окна - чтобы понять, как действует этот метод, перейдем к изучению протоколов окна.
Протоколы окна верхнего уровня
Виджеты Tk и Toplevel экспортируют дополнительные методы и свойства, предназначенные для той роли, которую они играют на верхнем уровне, что иллюстрируется примером 8.5.
Пример 8.5. PP4E\Gui\Tour\toplevel2.py
Открывает три новых окна со стилями
метод destroy() закрывает одно окно, метод quit() закрывает все окна и завершает
приложение (прерывает работу функции mainloop);
окна верхнего уровня имеют заголовки, значки, могут сворачиваться
и восстанавливаться и поддерживают протокол событий wm;
приложение всегда имеет корневое окно, создаваемое по умолчанию или явно,
вызовом конструктора Tk(); все окна верхнего уровня являются контейнерами,
но они никогда не размещаются с помощью менеджера компоновки; объект Toplevel
напоминает фрейм Frame, но в действительности является новым окном и может иметь
собственное меню;
from tkinter import * root = Tk() # explicit root
trees = [(‘The Larch!’, ‘light blue’),
(‘The Pine!’, ‘light green’),
(‘The Giant Redwood!’, ‘red’)]
for (tree, color) in trees:
win = Toplevel(root) # новое окно
win.title(‘Sing...’) # установка границ
win.protocol(‘WM_DELETE_WINDOW’, lambda:None) # игнорировать закрытие
win.iconbitmap(‘py-blue-trans-out.ico’) # вместо значка Tk
msg = Button(win, text=tree, command=win.destroy) # закрывает одно окно
msg.pack(expand=YES, fill=BOTH) msg.config(padx=10, pady=10, bd=10, relief=RAISED) msg.config(bg=’black’, fg=color, font=(‘times’, 30, ‘bold italic’))
root.title(‘Lumberjack demo’)
Label(root, text=’Main window’, width=30).pack()
Button(root, text=’Quit All’, command=root.quit).pack() # завершает программу root.mainloop()
Эта программа добавляет виджеты в корневое окно Tk, сразу выводит три окна Toplevel с прикрепленными к ним кнопками и использует специальные протоколы верхнего уровня. Если запустить этот пример, он создаст картинку, переданную в черно-белом изображении на рис. 8.4 (на мониторе текст кнопок отображается синим, зеленым и красным цветом).
Рис. 8.4. Три настроенных окна Toplevel
Здесь следует отметить несколько деталей, касающихся функционирования, которые станут более заметными, если вы запустите сценарий на своем компьютере:
Перехват закрытия: protocol
Этот сценарий перехватывает событие закрытия окна менеджера окон с помощью метода виджета верхнего уровня protocol, поэтому при нажатии кнопки X в правом верхнем углу какого-либо из трех окон Toplevel ничего не происходит. Строка WM_DELETE_WINDOW обозначает операцию закрытия. С помощью этого метода можно запретить закрытие окон, кроме как из создаваемых в сценарии виджетов. Создаваемая этим сценарием функция lambda: None лишь возвращает значение None и больше ничего не делает.
Закрытие одного окна (и его дочерних окон): destroy
При нажатии на большую черную кнопку в любом из трех дополнительных окон закрывается только это окно, потому что это действие вызывает метод destroy виджета. Остальные окна продолжают существовать, как это свойственно диалоговым окнам. Технически вызов этого метода приводит к уничтожению соответствующего виджета и всех остальных виджетов, для которых он является родителем. В случае окон под этим подразумевается все их содержимое. В случае более простых виджетов метод destroy уничтожает сам виджет.
Вследствие того, что окна Toplevel имеют родителя, эти их отношения могут иметь последствия при применении метода destroy. Уничтожение окна, даже первого корневого окна Tk, созданного автоматически или явно, - которое является родителем по умолчанию, -приводит к уничтожению всех его дочерних окон. Так как корневые окна Tk не имеют родителя, на них никак не действует уничтожение других окон. При этом уничтожение последнего (или единственного) корневого окна Tk приводит к завершению программы. Окна Toplevel всегда уничтожаются при уничтожении родителя, но их уничтожение никак не влияет на другие окна, для которых они не являются предками. Это делает их идеальными для создания диалогов. Технически виджет Toplevel может быть дочерним по отношению к любому виджету и автоматически будет уничтожен вместе с родителем, однако обычно они создаются как потомки окна Tk, созданного явно или автоматически.
Закрытие всех окон: quit
Чтобы закрыть сразу все окна и завершить приложение с графическим интерфейсом (в действительности - активный вызов mainloop), кнопка корневого окна вызывает метод quit. То есть нажатие кнопки в корневом окне завершает работу приложения. Метод quit немедленно завершает приложение в целом и закрывает все его окна. Он может быть вызван относительно любого виджета tkinter, а не только относительно окна верхнего уровня - этот метод имеется также у фреймов, кнопок и других виджетов. Дополнительные подробности о методах quit и destroy вы найдете в обсуждении метода bind и его события далее в этой главе.
Заголовки окон: title
В главе 7 говорилось о методе title виджетов окон верхнего уровня (Tk и Toplevel), позволяющем изменять текст, выводимый в области верхней кромки окна. В данном случае в качестве текста заголовка окна устанавливается строка ‘Si...’, замещающая текст по умолчанию ‘tk’.
Значки окон: iconbitmap
Метод iconbitmap изменяет значок окна верхнего уровня. Он принимает значок или файл с растровым изображением и использует его в качестве графического значка окна, когда оно сворачивается и открывается. Если в Windows передать имя файла с расширением .ico (в данном примере используется такой файл, находящийся в текущем каталоге), он заменит значок по умолчанию с красными буквами «Tk», который обычно появляется в левом верхнем углу окна, а также в панели задач Windows. На других платформах вам может потребоваться использовать иные соглашения о файлах со значками, если вызов этого метода в наших примерах не дает желаемого результата (или просто закомментируйте вызов этого метода, если он приводит к аварийному завершению сценариев) - значки обычно являются платформозависимой особенностью, работа с ними зависит от используемого менеджера окон.
Управление компоновкой
Окна верхнего уровня служат контейнерами для других виджетов, подобно отдельному фрейму Frame. Однако в отличие от фреймов, виджеты - окна верхнего уровня - сами не компонуются (и не размещаются каким-либо другим менеджером компоновки). Для встраивания виджетов этот сценарий передает свои окна в аргументах, определяющих родительское окно, конструкторам меток и кнопок.
Имеется также возможность определять максимальный размер окна (физические размеры экрана в виде кортежа [ширина, высота]) с помощью метода maxsize() и устанавливать начальные размеры окна с помощью высокоуровневого метода geometry(" width x height + x + y "). На практике гораздо проще и удобнее позволить библиотеке tkinter (или вашим пользователям) самой устанавливать размер окон, тем не менее размер экрана может пригодиться при выборе масштаба отображения изображений (смотрите обсуждение PyPhoto в главе 11, например).
Кроме того, графические элементы окон верхнего уровня поддерживают другие типы протоколов, которые будут позднее использованы в данном обзоре:
Состояние
Методы iconify и withdraw объектов окон верхнего уровня позволяют сценариям сворачивать или удалять окна на лету; метод deiconify перерисовывает свернутое или удаленное окно. Метод state возвращает или изменяет состояние окна - допустимыми значениями, которые могут устанавливаться или возвращаться, являются: iconic, withdrawn, zoomed (в Windows: распахнутое на весь экран с помощью geometry или какого-либо другого метода) и normal (достаточно большого размера, чтобы вместить все содержимое). Методы lift и lower поднимают или опускают окно относительно других (метод lift является аналогом команды raise библиотеки Tk, которое является зарезервированным словом в языке Python). Их использование демонстрируется в сценариях будильника в конце главы 9.
Меню
Каждое окно верхнего уровня может иметь собственное меню - виджеты Tk и Toplevel принимают параметр menu, который используется для подключения горизонтальной строки меню с открывающимися списками элементов выбора. Эта строка меню выглядит соответствующим образом на каждой платформе, где выполняется сценарий. Меню будут изучаться в начале главы 9.
Большую часть методов окна верхнего уровня, используемых для взаимодействия с менеджером окон, можно также вызывать под именами с префиксом «wm_». Например, методы state и protocol можно также вызвать как wm_state и wm_protocol.
Обратите внимание, что в примере 8.3 при вызове конструктора Toplevel ему явно передается родительский виджет - корневое окно Tk (то есть Toplevel(root)). Окна Toplevel можно связывать с родительскими, как и любые другие виджеты, хотя зрительно они не встраиваются в родительские окна. Такой способ написания сценария имел целью избежать одной, на первый взгляд странной, особенности. Если бы окно создавалось так:
win = Toplevel() # новое окно
и корневое окно Tk при этом еще не существовало бы, этот вызов создал бы корневое окно Tk по умолчанию, которое стало бы родителем для окон Toplevel, как при всяком другом вызове графического элемента без передачи аргумента со ссылкой на родителя. Проблема в том, это делает принципиальным местоположение следующей строки:
root = Tk() # явное создание корня
Если поместить эту строку выше вызовов конструктора Toplevel, она создаст одно корневое окно, как и предполагается. Но если поставить эту строку ниже вызовов Toplevel, то tkinter создаст корневое окно Tk, которое будет отлично от созданного сценарием при явном вызове Tk. Это приведет к созданию двух корневых окон Tk, как в примере 8.4. Переместите вызов Tk под вызовы Toplevel, перезапустите сценарий, и вы увидите, что я имею в виду - вы получите четвертое, совершенно пустое окно! Чтобы избежать таких странностей, возьмите за правило создавать корневые окна Tk в начале сценариев и явным образом.
Все интерфейсы протоколов верхнего уровня доступны только в виджетах окон верхнего уровня, но часто доступ к ним можно получить через атрибут master виджета, хранящего ссылку на родительское окно. Например, изменение заголовка окна, в котором содержится фрейм, можно реализовать так:
theframe.master.title(‘Spam demo’) # master является окном-контейнером
Естественно, делать так можно только при уверенности, что фрейм будет использован только в одном типе окна. Например, прикрепляемые компоненты общего назначения, реализуемые в виде классов, должны оставить право на установку свойств окон за своим приложениями-клиентами.
Для виджетов верхнего уровня существуют другие инструменты, некоторые из которых могут не встретиться в этой книге. Например, в менеджерах окон Unix можно также устанавливать имя значка окна (iconname). Поскольку некоторые параметры значков можно применять только в сценариях, выполняемых в Unix, подробности, касающиеся этой темы, смотрите в других ресурсах по библиотекам Tk и tkinter. А сейчас нас ожидает следующая запланированная остановка в нашей экскурсии, где будет рассказано об одном из наиболее частых применений окон верхнего уровня.
Диалоги
Диалоги - это окна, выводимые сценарием с целью показать или запросить дополнительную информацию. Существует два вида диалогов: модальные и немодальные:
Модальные
Эти диалоги блокируют остальную часть интерфейса, пока окно диалога не будет закрыто - выполнение программы будет продолжено после получения диалогом ответа пользователя.
Немодальные
Эти диалоги могут оставаться на экране неопределенное время, не создавая помех другим окнам интерфейса, - обычно они в любой момент могут принимать входные данные.
Независимо от модальности диалоги обычно реализуются с помощью объекта окна Toplevel, с которым мы познакомились в предыдущем разделе, создаете вы Toplevel или нет. Существует три основных способа вывести диалог с помощью библиотеки tkinter: вызовом стандартных диалогов, обращением к современному объекту Dialog и путем создания пользовательских диалоговых окон с помощью Toplevel и других типов виджетов. Рассмотрим основы использования всех трех схем.
Стандартные (типичные) диалоги
Вызовы стандартных диалогов проще, поэтому начнем с них. В составе библиотеки tkinter поставляется набор готовых диалогов, реализующих многие из наиболее часто встречающихся окон, генерируемых программами, - диалоги выбора файла, диалоги с сообщениями об ошибках и предупреждениями и диалоги, позволяющие запросить ввод данных. Они называются стандартными диалогами, поскольку входят в состав библиотеки tkinter и используют библиотечные вызовы для конкретных платформ, чтобы принять вид, свойственный данной платформе. Например, диалог открытия файла в библиотеке tkinter выглядит как любой другой подобный диалог в Windows.
Все стандартные диалоги являются модальными (они не возвращают управление, пока пользователь не закроет диалог) и блокируют главное окно программы. Сценарии могут настраивать окна этих диалогов, передавая текст сообщения, заголовки и тому подобное. Они очень просты в использовании, поэтому сразу перейдем к примеру 8.6 (который хранится в файле с расширением .pyw, чтобы подавить вывод окна консоли в Windows при запуске сценария щелчком мыши):
Пример 8.6. PP4E\Gui\Tour\dlg1.pyw
from tkinter import *
from tkinter.messagebox import *
def callback():
if askyesno(‘Verify’, ‘Do you really want to quit?’): showwarning(‘Yes’, ‘Quit not yet implemented’) else:
showinfo(‘No’, ‘Quit has been cancelled’)
errmsg = ‘Sorry, no Spam allowed!’
Button(text=’Quit’, command=callback).pack(fill=X)
Button(text=’Spam’, command=(lambda: showerror(‘Spam’, errmsg))).pack(fill=X) mainloop()
Анонимная lambda-функция использована здесь в качестве оболочки вызова showerror, для передачи двух жестко определенных аргументов (напомню, что обработчики событий не получают аргументов от самой библиотеки tkinter). Если запустить этот сценарий, он создаст главное окно, изображенное на рис. 8.5.
Нажатие кнопки Quit в этом окне выводит диалог (рис. 8.6) - вызовом стандартной функции askyesno из модуля messagebox, входящего в состав пакета tkinter. В Unix и Macintosh этот диалог выглядит иначе, а в Windows выглядит, как показано на рисунке (на практике внешний вид диалога зависит от версии и настроек Windows - в моей системе Window 7 с настройками по умолчанию он выглядит несколько иначе, чем в Windows XP, как было показано в предыдущем издании).
Рис. 8.5. Главное окно dlg1: кнопки вызывают появление дополнительных окон
Диалог на рис. 8.6 блокирует программу, пока пользователь не щелкнет по одной из кнопок - при выборе кнопки Yes (или нажатии клавиши Enter) вызов диалога возвращает значение True, и сценарий выводит стандартный диалог showwarning (рис. 8.7), вызывая функцию showwarning.
Рис. 8.6. Диалог askyesno, выводимый сценарием dlg1 (в Windows 7)
Рис. 8.7. Диалог showwarning, выводимый сценарием dlg1
В диалоге на рис. 8.7 пользователь может только нажать кнопку OK. Если щелкнуть на кнопке No в диалоге на рис. 8.6, вызов showinfo создаст соответствующее окно диалога (рис. 8.8). Наконец, если в главном окне щелкнуть по кнопке Spam, то с помощью стандартного вызова show-error будет создан стандартный диалог showerror (рис. 8.9).
Рис. 8.8. Диалог showinfo, выводимый сценарием dlg1
Рис. 8.9. Диалог showerror, выводимый сценарием dlg1
Конечно, в результате создается множество всплывающих окон, и не следует злоупотреблять этими диалогами (обычно лучше применять окна с полями ввода, остающиеся на экране длительное время, а не отвлекать пользователя всплывающими окнами). Но в нужных случаях такие всплывающие диалоги сокращают время разработки и обеспечивают привычный внешний вид.
«Умная» и многократно используемая кнопка Quit
Для некоторых из этих готовых диалогов можно найти лучшее применение. В примере 8.7 реализована прикрепляемая кнопка Quit, которая с помощью стандартных диалогов получает подтверждение в ответ на запрос о завершении. Поскольку она реализована в виде класса, ее можно прикреплять и повторно использовать в любом приложении, где требуется кнопка Quit с запросом на подтверждение. Так как в этой кнопке использованы стандартные диалоги, она должным образом выглядит на любой платформе.
Пример 8.7. PP4E\Gui\Tour\quitter.py
кнопка Quit, которая запрашивает подтверждение на завершение;
для повторного использования достаточно прикрепить экземпляр к другому
графическому интерфейсу и скомпоновать с желаемыми параметрами
from tkinter import * # импортировать классы виджетов
from tkinter.messagebox import askokcancel # импортировать стандартный диалог
class Quitter(Frame): # подкласс графич. интерфейса
def __init__(self, parent=None): # метод конструктора
Frame.__init__(self, parent)
self.pack()
widget = Button(self, text=’Quit’, command=self.quit) widget.pack(side=LEFT, expand=YES, fill=BOTH)
def quit(self):
ans = askokcancel(‘Verify exit’, "Really quit?”) if ans: Frame.quit(self)
if __name__ == ‘__main__’: Quitter().mainloop()
Вообще этот модуль предназначен для использования в других программах, но может запускаться самостоятельно и тогда выводит кнопку, которая в нем реализована. На рис. 8.10 слева вверху показана сама кнопка Quit и диалог askokcancel запроса подтверждения, выведенный при нажатии кнопки Quit.
Рис. 8.10. Модуль Quitter с диалогом askokcancel
Если нажать кнопку OK в этом окне, модуль Quitter вызовет метод quit элемента Frame и закроет графический интерфейс, к которому прикреплена кнопка (на самом деле завершит работу функции mainloop). Но чтобы действительно оценить пользу, приносимую такими подпружиненными кнопками, рассмотрим графический интерфейс клиента, приведенный в следующем разделе.
Панель запуска демонстрации диалогов
Пока мы увидели лишь несколько стандартных диалогов, но их число значительно больше. Не станем показывать их на серых снимках с экрана, а напишем на языке Python демонстрационный сценарий, который будет генерировать их по требованию. Ниже приводится один из способов сделать это. Во-первых, напишем модуль, приведенный в примере 8.8, который определяет таблицу соответствий между именами демонстрационных программ и вызовами стандартных диалогов (будем использовать lambda-выражения для обертывания вызовов вызова, если функции диалога нужно передать дополнительные аргументы).
Пример 8.8. PP4E\Gui\Tour\dialogTable.py
# определяет таблицу имя:обработчик с демонстрационными примерами
from tkinter.filedialog import askopenfilename # импортировать стандартные from tkinter.colorchooser import askcolor # диалоги из Lib\tkinter
from tkinter.messagebox import askquestion, showerror from tkinter.simpledialog import askfloat
demos = {
‘Open’: askopenfilename,
‘Color’: askcolor,
‘Query’: lambda: askquestion(‘Warning’, ‘You typed "rm *”\nConfirm?’), ‘Error’: lambda: showerror(‘Error!’, "He’s dead, Jim”),
‘Input’: lambda: askfloat(‘Entry’, ‘Enter credit card number’)
}
Я поместил эту таблицу в модуль, чтобы использовать ее в качестве основы будущих демонстрационных сценариев (работать с диалогами веселее, чем выводить текст в stdout). Затем напишем сценарий на языке Python, представленный в примере 8.9, который просто генерирует кнопки для всех этих элементов таблицы - использует ее ключи как метки кнопок, а значения как обработчики событий для кнопок.
Пример 8.9. PP4E\Gui\Tour\demoDlg.py
"создает панель с кнопками, которые вызывают диалоги”
from tkinter import * # импортировать базовый набор виджетов
from dialogTable import demos # обработчики событий для кнопок from quitter import Quitter # прикрепить к себе объект quit
class Demo(Frame):
def __init__(self, parent=None, **options):
Frame.__init__(self, parent, **options)
self.pack()
Label(self, text=”Basic demos”).pack() for (key, value) in demos.items():
Button(self, text=key, command=value).pack(side=TOP, fill=BOTH)
Quitter(self).pack(side=TOP, fill=BOTH)
if __name__ == ‘__main__’: Demo().mainloop()
Если запустить этот пример как самостоятельный сценарий, он создаст окно, изображенное на рис. 8.11: это панель демонстрационных кнопок, при нажатии которых просто выполняется передача управления в соответствии со значениями в таблице из модуля dialogTable.
Рис. 8.11. Главное окно demoDlg
Обратите внимание, что этот сценарий управляется содержимым словаря из модуля dialogTable, поэтому мы можем изменять набор кнопок, изменяя только dialogTable (никакого выполняемого программного кода в demoDlg менять не нужно). Отметьте также, что кнопка Quit является в данном случае прикрепленным экземпляром класса Quitter из предыдущего раздела, причем она скомпонована с теми же параметрами, что и остальные кнопки, - по крайней мере эту часть программного кода уже не нужно будет писать снова.
Кроме всего прочего этот класс обеспечивает передачу любых именованных аргументов **options конструктору своего суперкласса Frame. Хотя в данном примере эта возможность и не используется, тем не менее вызывающие программы могут передавать параметры настройки во время создания экземпляра (Demo(o=v)), вместо того чтобы выполнять настройку позднее (d.config(o=v)). В этом нет особой необходимости, но такая реализация обеспечивает возможность использования класса Demo как обычного виджета фрейма (в чем, собственно, и заключается прием создания подклассов). Позднее мы увидим, как можно использовать эту особенность.
Мы уже видели некоторые диалоги, запускаемые другими кнопками этой демонстрационной панели, поэтому я коснусь здесь только новых.
Например, нажатие кнопки Query генерирует стандартный диалог, изображенный на рис. 8.12.
Этот диалог askquestion выглядит как askyesno, который мы видели раньше, но в действительности возвращает строку "yes” или "no” (askyesno и askokcancel возвращают True или False). Нажатие кнопки Input генерирует стандартный диалог askfloat, изображенный на рис. 8.13.
Рис. 8.12. Запрос demoDlg, диалог askquestion
Рис. 8.13. Ввод demoDlg, диалог askfloat
Прежде чем вернуть управление, этот диалог автоматически проверяет введенные данные на соответствие синтаксису записи чисел с плавающей точкой; он является представителем группы диалогов ввода одного значения (помимо askinteger и askstring, предлагающих ввести целое число и строку). Он возвращает введенные данные как объект числа с плавающей точкой (а не строку) при нажатии кнопки OK и клавиши Enter, либо объект Python None, если пользователь щелкнет на кнопке CanceL. Два родственных ему диалога возвращают объекты целого числа и строки.
При нажатии кнопки Open мы получаем стандартный диалог открытия файла, создаваемый вызовом функции askopenfilename и изображенный на рис. 8.14. Это внешний вид в Windows 7 - в Mac OS, Linux и в более старых версиях Windows этот диалог может выглядеть совершенно иначе.
Рис. 8.14. Открытие файла в demoDlg, диалог askopenfilename
Аналогичный диалог выбора имени сохраняемого файла создается вызовом функции asksaveasfilename (пример можно найти в разделе, посвященном виджету Text, в главе 9). Оба файловых диалога дают пользователю возможность перемещаться по файловой системе для выбора нужного имени файла, которое возвращается вместе с полным путем к файлу при нажатии кнопки Open; если была нажата кнопка Cancel, возвращается пустая строка. Оба диалога поддерживают дополнительные протоколы, не показанные в этом примере:
• Им можно передать именованный аргумент filetypes - группу шаблонов имен для выбора файлов, появляющихся в раскрывающемся списке в нижней части диалога.
• Им можно передать параметры initialdir (начальный каталог), ini-tialfile (для поля ввода File name), title (заголовок окна диалога), de-faultextension (расширение, добавляемое, когда у выбранного файла нет расширения) и parent (для отображения в виде встроенного дочернего элемента, а не всплывающего диалога).
• Можно заставить их запомнить последний выбранный каталог путем использования экспортированных объектов вместо этих вызовов функций - эту особенность мы будем использовать в последующих примерах.
В модуле filedialog, в библиотеке tkinter, имеется еще один часто используемый диалог, вызываемый функцией askdirectory, который может использоваться, чтобы дать пользователю возможность выбрать каталог. Он выводит структуру каталогов в виде дерева - пользователь может перемещаться по этому дереву и выбирать нужный ему каталог. Эта функция принимает именованные аргументы, включая initialdir и title. Для сохранения имени последнего выбранного каталога, который будет автоматически открыт при следующем вызове диалога, можно использовать соответствующий объект Directory.
Большинство из этих интерфейсов позднее будут использованы в книге, особенно для реализации диалогов выбора файлов в приложении PyEdit, в главе 11, но вы можете, забежав вперед, узнать дополнительные подробности прямо сейчас. Диалог выбора каталога будет показан в примере приложения PyPhoto, в главе 11, и в примере приложения PyMailGUI, в главе 14 - опять же, вы можете забежать вперед, чтобы посмотреть примеры программного кода и снимки с экрана.
Наконец, кнопка Color вызывает стандартную функцию askcolor, которая генерирует стандартный диалог выбора цвета, изображенный на рис. 8.15.
Рис. 8.15. Выбор цвета в demoDlg, диалог askcolor
При нажатии в нем кнопки OK возвращается структура данных, идентифицирующая выбранный цвет, которую можно использовать в любом контексте tkinter, где требуется указать цвет. В нее входят значения RGB и шестнадцатеричная строка цвета (например, ((160, 160, 160), #a0a0a0)). Подробнее об использовании этого набора будет рассказываться несколько позже. При нажатии кнопки Cancel диалог возвращает кортеж, состоящий из двух значений None.
Вывод результатов, возвращаемых диалогами, и передача данных обработчикам с помощью lambda-выражений
Демонстрационная панель запуска диалогов выводит стандартные диалоги и может быть использована для вывода других диалогов простым изменением импортируемого модуля dialogTable. Однако в существующем виде этот пример только показывает диалоги, и было бы неплохо посмотреть на возвращаемые ими значения, чтобы знать, как использовать их в сценариях. В примере 8.10 добавлен вывод результатов стандартных диалогов в стандартный поток вывода stdout.
Пример 8.10. PP4E\Gui\Tour\demoDlg-print.py
то же, что и предыдущий пример, но выводит значения, возвращаемые диалогами; lambda-выражение сохраняет данные из локальной области видимости для передачи их обработчику (обработчик события нажатия кнопки обычно не получает аргументов, а автоматические ссылки в объемлющую область видимости некорректно работают с переменными цикла) и действует подобно вложенной инструкции def, такой как: def func(key=key): self.printit(key)
from tkinter import * # импортировать базовый набор виджетов
from dialogTable import demos # обработчики событий от кнопок
from quitter import Quitter # прикрепить к себе объект quit
class Demo(Frame):
def __init__(self, parent=None):
Frame.__init__(self, parent)
self.pack()
Label(self, text=”Basic demos”).pack() for key in demos:
func = (lambda key=key: self.printit(key))
Button(self, text=key, command=func).pack(side=TOP, fill=BOTH) Quitter(self).pack(side=TOP, fill=BOTH)
def printit(self, name):
print(name, ‘returns =>’, demos[name]()) # извлечь, вызвать, вывести
if __name__ == ‘__main__’: Demo().mainloop()
Этот сценарий создает то же самое главное окно панели кнопок, но обратите внимание, что обработчик события теперь является анонимной функцией, созданной с помощью lambda-выражения, а не прямой ссылкой на вызов диалога в словаре demos, импортированном из модуля
dialogTable:
# задействовать поиск значения в объемлющей области видимости func = (lambda key=key: self.printit(key))
Мы уже говорили о такой возможности в предыдущей главе, но здесь мы впервые использовали lambda-выражение подобным образом, поэтому разберемся в том, что происходит. Так как обработчики событий нажатий кнопок вызываются без аргументов, то при необходимости передать обработчику дополнительные данные для него нужно создать оболочку в виде объекта, который запомнит эти дополнительные данные и передаст их фактическому обработчику. В данном случае при нажатии кнопки вызывается функция, создаваемая lambda-выражением, -промежуточная функция, сохраняющая информацию из объемлющей области видимости. Благодаря этому действительный обработчик, printit, получит дополнительный аргумент name и выполнит действия, связанные с нажатой кнопкой, несмотря на то, что этот аргумент не был передан самой библиотекой tkinter. Фактически lambda-выражение сохраняет и передает информацию о состоянии.
Заметьте, однако, что в теле функции, создаваемой этим lambda-выражением, используются ссылки на значения self и key, находящиеся в объемлющей области видимости. Во всех последних версиях Python ссылка на self действует автоматически, в соответствии с правилами поиска значений в объемлющих областях видимости, но значение key необходимо передать явно, в виде аргумента со значением по умолчанию, иначе все функции, сгенерированные lambda-выражением, получат одно и то же значение - которое получит переменная key в последней итерации цикла. Как мы узнали в главе 7, ссылки на переменные в объемлющей области видимости разрешаются в момент вызова вложенной функции, а ссылки на значения по умолчанию - в момент создания вложенной функции. Так как значение self не изменится после создания функции, мы можем довериться правилам поиска только этого имени, но не переменной цикла key.
В прежних версиях Python требовалось явно передавать любые значения из объемлющей области видимости в виде аргументов со значениями по умолчанию, используя любой из двух следующих приемов:
# использовать простые аргументы со значениями по умолчанию
func = (lambda self=self, name=key: self.printit(name))
# использовать связанный метод по умолчанию
func = (lambda handler=self.printit, name=key: handler(name))
В настоящее время для получения значения self можно использовать более простой прием автоматических ссылок в объемлющую область видимости, однако для передачи значения переменной key по-прежнему требуется использовать значение по умолчанию аргумента (а кроме того, передачу данных в виде значений по умолчанию можно встретить в давно написанных сценариях на языке Python).
Обратите внимание, что круглые скобки вокруг lambda-выражений здесь не являются обязательными - я добавляю их, потому что предпочитаю визуально отделять lambda-выражения от окружающего программного
кода (ваши предпочтения могут отличаться от моих). Отметьте также, что здесь lambda-выражение можно заменить вложенной инструкцией def. Однако в отличие от инструкции def lambda-выражение может появляться внутри вызова конструктора Button, потому что это выражение и ему не требуется присваивать имя. Следующие две формы совершенно равноценны:
for (key, value) in demos.items():
func = (lambda key=key: self.printit(key)) # может вкладываться в вызов
# Button()
for (key, value) in demos.items():
def func(key=key): self.printit(key) # а инструкция def - нет
Здесь можно также использовать вызываемый объект класса, который сохраняет состояние в виде атрибутов экземпляра (смотрите подсказку в учебном примере__call__главы 7). Но как правило, если нужно, что
бы результат lambda-выражения в последующих вызовах использовал переменные из объемлющей области, просто используйте их имена и позвольте интерпретатору самому сохранять значения для последующего использования или передайте их в качестве значений по умолчанию, чтобы обеспечить сохранение значений на этапе создания функции. Последний способ необходим, только если используемая переменная может изменить значение перед тем, как произойдет вызов обработчика.
Если запустить этот сценарий, он создаст то же окно (рис. 8.11) и дополнительно будет выводить значения, возвращаемые диалогами, в стандартный поток вывода. Ниже приводится вывод сценария после щелчков мышью на всех кнопках в главном окне и выбора в каждом диалоге обеих кнопок Cancel/No и OK/Yes:
C:\...\PP4E\Gui\Tour> python demoDlg-print.py
Color returns => (None, None)
Color returns => ((128.5, 1 28.5, 255.99609375), ‘ #8080ff’)
Query returns => no Query returns => yes Input returns => None Input returns => 3.14159 Open returns =>
Open returns => C:/Users/mark/Stuff/Books/4E/PP4E/dev/Examples/PP4E/Launcher.py Error returns => ok
Теперь, когда были показаны результаты вызова всех диалогов, я хочу продемонстрировать фактическое использование одного из них.
Предоставление возможности динамического выбора цвета
Стандартный диалог выбора цвета - это не украшение ради украшения. Сценарии могут передавать возвращаемую этим диалогом шестнадцатеричную строку цветов в уже знакомые нам параметры bg и fg настройки цветов виджетов. То есть параметры bg и fg принимают имя цвета (например, blue) и шестнадцатеричные строки со значениями насыщенности цветов RGB, возвращаемые функцией askcolor, которые начинаются с # (например, #8080ff из последней строки вывода в предыдущем разделе).
Это добавляет новое измерение в модификацию графических интерфейсов на базе tkinter: вместо того чтобы жестко определять значения цветов в создаваемых интерфейсах, можно создать кнопку, выводящую диалог выбора цвета, с помощью которой пользователи смогут осуществлять настройку цветов на лету. Нужно просто передать строку цвета методу config в обработчиках событий, как показано в примере 8.11.
Пример 8.11. PP4E\Gui\Tour\setcolor.py
from tkinter import *
from tkinter.colorchooser import askcolor
def setBgColor():
(triple, hexstr) = askcolor() if hexstr:
print(hexstr)
push.config(bg=hexstr)
root = Tk()
push = Button(root, text=’Set Background Color’, command=setBgColor) push.config(height=3, font=(‘times’, 20, ‘bold’)) push.pack(expand=YES, fill=BOTH) root.mainloop()
Этот сценарий создает окно, изображенное на рис. 8.16 (фон его кнопки зеленоватый, и вам придется поверить мне на слово). Нажатие кнопки выводит диалог выбора цвета, который мы видели выше. Цвет, выбранный в этом окне, становится цветом фона этой кнопки после нажатия кнопки OK в диалоге.
Рис. 8.16. Главное окно setcolor
Строки со значениями цвета также выводятся в поток stdout (окно консоли). Запустите этот сценарий на своем компьютере и поэкспериментируйте с возможными настройками цветов:
C:\...\PP4E\Gui\Tour> python setcolor.py
#0080c0
#408080
#77d5df
Другие стандартные диалоги
Мы уже видели большую часть стандартных диалогов, и мы будем пользоваться ими в примерах на протяжении оставшейся части книги. Если нужны дополнительные сведения о других имеющихся диалогах и параметрах, обращайтесь к другой документации по библиотеке tkinter или просмотрите исходные тексты модулей, используемых в начале модуля dialogTable, представленного в примере 8.8, - все они являются обычными файлами с программным кодом на языке Python, установленными на вашем компьютере в подкаталоге tkinter стандартной библиотеки Python (например, в каталоге C:\Python31\Lib, в Windows). И сохраните этот пример с демонстрационной панелью на будущее - мы снова воспользуемся им позднее, когда встретимся с другими виджетами, похожими на кнопки.
Модуль диалогов в старом стиле
В более старом программном коде на языке Python можно иногда увидеть диалоги, реализованные с использованием стандартного модуля dialog. Сейчас он несколько устарел и использует внешний вид, характерный для X Window, но на случай, если вам придется встретить такой программный код при сопровождении программ на языке Python, пример 8.12 может дать представление об этом интерфейсе.
Пример 8.12. PP4E\Gui\Tour\dlg-old.py
from tkinter import *
from tkinter.dialog import Dialog
class OldDialogDemo(Frame):
def __init__(self, master=None):
Frame.__init__(self, master)
Pack.config(self) # то же, что и self.pack()
Button(self, text=’Pop1’, command=self.dialog1).pack()
Button(self, text=’Pop2’, command=self.dialog2).pack()
def dialog1(self): ans = Dialog(self,
title = ‘Popup Fun!’,
text = ‘An example of a popup-dialog ‘
‘box, using older “Dialog.py”.’, bitmap = ‘questhead’,
default = 0, strings = (‘Yes’, ‘No’, ‘Cancel’)) if ans.num == 0: self.dialog2()
def dialog2(self):
Dialog(self, title = ‘HAL-9000’,
text = “I’m afraid I can’t let you do that, Dave...”,
bitmap = ‘hourglass’,
default = 0, strings = (‘spam’, ‘SPAM’))
if __name__ == ‘__main__’: OldDialogDemo().mainloop()
Если передать функции Dialog кортеж с метками для кнопок и текст сообщения, она вернет индекс нажатой кнопки (самая левая кнопка имеет индекс ноль). Окна Dialog являются модальными: доступ к остальным окнам приложения блокируется, пока Dialog ожидает ответа пользователя. При нажатии кнопки Pop2 в главном окне этого сценария выводится второй диалог, как показано на рис. 8.17.
Рис. 8.17. Диалог в старом стиле
Сценарий был запущен в Windows, и, как видите, этот диалог нисколько не похож на то, что можно было бы ожидать на этой платформе. При вызове на любой платформе этот диалог имеет внешний вид, принятый в X Window. Из-за внешнего вида диалогов, воспроизводимых модулем dialog и повышенной сложности его использования лучше использовать стандартные диалоги, продемонстрированные в предыдущем разделе.
Пользовательские диалоги
Все встреченные нами до сих пор диалоги имеют стандартный внешний вид и способы взаимодействия. Для многих задач этого достаточно, но иногда требуется нечто более специфическое. Например, формы, требующие заполнения нескольких полей ввода (например, имя, возраст и размер обуви), не поддерживаются непосредственно библиотекой стандартных диалогов. Можно было бы поочередно выводить диалоги для ввода каждого значения, но такой интерфейс нельзя назвать дружественным.
Пользовательские диалоги поддерживают произвольные интерфейсы, но работать с ними сложнее. Впрочем, многого для этого не требуется: создать окно, такое как Toplevel, с прикрепленными виджетами и добавить обработчик события, который соберет данные, введенные пользователем (если они есть), и закроет окно. Чтобы сделать такой диалог модальным, необходимо передать окну фокус ввода, сделать другие окна неактивными и ожидать события. Реализация такого диалога демонстрируется в примере 8.13.
Пример 8.13. PP4E\Gui\Tour\dlg-custom.py
import sys
from tkinter import * makemodal = (len(sys.argv) > 1)
def dialog():
win = Toplevel() # создать новое окно
Label(win, text=’Hard drive reformatted!’).pack() # добавить виджеты Button(win, text=’OK’, command=win.destroy).pack() # установить обработчик if makemodal:
win.focus_set() # принять фокус ввода,
win.grab_set() # запретить доступ к др. окнам, пока открыт диалог
win.wait_window() # ждать, пока win не будет уничтожен print(‘dialog exit’) # иначе - сразу вернуть управление
root = Tk()
Button(root, text=’popup’, command=dialog).pack() root.mainloop()
Этот сценарий создает модальное или немодальное окно, в зависимости от значения глобальной переменной makemodal. Если запустить его без аргументов командной строки, выбирается немодальный стиль, как показано на рис. 8.18.
Рис. 8.18. Немодальные пользовательские диалоги в действии
Окно справа сверху - это корневое окно. При нажатии в нем кнопки popup создается новое диалоговое окно. Поскольку в этом режиме диалоги являются немодальными, корневое окно сохраняет активность после вывода диалога. Немодальные диалоги не блокируют другие окна, поэтому кнопку в корневом окне можно нажать несколько раз и создать столько копий диалога, сколько поместится на экране. Любые из этих окон можно закрыть щелчком на их кнопках OK, при этом остальные окна останутся на экране.
Создание модальных пользовательских диалогов
Если запустить сценарий, передав ему аргумент в командной строке (например, python dlg-custom.py 1), окно диалога будет сделано модальным. Так как модальные диалоги сосредоточивают на себе все внимание интерфейса, главное окно становится недоступным, пока не будет закрыто окно диалога - пока диалог открыт, нельзя даже щелкнуть на корневом окне, чтобы активизировать его. Поэтому невозможно создать на экране больше одного всплывающего окна, как показано на рис. 8.19.
Рис. 8.19. Модальный пользовательский диалог в действии
Фактически функция dialog в этом сценарии не возвращает управление, пока диалог в левой части не будет закрыт нажатием кнопки OK. В результате модальные диалоги накладывают на модель программирования, в других случаях управляемую событиями, модель вызова функций - введенные пользователем данные можно обрабатывать сразу, а не в обработчике события, который вызывается в какой-то неопределенный момент времени в будущем.
Однако навязывание такой линейной логики управления в графическом интерфейсе требует некоторой дополнительной работы. Секрет блокирования других окон и ожидания ответа сводится к трем строкам программного кода, являющимся общим шаблоном для большинства пользовательских модальных диалогов:
win.focus_set()
Передает окну фокус ввода приложения, как если бы оно было активизировано щелчком мыши. У этого метода есть также синоним, focus, и часто фокус ввода устанавливается не на все окно, а на виджет в нем, позволяющий вводить данные (например, Entry).
win.grab_set()
Блокирует доступ ко всем другим окнам приложения, пока не будет закрыто данное окно. В это время пользователь не может взаимодействовать с другими окнами программы.
win.wait_window()
Приостанавливает вызвавшую программу, пока не будет уничтожен виджет win, но при этом главный цикл обработки событий (main-loop) остается активным. Это означает, что графический интерфейс в целом остается активным во время ожидания. Например, его окна перерисовываются при скрытии под другими окнами или открытии. Когда окно закрывается вызовом метода destroy, оно удаляется с экрана, блокировка приложения автоматически снимается и происходит возврат из данного метода.
Так как сценарий ждет события закрытия окна, он должен предоставить обработчик события, уничтожающий окно в ответ на взаимодействие с виджетами в диалоговом окне (единственном, которое активно). Диалог в этом примере является простым информационным диалогом, поэтому его кнопка OK вызывает метод destroy окна. В диалогах для ввода данных можно установить обработчик события нажатия клавиши Enter, который извлечет данные, введенные в элемент Entry, и после этого вызовет destroy (как будет показано далее в этой главе).
Другие способы реализации модальности
Модальные диалоги обычно реализуются путем создания нового всплывающего окна и ожидания в нем события destroy, как в этом примере. Но существуют и другие схемы. Например, можно создать диалоговые окна заранее, и по мере необходимости показывать или скрывать их с помощью методов deiconify и withdraw окна верхнего уровня (подробности смотрите в сценариях раздела главы 9). С учетом того, что в настоящее время скорость выполнения такова, что создание окон происходит практически мгновенно, такой способ встречается значительно реже, чем создание окон с нуля и уничтожение их при каждом взаимодействии.
Можно также реализовать состояние модальности путем ожидания изменения значения переменной tkinter, а не уничтожения окна. Подробности смотрите в последующем обсуждении переменных tkinter в данной главе (они являются объектами классов, а не обычными переменными Python) и метода wait_variable в конце главы 9. В этой схеме обработчик события долгоживущего диалогового окна может подать сигнал об изменении состояния ожидающей головной программе без необходимости уничтожения диалогового окна.
Наконец, если вызвать метод mainloop рекурсивно, возврат из вызова произойдет только после выполнения метода quit виджета. Метод quit прекращает выполнение функции mainloop и потому обычно завершает выполнение программы с графическим интерфейсом. Но если был произведен рекурсивный вызов mainloop, метод quit просто завершит его. Благодаря этому модальные диалоги можно реализовать без обраще-
ния к методу ожидания. Так, сценарий в примере 8.14 работает аналогично dlg-custom в модальном режиме.
Пример 8.14. PP4E\Gui\Tour\dlg-recursive.py
from tkinter import *
def dialog():
win = Toplevel() # создать новое окно
Label(win, text=’Hard drive reformatted!').pack() # добавить виджеты Button(win, text='OK', command=win.quit).pack() # установить обр-к quit win.protocol('WM_DELETE_WINDOW', win.quit) # завершить и при
# закрытии окна!
win.focus_set() # принять фокус ввода,
win.grab_set() # запретить доступ к др. окнам, пока открыт диалог win.mainloop() # и запустить вложенный цикл обр. событий для ожидания win.destroy()
print(‘dialog exit’)
root = Tk()
Button(root, text=’popup’, command=dialog).pack() root.mainloop()
Выбирая этот путь, нужно вместо метода destroy вызывать в обработчиках событий метод quit (destroy не завершает функцию mainloop) и обеспечить вызов quit кнопкой закрытия окна с помощью метода protocol (иначе не будет завершаться рекурсивный вызов mainloop, что приведет к генерации странных сообщений об ошибках при окончательном выходе из программы). Из-за этой дополнительной сложности более удобным может оказаться использование wait_window или wait_variable, а не рекурсивных вызовов mainloop.
Как строить диалоги в виде форм с метками и полями ввода, мы увидим далее в этой главе, познакомившись с элементом Entry, и еще раз - при изучении менеджера grid в главе 9. Другие примеры пользовательских диалогов можно найти в демонстрационных приложениях ShellGui (глава 10), PyMailGui (глава 14), PyCalc (глава 19) и немодальном form. py (глава 12). А сейчас мы перейдем к более глубокому изучению событий, что несомненно пригодится на следующих этапах нашего турне.
Привязка событий
В предыдущей главе мы познакомились с методом bind виджетов, который использовался для перехвата нажатий кнопок. Так как метод bind часто используется вместе с другими виджетами (например, для перехвата нажатия клавиши Enter в полях ввода), остановимся на нем здесь в начале нашего обзора. Пример 8.15 иллюстрирует другие протоколы событий для метода bind.
Пример 8.15. PP4E\Gui\Tour\bind.py
from tkinter import *
def showPosEvent(event):
print(‘Widget=%s X=%s Y=%s’ % (event.widget, event.x, event.y))
def showAllEvent(event): print(event) for attr in dir(event):
if not attr.startswith(‘__’):
print(attr, ‘=>’, getattr(event, attr))
def onKeyPress(event):
print(‘Got key press:’, event.char)
def onArrowKey(event):
print(‘Got up arrow key press’)
def onReturnKey(event):
print(‘Got return key press’)
def onLeftClick(event):
print(‘Got left mouse button click:’, end=’ ‘) showPosEvent(event)
def onRightClick(event):
print(‘Got right mouse button click:’, end=’ ‘) showPosEvent(event)
def onMiddleClick(event):
print(‘Got middle mouse button click:’, end=’ ‘)
showPosEvent(event)
showAllEvent(event)
def onLeftDrag(event):
print(‘Got left mouse button drag:’, end=’ ‘) showPosEvent(event)
def onDoubleLeftClick(event):
print(‘Got double left mouse click’, end=’ ‘)
showPosEvent(event)
tkroot.quit()
tkroot = Tk()
labelfont = (‘courier’, 20, ‘bold’) # семейство, размер, стиль
widget = Label(tkroot, text=’Hello bind world’)
widget.config(bg=’red’, font=labelfont) # красный фон, большой шрифт
widget.config(height=5, width=20) # начальн. размер: строк,символов
widget.pack(expand=YES, fill=BOTH)
widget.bind(‘’, onLeftClick) # щелчок мышью
widget.bind(‘’, onRightClick)
widget.bind(‘’, onMiddleClick) # средняя = обе на некот. мышах widget.bind(‘’, onDoubleLeftClick)# двойной щелчок левой кнопкой widget.bind(‘’, onLeftDrag) # щелчок левой кнопкой и перемещ.
widget.bind(‘’, onKeyPress) # нажатие любой клавиши на клав.
widget.bind(‘’, onArrowKey) # нажатие клавиши со стрелкой
widget.bind(‘’, onReturnKey) # return/enter key pressed
widget.focus() # или привязать нажатие клавиши
# к tkroot
tkroot.title(‘Click Me’) tkroot.mainloop()
Этот файл состоит в основном из функций обработчиков событий, вызываемых при возникновении связанных событий. Как было показано в главе 7, обработчики данного типа получают в качестве аргумента объект события, содержащий сведения о сгенерированном событии. Технически этот аргумент является экземпляром класса Event из библиотеки tkinter, и содержащиеся в нем подробности представлены атрибутами. Большинство обработчиков просто выводят информацию о событиях, извлекая значения из их атрибутов.
Если запустить этот сценарий, он создаст окно, изображенное на рис. 8.20. Главное его назначение - служить областью для запуска событий щелчков мышью и нажатия клавиш.
Рис. 8.20. Окно сценария bind для щелчков мышью
Черно-белое издание, которое вы держите в руках, не позволяет оценить этот сценарий. При запуске вживую он использует приведенные выше настройки и выводит текст черным по красному большим шрифтом Courier. Вам придется поверить мне на слово (или запустить его самим).
Но главная задача этого примера - продемонстрировать действие других протоколов связывания событий. Мы уже встречали в главе 7 сценарий, который с помощью метода bind виджета и имен событий и перехватывал одиночные и двойные щелчки левой кнопкой мыши. Данный сценарий демонстрирует другие виды событий, часто перехватываемые с помощью метода bind:
Чтобы перехватывать нажатия одиночных клавиш на клавиатуре, можно зарегистрировать обработчик для события с идентификатором - это более низкоуровневый способ ввода данных в программах с графическим интерфейсом, чем использование виджета Entry, о котором рассказывается в следующем разделе. Нажатая клавиша возвращается в виде кода ASCII в объекте события, передаваемом обработчику события (event.char). Другие атрибуты в структуре события позволяют идентифицировать нажатую клавишу на еще более низком уровне. Нажатия клавиш можно перехватывать виджетом корневого окна верхнего уровня или виджетом, которому передан фокус ввода с помощью метода focus, используемого в данном сценарии.
Этот сценарий перехватывает также перемещение мыши при нажатой кнопке: зарегистрированный обработчик события вызывается всякий раз когда мышь передвигается при нажатой левой кнопке и получает в аргументе события текущие координаты X/Y указателя мыши (event.x, event.y). Эту информацию можно использовать для организации перемещения объектов, перетаскивания, рисования на уровне пикселей и так далее (смотрите демонстрационный пример программы PyDraw в главе 11).
,
Этот сценарий перехватывает также щелчки правой и средней кнопками мыши (называемыми также кнопками 3 и 2). Воспроизвести щелчок средней кнопкой 2 с помощью двухкнопочной мыши можно, щелкнув одновременно обеими кнопками, - если этот прием не действует, проверьте настройки мыши в интерфейсе свойств (Панель управления (Control PaneL) в Windows)40.
,
Чтобы перехватывать нажатия более специфических клавиш, в данном сценарии зарегистрированы обработчики событий нажатия клавиш Return/Enter и «стрелки вверх». В противном случае эти события были бы отправлены универсальному обработчику события и потребовали бы дополнительного анализа события.
Ниже показано, что попадает в поток вывода stdout после щелчка левой кнопкой, правой кнопкой, левой кнопкой и перетаскивания, нескольких нажатий клавиш, нажатия клавиш Enter и «стрелки вверх» и наконец, двойного щелчка левой кнопкой для завершения. При нажатии левой кнопки мыши и перемещении курсора по экрану возникает множество сообщений с информацией о событии перетаскивания - одно сообщение выводится для каждого движения при перетаскивании (и для каждого производится вызов обработчика на языке Python):
C:\...\PP4E\Gui\Tour> python bind.py
Got left mouse button click: Widget=.25763696 X=376 Y=53
Got right mouse button click: Widget=.25763696 X=36 Y=60
Got left mouse button click: Widget=.25763696 X=144 Y=43
Got left mouse button drag: Widget=.25763696 X=144 Y=45
Got left mouse button drag: Widget=.25763696 X=144 Y=47
Got left mouse button drag: Widget=.25763696 X=145 Y=50
Got left mouse button drag: Widget=.25763696 X=146 Y=51
Got left mouse button drag: Widget=.25763696 X=149 Y=53
Got key press: s
Got key press: p
Got key press: a
Got key press: m
Got key press: 1
Got key press: -
Got key press: 2
Got key press: .
Got return key press Got up arrow key press
Got left mouse button click: Widget=.25763696 X=300 Y=68 Got double left mouse click Widget=.25763696 X=300 Y=68
Для событий, связанных с мышью, обработчики выводят координаты X и Y указателя мыши, которые передаются в объекте события. Обычно координаты измеряются в пикселях от верхнего левого угла (0, 0), относительно того виджета, на котором произведен щелчок. Ниже показано, что выводится для щелчка левой кнопкой, средней кнопкой и двойного щелчка левой. Обратите внимание, что обработчик щелчка средней кнопкой выводит свой аргумент целиком - все атрибуты объекта Event (исключая внутренние атрибуты с именами, начинающимися
с двух символов подчеркивания «__», в число которых входит атрибут
__doc__и методы перегрузки операторов, унаследованные от суперкласса object, подразумеваемого в Python 3.X по умолчанию). Различные типы событий устанавливают различные атрибуты. Например, нажатие большинства клавиш записывает некоторое значение в атрибут char:
C:\...\PP4E\Gui\Tour> python bind.py
Got left mouse button click: Widget=.25632624 X=6 Y=6
Got middle mouse button click: Widget=.25632624 X=212 Y=95
char => ??
delta => 0
height => ??
keycode => ??
keysym => ?? keysym_num => ?? num => 2
send_event => False serial => 17 state => 0 time => 549707945 type => 4
widget => .25632624 width => ?? x => 212 x_root => 311 y => 95 y_root => 221
Got left mouse button click: Widget=.25632624 X=400 Y=183 Got double left mouse click Widget=.25632624 X=400 Y=183
Другие события, доступные с помощью метода bind
Помимо событий, которые были проиллюстрированы в данном примере, сценарий, использующий библиотеку tkinter, может зарегистрировать обработчики других видов связываемых событий. Например:
• генерируется при отпускании кнопки мыши (событие генерируется, когда кнопка нажимается).
• генерируется при перемещении указателя мыши.
• Обработчики и генерируются в момент входа и выхода указателя мыши из области окна (полезно для автоматического выделения виджета).
• генерируется при изменении размеров окна, его положения и так далее (например, новые размеры окна содержатся в атрибутах width и height объекта события). Мы будем использовать это событие для масштабирования содержимого окна при изменении его размеров в примере PyClock, в главе 11.
• генерируется при уничтожении виджета окна (и отличается от механизма protocol менеджера окон, реализованного для кнопки закрытия). Поскольку это событие имеет непосредственное отношение к методам quit и destroy виджетов, я расскажу о нем более подробно далее в этом разделе.
• и генерируются, когда виджет получает или теряет фокус ввода.
• и генерируются, когда окно сворачивается в значок и восстанавливается.
• , и генерируются при нажатии других специальных клавиш.
• , и генерируются при нажатии других клавиш со стрелками.
Этот список не полон, а для записи названий событий есть свой довольно сложный синтаксис, например:
• Модификаторы - могут добавляться к идентификаторам событий, чтобы сделать их еще более специфическими. Например, означает перемещение указателя мыши при нажатой левой кнопке, а генерируется только при нажатии клавиши «а».
• Синонимы. - могут использоваться для имен некоторых частых событий. Например, , и <1> означают нажатие левой кнопки мыши, а и означают клавишу «а». Все формы имен чувствительны к регистру символов: пишите , а не .
• Имеется возможность определять идентификаторы виртуальных событий, обозначающие последовательности из одного или нескольких событий, с помощью пары угловых скобок (например, <>).
С целью экономии места за исчерпывающими сведениями по этой теме мы отсылаем вас к другим источникам информации по Tk и tkinter. Кроме того, изменяя настройки в сценарии и запуская его заново, также можно выяснить некоторые особенности поведения событий - в конце концов, это Python.
Подробнее о событии и методах quit и destroy
Прежде чем двинуться дальше, необходимо сказать несколько слов о событии (регистр символов в имени которого имеет значение): это событие генерируется, когда выполняется операция уничтожения виджета, будь то вызов метода из сценария или операция закрытия окна пользователем, включая завершение программы. Если привязать обработчик этого события к окну, он будет вызываться по одному разу для каждого виджета в окне - атрибут widget объекта события, передаваемого обработчику в виде аргумента, будет ссылаться на уничтожаемый виджет, и вы можете использовать эту особенность, чтобы определить момент уничтожения какого-то определенного виджета. Если же привязать этот обработчик к какому-то определенному виджету, он будет вызываться только при уничтожении этого виджета.
Важно знать, что в момент возбуждения события виджет находится в «полумертвом» состоянии (в терминологии библиотеки Tk) - он по-прежнему существует, но большинство операций над ним будут терпеть неудачу. По этой причине событие вообще не может использоваться для выполнения операций с графическим интерфейсом -например, попытки проверки признака изменения состояния виджета или извлечения его содержимого в обработчике события будут возбуждать исключения. Кроме того, в этом обработчике нельзя отменить уничтожение виджетов и обеспечить продолжение работы графического интерфейса. Если вам потребуется перехватывать и проверять или подавлять операцию закрытия окна после щелчка пользователем на кнопке X окна, используйте событие WM_DELETE_WINDOW в методе protocol высокого уровня, как было описано выше в этой главе.
Кроме того, вы должны знать, что вызов метода quit виджетов не возбуждает никаких событий , а наличие любых зарегистрированных обработчиков события в программах, выполняемых под управлением Python 3.X, вообще приводит к фатальной ошибке при завершении программы. Вследствие этого программы, привязывающие обработчики этого события для выполнения заключительных действий, не связанных с графическим интерфейсом, должны обычно вызывать метод destroy вместо quit и надеяться, что программа завершится вместе с уничтожением последнего или единственного корневого окна Tk (созданного явно или по умолчанию), как описывалось выше. Это обстоятельство препятствует использованию метода quit для немедленного завершения программы, хотя у вас всегда остается последнее средство - функция sys.exit.
Сценарий может также выполнять заключительные операции в программном коде, следующем за вызовом функции mainloop, но к этому моменту графический интерфейс уже будет полностью уничтожен, и данный программный код не может быть привязан к какому-то конкретному виджету. Мы еще будем говорить об этом событии, когда будем изучать программу PyEdit в главе 11 - мы найдем это событие непригодным для проверки наличия изменений в тексте, определяющих необходимость его сохранения.
Виджеты Message и Entry
Виджеты Message и Entry позволяют отображать и вводить простой текст. Оба они, в сущности, являются функциональными подмножествами виджета Text, с которым мы познакомимся позднее, - Text может делать все то, что могут Message и Entry, при этом обратное утверждение неверно.
Message
Виджет Message служит всего лишь местом для отображения текста. Хотя с помощью стандартного диалога showinfo, с которым мы встречались ранее, выводить всплывающие сообщения, вероятно, удобнее, тем не менее виджет Message автоматически и гибко разбивает длинные строки и может встраиваться внутрь элементов-контейнеров, когда нужно вывести на экране какой-либо текст, доступный только для чтения. Кроме того, этот виджет обладает более чем десятком параметров настройки, позволяющих изменять его внешний вид. Пример 8.16 и рис. 8.21 иллюстрируют основы применения Message и демонстрируют, как этот виджет реагирует на растягивание по горизонтали с применением параметров fill и expand. Дополнительные сведения об изменении размеров виджетов вы найдете в главе 7, а сведения о других поддерживаемых параметрах ищите в справочниках по Tk или tkinter.
Пример 8.16. PP4E\Gui\tour\message.py
from tkinter import *
msg = Message(text=”Oh by the way, which one’s Pink?”) msg.config(bg=’pink’, font=(‘times’, 16, ‘italic’)) msg.pack(fill=X, expand=YES) mainloop()
Рис. 8.21. Виджет Message в действии
Entry
Виджет Entry служит простым полем ввода одной строки текста. Обычно он используется для реализации полей ввода в диалогах, имеющих вид форм, и всюду, где пользователь должен ввести значение в поле. Виджет Entry также поддерживает более сложные понятия, такие как прокрутка, привязка клавиш для редактирования и выделение текста, при этом он очень прост в использовании. Сценарий в примере 8.17 создает окно для ввода, изображенное на рис. 8.22.
Пример 8.17. PP4E\Gui\tour\entry1.py
from tkinter import * from quitter import Quitter
def fetch():
print(‘Input => “%s”’ % ent.get()) # извлечь текст
root = Tk() ent = Entry(root)
ent.insert(0, ‘Type words here’) # записать текст
ent.pack(side=TOP, fill=X) # растянуть по горизонтали
ent.focus() # избавить от необходимости
# выполнять щелчок мышью
ent.bind(‘’, (lambda event: fetch())) # по нажатию клавиши Enter btn = Button(root, text=’Fetch’, command=fetch) # и по щелчку на кнопке btn.pack(side=LEFT)
Quitter(root).pack(side=RIGHT)
root.mainloop()
Рис. 8.22. Сценарий entry1 в действии
Если запустить сценарий entry1, он заполнит поле ввода в этом интерфейсе текстом «Type words here» вызовом метода insert виджета. Поскольку щелчок на кнопке Fetch и нажатие клавиши Enter запускают в сценарии функцию обратного вызова fetch, оба эти события извлекут из поля ввода текущий текст с помощью метода get виджета и выведут его:
C:\...\PP4E\Gui\Tour> python entry1.py
Input => “Type words here”
Input => “Have a cigar”
Мы уже встречались выше с событием , когда знакомились с методом bind - в отличие от событий нажатий на кнопки, эти низкоуровневые обработчики получают в качестве аргумента объект события, поэтому, чтобы игнорировать его, в сценарии использовано обертывающее lambda-выражение. Кроме того, поле ввода в этом сценарии компонуется с параметром fill=X, чтобы оно растягивалось по горизонтали вместе с окном (попробуйте сами), и вызывается метод focus виджета, чтобы автоматически передать фокус в поле ввода при появлении окна. Благодаря передаче фокуса вручную пользователю не нужно щелкать на поле, чтобы начать ввод данных. Наша умная кнопка Quit, которую мы реализовали ранее, также прикрепляется к интерфейсу (она выводит диалог с просьбой подтвердить завершение приложения).
Программирование виджетов Entry
Вообще говоря, значения, вводимые в виджеты Entry и отображаемые ими, могут быть записаны или получены с помощью связанных объектов «переменных» (описываемых далее в этой главе) или с помощью следующих методов виджета Entry:
ent.insert(0, ‘some text’) # запись значения
value = ent.get() # извлечение значения (строки)
Первый параметр метода insert определяет позицию в строке, начиная с которой должен быть введен текст. Здесь «0» означает ввод в начало строки, поскольку смещения начинают отсчитываться с нуля, а целое число 0 и строка ‘0’ означают одно и то же (аргументы методов в библиотеке tkinter всегда при необходимости преобразуются в строки). Если виджет Entry уже содержит текст, то обычно требуется удалить его содержимое перед записью нового значения, иначе новый текст будет просто добавлен к уже существующему:
ent.delete(0, END) # сперва удалить текст с начала до конца
ent.insert(0, ‘some text’) # затем записать значение
Имя END здесь является предопределенной константой tkinter, обозначающей конец содержимого виджета - она снова встретится нам в главе 9 при изучении полномасштабного и многострочного виджета Text (более мощного собрата Entry). Поскольку после удаления виджет не будет ничего содержать, предыдущая последовательность инструкций эквивалентна следующей:
ent.delete(‘0’, END) # удалить текст с начала до конца
ent.insert(END, ‘some text’) # добавить в конец пустой строки текста
В любом случае, если сначала не удалить текст, новый текст просто будет добавлен к нему. Если вам интересно увидеть, как это происходит, измените функцию fetch, как показано ниже, и при каждом щелчке кнопкой или нажатии клавиши в начало и в конец поля ввода будет добавляться «х»:
def fetch():
print(‘Input => “%s”’ % ent.get()) # получить текст
ent.insert(END, ‘x’) # для очистки: ent.delete(‘0’, END)
ent.insert(0, ‘x’) # новый текст просто добавляется
В последующих примерах мы встретимся также с параметром state= ’disabled’ виджета Entry, делающим его доступным только для чтения, а также параметром show=’*’, заставляющим его выводить каждый символ как * (полезно для организации ввода паролей). Поэкспериментируйте с этим сценарием, изменяя и запуская его. Виджет Entry поддерживает и другие параметры, которые мы здесь также пропустим; дополнительные сведения ищите в последующих примерах и других источниках.
Компоновка элементов ввода в формах
Как уже отмечалось, виджеты Entry часто применяются в качестве полей ввода при реализации форм. Мы часто будем создавать такие формы в этой книге. Простую иллюстрацию такого применения дает пример 8.18, в котором несколько меток, полей ввода и фреймов объединены в форму для ввода нескольких значений, изображенную на рис. 8.23.
Пример 8.18. PP4E\Gui\Tour\entry2.py
непосредственное использование виджетов Entry и размещение их по рядам с метками фиксированной ширины: такой способ компоновки, а также использование менеджера grid обеспечивают наилучшее представление для форм
from tkinter import * from quitter import Quitter fields = ‘Name’, ‘Job’, ‘Pay’
def fetch(entries):
for entry in entries:
print(‘Input => “%s”’ % entry.get()) # извлечь текст
def makeform(root, fields): entries = [] for field in fields:
row = Frame(root) # создать новый ряд
lab = Label(row, width=5, text=field) # добавить метку, поле ввода
ent = Entry(row)
row.pack(side=TOP, fill=X) # прикрепить к верхнему краю
lab.pack(side=LEFT)
ent.pack(side=RIGHT, expand=YES, fill=X) # растянуть по горизонтали entries.append(ent) return entries
if__name__== ‘__main__’:
root = Tk()
ents = makeform(root, fields) root.bind(‘’, (lambda event: fetch(ents)))
Button(root, text=’Fetch’,
command = (lambda: fetch(ents))).pack(side=LEFT) Quitter(root).pack(side=RIGHT) root.mainloop()
Рис. 8.23. Внешний вид форм entry2 (и entry3)
Полями ввода здесь служат простые виджеты Entry. Сценарий создает список виджетов, с помощью которого потом будут извлекаться их значения. При каждом нажатии кнопки Fetch текущие значения извлекаются из всех полей ввода и выводятся в стандартный поток вывода:
C:\...\PP4E\Gui\Tour> python entry2.py
Input => “Bob”
Input => “Technical Writer”
Input => “Jack”
Тот же результат дает нажатие клавиши Enter, когда окно обладает фокусом ввода, - на этот раз событие привязано к корневому окну в целом, а не к отдельному полю ввода.
Искусство создания структуры формы состоит в основном в организации иерархии виджетов. В данном сценарии каждый ряд метка/поле ввода конструируется как новый фрейм Frame, прикрепляемый к текущему краю TOP окна. Метки прикрепляются к левому краю ряда (LEFT), а поля - к правому (RIGHT). Поскольку каждый ряд представляет собой отдельный фрейм, его содержимое изолируется от других операций компоновки, производимых в этом окне. Кроме того, этот сценарий разрешает увеличение горизонтального размера при изменении размеров окна только для полей ввода, как показано на рис. 8.24.
Рис. 8.24. Возможность растягивания полей ввода в сценариях entry2 (и entry3) в действии
Снова о создании модальных окон
Далее мы увидим, как создавать аналогичные структуры форм с помощью менеджера компоновки grid, где вместо фреймов размещение виджетов выполняется по номерам рядов и столбцов. Но сейчас, реализовав структуру формы, посмотрим, как применять технологию создания модальных диалогов к более сложным формам.
Сценарий в примере 8.19, используя функции makeform и fetch из предыдущего примера, создает форму и выводит ее содержимое подобно тому, как это делалось раньше. Но теперь поля ввода прикрепляются к новому всплывающему окну Toplevel, создаваемому по требованию и содержащему кнопку OK, генерирующую событие уничтожения окна. Как мы уже знаем, метод wait_window влечет приостановку программы, пока окно не будет закрыто.
Пример 8.19. PP4E\Gui\Tour\entry2-modal.py
# создает модальный диалог с формой;
# данные должны извлекаться до уничтожения окна с полями ввода from tkinter import *
from entry2 import makeform, fetch, fields
def show(entries, popup):
fetch(entries) # извлечь данные перед уничтожением окна!
popup.destroy() # если инструкции поменять местами, сценарий
# будет возбуждать исключение
def ask():
popup = Toplevel() # отобразить форму в виде модального диалога
ents = makeform(popup, fields)
Button(popup, text=’OK’, command=(lambda: show(ents, popup))).pack()
popup.grab_set()
popup.focus_set()
popup.wait_window() # ждать закрытия окна
root = Tk()
Button(root, text=’Dialog’, command=ask).pack() root.mainloop()
Если нажать кнопку в главном окне, сценарий создаст окно диалога с формой, блокирующее остальное приложение, изображенное на рис. 8.25.
В реализации этого модального диалога таится малозаметная опасность: поскольку он извлекает данные, вводимые пользователем, из виджетов Entry, встроенных во всплывающее окно, эти данные необходимо получить прежде чем окно будет уничтожено в обработчике события нажатия кнопки OK. Оказывается, что вызов destroy действительно уничтожает все виджеты окна - попытка получить значение из уничтоженного виджета Entry не только не действует, но и порождает исключение с выводом трассировочной информации и сообщения об ошибке в окне консоли - попробуйте изменить порядок команд в функции show, и вы убедитесь в этом сами.
Рис. 8.25. Окна, создаваемые сценарием entry2-modal (и entry3-modal)
Чтобы избежать этой проблемы, нужно следить за тем, чтобы выборка значений осуществлялась перед уничтожением, или использовать переменные tkinter, являющиеся предметом обсуждения следующего раздела.
«Переменные» tkinter и альтернативные способы компоновки форм
Виджеты Entry (наряду с другими) поддерживают понятие ассоциированной переменной - изменение значения ассоциированной переменной изменяет текст, отображаемый виджетом Entry, а изменение текста в Entry изменяет значение переменной. Однако это не обычные переменные Python. Переменные, связанные с виджетами, являются экземплярами классов переменных в библиотеке tkinter. Эти классы носят названия StringVar, IntVar, DoubleVar и BooleanVar. Выбор того или иного класса зависит от контекста, в котором он должен использоваться. Например, можно связать с полем Entry экземпляр класса StringVar, как показано в примере 8.20.
Пример 8.20. PP4E\Gui\Tour\entry3.py
использует переменные StringVar
компоновка по колонкам: вертикальные координаты виджетов могут не совпадать (смотрите entry2)
from tkinter import * from quitter import Quitter fields = ‘Name’, ‘Job’, ‘Pay’
def fetch(variables):
for variable in variables:
print(‘Input => “%s”’ % variable.get()) # извлечь из переменных def makeform(root, fields):
form = Frame(root) # создать внешний фрейм
left = Frame(form) # создать две колонки
rite = Frame(form)
form.pack(fill=X)
left.pack(side=LEFT)
rite.pack(side=RIGHT, expand=YES, fill=X) # растягивать по горизонтали
variables = [] for field in fields:
lab = Label(left, width=5, text=field) # добавить в колонки
ent = Entry(rite)
lab.pack(side=TOP)
ent.pack(side=TOP, fill=X) # растягивать по горизонтали
var = StringVar()
ent.config(textvariable=var) # связать поле с переменной
var.set(‘enter here’) variables.append(var) return variables
if__name__== ‘__main__’:
root = Tk()
vars = makeform(root, fields)
Button(root, text=’Fetch’, command=(lambda: fetch(vars))).pack(side=LEFT)
Quitter(root).pack(side=RIGHT)
root.bind(‘’, (lambda event: fetch(vars)))
root.mainloop()
За исключением того обстоятельства, что поля ввода инициализируются строкой enter here’, этот сценарий создает окно, практически идентичное по внешнему виду и функциям тому, которое создает сценарий entry2 (рис. 8.23 и 8.24). Для наглядности виджеты в окне компонуются другим способом - как фрейм с двумя вложенными фреймами, образующими левую и правую колонки в области формы, - но конечный результат при отображении на экран оказывается тем же самым (на некоторых платформах, по крайней мере: смотрите примечание в конце этого раздела, где описывается, почему компоновка на основе рядов обычно бывает предпочтительнее).
Главное, на что здесь нужно обратить внимание, это использование переменных StringVar. Вместо списка виджетов Entry, из которого извлекаются введенные значения, эта версия хранит список объектов StringVar, которые ассоциируются с виджетами Entry следующим способом:
ent = Entry(rite) var = StringVar()
ent.config(textvariable=var) # связать поле с переменной
После того как переменные будут связаны, операции изменения и получения значения переменной
var.set(‘text here’) value = var.get()
действительно будут изменять и получать значение соответствующего поля ввода на экране.41 Метод get объекта переменной возвращает строку для StringVar, целое число для IntVar и число с плавающей точкой для
DoubleVar.
Конечно, как мы уже видели, можно легко изменять и извлекать текст непосредственно из полей Entry, без всяких дополнительных переменных. Зачем же утруждать себя обработкой объектов переменных? Во-первых, исчезает опасность попыток извлечения значений после уничтожения, о чем говорилось в предыдущем разделе. Поскольку объекты StringVar продолжают существовать после уничтожения виджетов Entry, к которым они привязаны, сохраняется возможность извлекать из них значения, когда модального диалога уже давно нет, как показано в примере 8.21.
Пример 8.21. PP4E\Gui\Tour\entry3-modal.py
# значения могут извлекаться из StringVar и после уничтожения виджета
from tkinter import *
from entry3 import makeform, fetch, fields def show(variables, popup):
popup.destroy() # здесь порядок не имеет значения
fetch(variables) # переменные сохраняются после уничтожения окна
def ask():
popup = Toplevel() # отображение формы в модальном диалоге
vars = makeform(popup, fields)
Button(popup, text=’OK’, command=(lambda: show(vars, popup))).pack()
popup.grab_set()
popup.focus_set()
popup.wait_window() # ждать уничтожения окна
root = Tk()
Button(root, text=’Dialog’, command=ask).pack() root.mainloop()
Эта версия такая же, как исходная (представленная в примере 8.19 и на рис. 8.25), но теперь функция show уничтожает всплывающее окно до извлечения введенных данных из переменных StringVar в списке, созданном функцией makeform. Иными словами, переменные оказываются более надежными в некоторых контекстах, потому что они не являются частью действительного дерева виджетов. Например, они также часто используются с флажками, группами переключателей и ползунками, обеспечивая доступ к текущим значениям и связывая вместе несколько виджетов. Так уж совпало, что им посвящен следующий раздел.
В этом разделе мы использовали два способа компоновки форм: во фреймах по рядам, с метками фиксированной ширины (entry2), и во фреймах по колонкам (entry3). В главе 9 мы познакомимся с третьим способом: компоновкой с помощью менеджера grid. Из них наилучший результат на всех платформах обеспечивают компоновка по сетке и по рядам с метками фиксированной ширины, как в сценарии entry2.
Компоновка по колонкам, использованная в сценарии ent ry3, может использоваться только на платформах, где высота каждой метки в точности соответствует высоте каждого поля ввода. Поскольку эти виджеты напрямую никак не связаны, их вертикальные координаты могут не совпадать на некоторых платформах. Когда я попытался протестировать в системе Linux некоторые формы, замечательно выглядевшие в Windows XP, метки и соответствующие им поля ввода оказались на разной высоте.
Даже такое простое окно, которое воспроизводит сценарий entry3, при ближайшем рассмотрении выглядит несколько кривовато. На некоторых платформах оно только кажется похожим на окно, воспроизводимое сценарием entry2, из-за небольшого количества полей ввода и небольших размеров по умолчанию. В Windows 7 на моем нетбуке несовпадение меток и полей ввода по вертикали становится заметным после добавления 3-4 дополнительных полей ввода в кортеж полей в сценарии ent ry3.
Если переносимость имеет для вас важное значение, компонуйте свои формы либо с помощью фреймов по рядам и с метками фиксированной/максимальной ширины, как в сценарии entry2, либо с выравниванием виджетов по сетке. Дополнительные примеры таких форм мы увидим в следующей главе. А в главе 12 мы напишем свой инструмент конструирования форм, скрывающий тонкости их компоновки от клиента (включая пример клиента в главе 13).
Флажки, переключатели и ползунки
Этот раздел знакомит с тремя типами виджетов - Checkbutton («флажок», виджет для выбора нескольких вариантов одновременно), Radiobutton («переключатель», виджет для выбора единственного варианта из нескольких) и Scale («шкала», иногда называемый «slider» - «ползунок»). Все они являются вариациями на одну тему и в какой-то мере связаны с простыми кнопками, поэтому мы будем изучать их здесь вместе. Чтобы тренироваться с этими элементами было интереснее, мы повторно используем модуль dialogTable, представленный в примере 8.8, где определяются обработчики событий выбора виджетов (обработчики, вызывающие диалоги). Попутно мы воспользуемся только что рассмотренными переменными tkinter для получения значений состояния этих виджетов.
Флажки
Виджеты Checkbutton и Radiobutton предусматривают возможность ассоциирования с переменными tkinter: щелчок на виджете изменяет значение переменной, а изменение значения переменной изменяет состояние виджета, к которому она привязана. В действительности переменные tkinter составляют функциональную основу этих графических элементов:
• Группа флажков Checkbutton реализует интерфейс с выбором нескольких вариантов путем присвоения каждому виджету (флажку) собственной переменной.
• Группа переключателей Radiobutton реализует модель выбора единственного из нескольких взаимоисключающих вариантов путем придания каждому виджету уникального значения и назначения одной и той же переменной tkinter.
У обоих типов виджетов есть параметры command и variable. Параметр command позволяет зарегистрировать обработчик, который вызывается, как только возникает событие щелчка на виджете, подобно обычным виджетам Button. Но передавая переменную tkinter в параметре variable, можно также в любой момент получать или изменять состояние виджета путем получения или изменения значения связанной с ним переменной.
Флажки tkinter несколько проще в обращении, поэтому с них и начнем. Пример 8.22 создает группу из пяти флажков, изображенную на рис. 8.26. Для большей пользы он также добавляет кнопку, с помощью которой выводится текущее состояние всех флажков, и прикрепляет экземпляр кнопки Quitter, которую мы создали в начале главы.
Рис. 8.26. Сценарий demoCheck в действии
Пример 8.22. PP4E\Gui\Tour\demoCheck.py
“создает группу флажков, которые вызывают демонстрационные диалоги”
from tkinter import * # импортировать базовый набор виджетов
from dialogTable import demos # импортировать готовые диалоги
from quitter import Quitter # прикрепить к “себе” объект Quitter
class Demo(Frame):
def __init__(self, parent=None, **options):
Frame.__init__(self, parent, **options)
self.pack()
self.tools()
Label(self, text=”Check demos”).pack()
self.vars = [] for key in demos: var = IntVar()
Checkbutton(self,
text=key,
variable=var,
command=demos[key]).pack(side=LEFT)
self.vars.append(var)
def report(self):
for var in self.vars:
print(var.get(), end=’ ‘) # текущие значения флажков: 1 или 0
print()
def tools(self):
frm = Frame(self) frm.pack(side=RIGHT)
Button(frm, text=’State’, command=self.report).pack(fill=X) Quitter(frm).pack(fill=X)
if __name__ == ‘__main__’: Demo().mainloop()
С точки зрения программного кода, флажки похожи на обычные кнопки, они даже добавляются в контейнерный виджет. Однако функционально они несколько отличаются. Как можно видеть по рисунку (а лучше - запустив пример), флажок работает как переключатель: щелчок на нем изменяет его состояние из выключенного во включенное (из невыбранного в выбранное) или обратно - из включенного в выключенное. Когда флажок выбран, на нем выводится галочка, а связанная с ним переменная IntVar получает значение 1; когда он не выбран, галочка исчезает, а его переменная IntVar получает значение 0.
Чтобы смоделировать приложение, содержащее флажки, кнопка State в этом графическом интерфейсе запускает метод report в сценарии, который выводит текущие состояния всех пяти флажков в поток stdout. Ниже приводится вывод, полученный после нескольких щелчков:
C:\...\PP4E\Gui\Tour> python demoCheck.py
0 0 0 0 0
1 0 0 0 0
1 0 1 0 0
1 0 1 1 0
1 0 0 1 0
1 0 0 1 1
В действительности это значения пяти переменных tkinter, ассоциированных с флажками Checkbutton посредством параметров variable, и при опросе они совпадают со значениями виджетов. В этом сценарии с каждым из флажков Checkbutton на экране ассоциирована переменная IntVar, поскольку это двоичные индикаторы, способные принимать значение 0 или 1. Переменные StringVar тоже можно использовать, но при этом их методы будут возвращать строки 0’ или ‘1’, а не целые числа, а их начальным состоянием будет пустая строка (а не целое число 0).
Параметр command этого виджета позволяет зарегистрировать обработчик, который будет вызываться при каждом щелчке на виджете. Для иллюстрации в качестве обработчика для каждого из флажков в этом сценарии зарегистрирован вызов демонстрации стандартного диалога: щелчок изменяет состояние переключателя, а кроме того, выводит один из знакомых диалогов.
Интересно, что вызвать метод report можно также в интерактивном сеансе. При работе в таком режиме виджеты отображаются во всплывающем окне при вводе строк и полностью действуют даже без вызова функции mainloop:
C:\...\PP4E\Gui\Tour> python >>> from demoCheck import Demo >>> d = Demo()
>>> d.report()
0 0 0 0 0 >>> d.report()
1 0 0 0 0 >>> d.report()
1 0 0 1 1
Флажки и переменные
Когда я впервые изучал этот виджет, моей первой реакцией было: «Зачем вообще здесь нужны переменные tkinter, если можно зарегистрировать обработчики щелчков на виджетах?» На первый взгляд связанные переменные могут показаться излишними, но они упрощают некоторые действия с графическим интерфейсом. Не буду просить принять это на веру, а постараюсь объяснить, почему.
Имейте в виду, что обработчик для флажка, указанный в параметре command, будет выполняться при каждом щелчке - при переключении и в выбранное, и в невыбранное состояние. Поэтому если нужно совершить действие немедленно после щелчка на флажке, как правило, в обработчике события требуется узнать текущее значение флажка. Поскольку у флажка нет метода «get», с помощью которого можно было бы получить текущее его значение, обычно требуется запрашивать ассоциированную переменную, чтобы узнать, включен флажок или выключен.
Кроме того, в некоторых графических интерфейсах пользователям разрешается устанавливать флажки без вызова обработчиков, зарегистрированных с помощью параметра command, и получать значения где-либо позже в программе. В таком сценарии переменные служат для автоматического запоминания состояний флажков. Представителем этого последнего подхода является метод report в сценарии demoCheck.
Конечно, можно и вручную запоминать состояние каждого флажка в обработчиках событий. В примере 8.23 ведется свой список состояний флажков, который вручную обновляется в обработчиках событий, определяемых с помощью параметра command.
Пример 8.23. PP4E\Gwi\Towr\demo-eheek-manual.py
# флажки, сложный способ (без переменных)
from tkinter import *
states = [] # изменение объекта - не имени
def onPress(i): # сохраняет состояния
states[i] = not states[i] # изменяет False->True, True->False
root = Tk()
for i in range(10):
chk = Checkbutton(root, text=str(i), command=(lambda i=i: onPress(i)) ) chk.pack(side=LEFT) states.append(False) root.mainloop()
print(states) # при выходе вывести все состояния
Здесь lambda-выражение передает индекс нажатой кнопки в списке states. Иначе для каждой кнопки потребовалось бы создавать отдельный обработчик. Здесь мы снова вынуждены использовать аргумент со значением по умолчанию, чтобы передать переменную цикла lambda-выражению. В противном случае все 10 сгенерированных функций получили бы значение переменной цикла, присвоенное ей в последней итерации цикла (щелчок на любом флажке изменял бы состояние десятого элемента в списке - причины такого поведения описываются в главе 7). При запуске этот сценарий создает окно с 10 флажками, как показано на рис. 8.27.
Рис. 8.27. Окно флажков с изменением состояний, производимым вручную
Состояния флажков, поддерживаемые вручную, обновляются при каждом щелчке на флажках и выводятся при выходе из программы (формально, при возврате из вызова mainloop) - это список логических значений, которые можно было бы представить целыми числами 1 и 0, если бы потребовалось в точности имитировать оригинал:
C:\...\PP4E\Gui\Tour> python demo-check-manual.py
[False, False, True, False, True, False, False, False, True, False]
Такой способ действует, и его не столь уж трудно реализовать. Но связанные переменные tkinter заметно упрощают эту задачу, особенно если до какого-то момента в будущем нет необходимости проверять состояния флажков. Это проиллюстрировано в примере 8.24.
Пример 8.24. PP4E\Gui\Tour\demo-eheek-auto.py
# проверка состояния флажков, простой способ
from tkinter import * root = Tk() states = [] for i in range(10): var = IntVar()
chk = Checkbutton(root, text=str(i), variable=var)
chk.pack(side=LEFT)
states.append(var)
root.mainloop() # пусть следит библиотека tkinter
print([var.get() for var in states]) # вывести все состояния при выходе
# (можно также реализовать с помощью
# функции map и lambda-выражение)
Этот сценарий выводит такое же окно и действует точно так же, но здесь мы не передаем обработчики в параметре command, потому что библиотека tkinter автоматически отслеживает изменение состояний:
C:\...\PP4E\Gui\Tour> python demo-check-auto.py
[0, 0, 1, 1, 0, 0, 1, 0, 0, 1]
Смысл здесь в том, что необязательно связывать переменные с флажками, но если сделать это, то работать с графическим интерфейсом будет проще. Между прочим, генератор списков в самом конце этого сценария является эквивалентом следующим вызовам функции map со связанным методом или lambda-выражением в качестве аргумента:
print(list(map(IntVar.get, states))) print(list(map(lambda var: var.get(), states)))
Хотя генераторы списков получили большое распространение в настоящее время, тем не менее то, какая форма наиболее понятна вам, может заметно зависеть от вашего... размера обуви.
Переключатели
Переключатели (или радиокнопки) обычно используются группами: так же, как для механических кнопок выбора станций в старых радиоприемниках, щелчок на одном виджете Radiobutton из группы автоматически делает невыбранными все кнопки, кроме той, на которой был выполнен последний щелчок. Иными словами, одновременно может быть выбрано не более одного виджета. В tkinter связывание всех переключателей из группы с уникальными значениями с одной и той же переменной гарантирует, что в каждый данный момент времени может быть выбрано не более одного переключателя.
Подобно флажкам и обычным кнопкам переключатели поддерживают параметр command для регистрации функции обратного вызова, обрабатывающей щелчок. Подобно флажкам у переключателей также есть атрибут variable для связывания кнопок в группу и получения текущего выбора в произвольный момент времени.
Кроме того, у переключателей есть атрибут value, позволяющий сообщить библиотеке tkinter, какое значение должна иметь ассоциированная переменная, когда выбирается тот или иной переключатель в группе. Поскольку несколько переключателей ассоциируется с одной и той же переменной, каждому переключателю должно соответствовать свое значение (это не просто схема с переключением между 1 и 0). Основы использования переключателей демонстрируются в примере 8.25.
Пример 8.25. PP4E\Gui\Tour\demoRadio.py
“создает группу переключателей, которые вызывают демонстрационные диалоги”
from tkinter import * # импортировать базовый набор виджетов
from dialogTable import demos # обработчики событий
from quitter import Quitter # прикрепить к “себе” объект Quitter
class Demo(Frame):
def __init__(self, parent=None, **options):
Frame.__init__(self, parent, **options)
self.pack()
Label(self, text=”Radio demos”).pack(side=TOP) self.var = StringVar() for key in demos:
Radiobutton(self, text=key,
command=self.onPress,
variable=self.var,
value=key).pack(anchor=NW)
self.var.set(key) # при запуске выбрать последний переключатель Button(self, text=’State’, command=self.report).pack(fill=X) Quitter(self).pack(fill=X)
def onPress(self):
pick = self.var.get() print(‘you pressed’, pick) print(‘result:’, demos[pick]())
def report(self):
print(self.var.get())
if __name__ == ‘__main__’: Demo().mainloop()
На рис. 8.28 изображено окно, которое создается при запуске этого сценария. Щелчок на любом из переключателей в этом окне вызывает обработчик command, запускает один из стандартных диалогов, с которыми мы познакомились выше, и автоматически делает невыбранным переключатель, на котором выполнялся щелчок перед этим. Как и флажки, переключатели здесь также компонуются; в данном сценарии они прикрепляются к верхнему краю, располагаясь по вертикали, а затем выравниваются, прикрепляясь якорями к северо-западному углу отведенного им пространства.
Рис. 8.28. Сценарий demoRadio в действии
Как и в примере с флажками, кнопка State служит для запуска метода report класса и вывода информации о текущем состоянии переключателей (выбранного переключателя). В отличие от примера с флажками, в этом сценарии выводятся также значения, возвращаемые диалогами, которые запускаются щелчками на переключателях. Ниже показано, как выглядит поток stdout после нескольких щелчков на переключателях - информация о состоянии выделена полужирным шрифтом:
C:\...\PP4E\Gui\Tour> python demoRadio.py
you pressed Input result: 3.14 Input
you pressed Open
result: C:/PP4thEd/Examples/PP4E/Gui/Tour/demoRadio.py Open
you pressed Query result: yes Query
Переключатели и переменные
Так зачем здесь нужны переменные? Первое, у переключателей нет метода «get», который позволил бы получить значение выбора. Еще более важно то, что в группах переключателей именно параметры value и variable обслуживают режим выбора единственного варианта. Вообще, работа переключателей обеспечивается тем, что вся группа ассоциируется с одной и той же переменной tkinter и при этом все переключатели имеют различные значения. Чтобы до конца разобраться в этом, нужны еще некоторые сведения о том, как взаимодействуют переключатели и переменные.
Как мы уже видели, при изменении состояния виджета изменяется ассоциируемая с ним переменная tkinter, и наоборот. Но также верно и то, что любое изменение переменной автоматически изменяет каждый виджет, с которым она связана. При работе с переключателями щелчок на одном из них устанавливает значение совместно используемой переменной, которая, в свою очередь, оказывает воздействие на другие переключатели, ассоциированные с этой переменной. При условии, что все переключатели имеют различные значения, это вызывает ожидаемый эффект. Когда в результате щелчка на переключателе значение совместно используемой переменной изменяется на значение выбранного переключателя, все остальные переключатели оказываются невыбранными, потому что значение переменной не совпадает с их значениями.
Это правило действует в обоих направлениях: когда пользователь выбирает переключатель - он неявно изменяет значение совместно используемой переменной; когда сценарий изменяет значение переменной, -он изменяет состояние переключателей. Например, когда сценарий в примере 8.25 на этапе инициализации присваивает совместно используемой переменной последнее значение последнего переключателя (вызовом self.var.set), он выбирает последний переключатель, а остальные автоматически становятся невыбранными. В результате изначально будет выбран только один переключатель. Если бы в переменную была записана строка, не являющаяся именем какого-либо демонстрационного диалога (например, ‘ ‘ ), все переключатели при запуске оказались бы невыбранными.
Это довольно тонкий волновой эффект, но его будет проще понять, представив картину с другой стороны: если в группе переключателей, связанных с одной и той же переменной, назначить нескольким переключателям одно и то же значение, то при щелчке на любом из них все они будут автоматически выбраны. Рассмотрим пример 8.26 и рис. 8.29. При запуске сценария не выбран ни один переключатель (так как совместно используемая переменная инициализирована значением, не соответствующим ни одному из значений переключателей), но поскольку переключатели 0, 3, 6 и 9 - имеют значение 0 (остаток от деления на 3), при выборе любого из них выбираются они все.
Рис. 8.29. Переключатели испортились?
Пример 8.26. PP4E\Gui\Tour\demo-radio-multi.py
# посмотрите, что произойдет, если несколько переключателей
# будут иметь одно и то же значение
from tkinter import * root = Tk() var = StringVar() for i in range(10):
rad = Radiobutton(root, text=str(i), variable=var, value=str(i % 3)) rad.pack(side=LEFT)
var.set(‘ ‘) # все переключатели сделать невыбранными
root.mainloop()
Если теперь щелкнуть на любом из переключателей 1, 4 или 7, будут выбраны все три, а предыдущие выбранные окажутся сброшенными (их значение не равно «1»). Обычно это не то, что требуется, - переключатели как правило используются для представления групп с возможностью выбора единственного варианта (возможность выбора сразу нескольких вариантов реализуется с помощью флажков). Если вы хотите, чтобы переключатели действовали, как им положено, следите за тем, чтобы всем переключателям была назначена одна и та же переменная, но разные значения. Например, в сценарии demoRadio имя демонстрационного диалога дает естественное уникальное значение для каждой кнопки.
Переключатели без переменных
Строго говоря, в этом примере мы могли бы обойтись и без переменных tkinter. В примере 8.27 также реализована модель с одним выбором, но без переменных, - путем выбора и сброса элементов в группе вручную, в обработчике события. При каждом событии щелчка на переключателе вызывается метод deselect для всех объектов в группе и метод select для того переключателя, на котором был выполнен щелчок.
Пример 8.27. PP4E\Gui\Tour\demo-radio-manual.py
переключатели, сложный способ (без переменных)
обратите внимание, что метод deselect переключателя просто устанавливает пустую строку в качестве его значения, поэтому нам по-прежнему требуется присвоить переключателям уникальные значения или использовать флажки;
from tkinter import * state = ‘’ buttons = []
def onPress(i): global state state = i
for btn in buttons:
btn.deselect()
buttons[i].select()
root = Tk()
for i in range(10):
rad = Radiobutton(root, text=str(i),
value=str(i), command=(lambda i=i: onPress(i)) )
rad.pack(side=LEFT)
buttons.append(rad)
onPress(0) # первоначально выбрать первый переключатель
root.mainloop()
print(state) # вывести информацию о состоянии перед выходом
Этот сценарий создает такое же окно с 10 переключателями, как на рис. 8.29, но реализует интерфейс с единственным выбором, причем текущее состояние хранится в глобальной переменной Python, значение которой выводится при завершении сценария. Все это библиотека tkinter может сделать вместо вас, если использовать связанную переменную tkinter и уникальные значения, как показано в примере 8.28.
Пример 8.28. PP4E\Gui\Tour\demo-radio-auto.py
# переключатели, простой способ
from tkinter import *
root = Tk() # IntVar также можно использовать
var = IntVar(0) # выбрать 0-й переключатель при запуске
for i in range(10):
rad = Radiobutton(root, text=str(i), value=i, variable=var) rad.pack(side=LEFT) root.mainloop()
print(var.get()) # вывести информацию о состоянии перед выходом
Этот сценарий действует точно так же, но вводить и отлаживать его значительно проще. Обратите внимание, что в этом сценарии переключатели связываются с переменной типа IntVar, целочисленным собратом StringVar, которая инициализируется нулевым значением (которое также является значением по умолчанию) - если значения переключателей уникальны, можно также пользоваться и целыми числами.
Берегите свои переменные!
Небольшое предостережение: в целом следует сохранять объект переменной tkinter, используемой для связи с переключателями в течение всего времени, пока переключатели отображаются на экране. Присвойте ссылку на объект глобальной переменной модуля, запомните в структуре данных с длительным временем существования или сохраните как атрибут долгоживущего объекта класса, как сделано в сценарии demoRadio. Просто сохраните ссылку на него где-нибудь. В этом случае у вас всегда будет возможность тем или иным способом получить информацию о состоянии, и вас вряд ли когда-нибудь коснется то, о чем я хочу рассказать.
В текущей версии tkinter классы переменных обладают деструктором
__del__, который автоматически сбрасывает созданную переменную Tk,
когда уничтожается объект Python (то есть утилизируется сборщиком мусора). В итоге все ваши переключатели могут оказаться невыбранными, если объект переменной будет утилизирован, по крайней мере, до того момента, когда очередной щелчок мышью установит новое значение переменной Tk. В примере 8.29 демонстрируется ситуация, в которой это может случиться.
Пример 8.29. PP4E\Gui\Tour\demo-radio-elear.py
# берегите переменные переключателей (о чем действительно легко можно забыть)
from tkinter import * root = Tk()
def radio1(): # локальные переменные являются временными
#global tmp # сделав их глобальными, вы решите проблему
tmp = IntVar() for i in range(10):
rad = Radiobutton(root, text=str(i), value=i, variable=tmp) rad.pack(side=LEFT)
tmp.set(5) # выбрать 6-й переключатель
radio1()
root.mainloop()
Кажется, что первоначально должен быть выбран переключатель «5», но этого не происходит. Локальная переменная tmp уничтожается при выходе из функции, переменная Tk сбрасывается и значение 5 теряется (все переключатели оказываются невыбранными). Тем не менее эти переключатели прекрасно работают, если попробовать выполнять на них щелчки мышью, поскольку при этом переменная Tk переустанавливается. Если раскомментировать инструкцию global, кнопка 5 будет появляться в выбранном состоянии, как и задумывалось.
Однако в версии Python 3.X это явление, похоже, приобрело дополнительные отрицательные черты: в этой версии переключатель «5» не только не выбирается изначально, но и перемещение указателя мыши над невыбранными переключателями порождает эффект незаказанного выбора многих их них, пока не будет выполнен щелчок мышью. (В версии 3.X также требуется инициализировать строковую переменную StringVar, совместно используемую переключателями, как мы делали это в предыдущих примерах; в противном случае переменная получит пустую строку, как значение по умолчанию, что переведет все переключатели в выбранное состояние!)
Конечно, это нетипичный пример - в таком виде невозможно узнать, какая кнопка нажата, потому что переменная не сохраняется (и параметр command не установлен). Довольно бессмысленно использовать группу переключателей, если позднее нельзя получить значение выбора. Фактически это настолько невразумительно, что я отсылаю вас к примеру demo-radio-elear2.py в пакете примеров для книги, в котором делается попытка другими способами заставить проявиться эту странность. Возможно, вам это не понадобится, но если вы столкнетесь с этим, не говорите, что я вас не предупреждал.
Ползунки
Ползунки («scales» или «sliders») используются для выбора значения из диапазона чисел. Перемещение ползунка с помощью перетаскивания или щелчка мышью изменяет значение виджета в диапазоне целых чисел и запускает обработчик, если он зарегистрирован.
Подобно флажкам и переключателям ползунки обладают параметром command для регистрации управляемого событиями обработчика, выполняемого немедленно при перемещении ползунка, а также параметром variable для связи с переменной tkinter, которая позволяет в любой момент времени получить или установить положение ползунка. Обрабатывать значение можно сразу же после его установки или позже.
Кроме того, у ползунков есть третий способ обработки - методы get и set, с помощью которых можно непосредственно обращаться к значению виджета, не связывая с ним переменную. Поскольку обработчики, регистрируемые с помощью параметра command, получают текущее значение ползунка в качестве аргумента, часто этого достаточно, чтобы не прибегать к связанным переменным или вызовам методов get/set.
Для иллюстрации основ применения этого элемента в примере 8.30 приводится сценарий, который создает два ползунка - горизонтальный и вертикальный, связанные между собой через ассоциированную переменную, что позволяет их синхронизировать.
Пример 8.30. PP4E\Gui\Tour\demoSeale.py
“создает два связанных ползунка для запуска демонстрационных диалогов”
from tkinter import * # импортировать базовый набор виджетов
from dialogTable import demos # обработчики событий
from quitter import Quitter # прикрепить к “себе” объект Quitter
class Demo(Frame):
def __init__(self, parent=None, **options):
Frame.__init__(self, parent, **options)
self.pack()
Label(self, text=”Scale demos”).pack() self.var = IntVar()
Scale(self, label=’Pick demo number’,
command=self.onMove, # перехватывать перемещения variable=self.var, # отражает положение from_=0, to=len(demos)-1).pack()
Scale(self, label=’Pick demo number’,
command=self.onMove, # перехватывать перемещения variable=self.var, # отражает положение from_=0, to=len(demos)-1, length=200, tickinterval=1, showvalue=YES, orient=’horizontal’).pack() Quitter(self).pack(side=RIGHT)
Button(self, text=”Run demo”, command=self.onRun).pack(side=LEFT) Button(self, text=”State”, command=self.report).pack(side=RIGHT)
def onMove(self, value):
print(‘in onMove’, value)
def onRun(self):
pos = self.var.get() print(‘You picked’, pos)
demo = list(demos.values())[pos] # отображение позиции на ключ
# (представление в версии 3.X)
print(demo()) # или
# demos[ list(demos.keys())[pos] ]()
def report(self):
print(self.var.get())
if__name__== ‘__main__’:
print(list(demos.keys()))
Demo().mainloop()
Кроме доступа к значениям и регистрации обработчиков у ползунков имеются параметры, соответствующие понятию диапазона выбираемых значений, большинство из которых продемонстрировано в этом примере:
• Параметр label позволяет определить текст, появляющийся рядом со шкалой, параметр length позволяет определить начальный размер в пикселях, а параметр orient - направление.
• Параметры from_ и to позволяют определить минимальное и максимальное значения шкалы (обратите внимание, что from в языке Python является зарезервированным словом, а from_ - нет).
• Параметр tickinterval позволяет определить количество единиц измерения между отметками, наносимыми рядом со шкалой через равные интервалы (значение 0 по умолчанию означает, что отметки не выводятся).
• Параметр resolution позволяет определить количество единиц, на которое изменяется значение ползунка при каждом перетаскивании или щелчке левой кнопки мыши (по умолчанию 1).
• Параметр showvalue позволяет определить, должно ли отображаться текущее значение рядом с ползунком (по умолчанию showvalue=YES, то есть отображается).
Обратите внимание, что ползунки тоже прикрепляются к своим контейнерам, как и прочие виджеты tkinter. Посмотрим, как эти параметры используются на практике. На рис. 8.30 изображено окно, создаваемое этим сценарием в Windows 7 (в Unix и Mac получается аналогичная картина).
Рис. 8.30. Сценарий demoSeale в действии
Для наглядности кнопка State выводит текущие значения ползунков, а Run demo - запускает те же стандартные диалоги, используя целочисленные значения ползунков в качестве индекса таблицы demos. Сценарий также регистрирует обработчик command, который вызывается при каждом перемещении ползунка по любой из шкал и выводит новые значения ползунков. Ниже приводятся сообщения, отправленные в поток stdout после нескольких перемещений, с информацией о запускаемых демонстрационных диалогах (курсив) и о значениях ползунка (полужирный):
C:\...\PP4E\Gui\Tour> python demoScale.py
[‘Color’, ‘Query’, ‘Input’, ‘Open’, ‘Error’] in onMove 0 in onMove 0 in onMove 1 1
in onMove 2 You picked 2
123.0
in onMove 3 3
You picked 3
C:/Users/mark/Stuff/Books/4E/PP4E/dev/Examples/PP4E/Launcher.py
Ползунки и переменные
Как можно догадаться, ползунки предлагают различные способы обработки своих значений: непосредственно в обработчике события перемещения или позже, путем получения текущего положения через переменные или вызовы методов. В действительности переменные tkinter вообще не нужны для программирования ползунков - достаточно зарегистрировать обработчик события перемещения или вызывать метод get ползунка, чтобы при необходимости получать значение шкалы, как показано в более простом примере 8.31.
Пример 8.31. PP4E\Gui\Tour\demo-seale-simple.py
from tkinter import * root = Tk()
scl = Scale(root, from_=-100, to=100, tickinterval=50, resolution=10) scl.pack(expand=YES, fill=Y)
def report():
print(scl.get())
Button(root, text=’state’, command=report).pack(side=RIGHT) root.mainloop()
На рис. 8.31 изображены два экземпляра этой программы, запущенные в Windows, окно одной из них растянуто, а другой - нет (ползунки
Рис. 8.31. Простая шкала без переменных
настроены так, чтобы они растягивались по вертикали). Шкала имеет диапазон значений от -100 до 100, использует параметр resolution для изменения текущей позиции на 10 единиц вверх или вниз при каждом перемещении, а параметр tickinterval установлен так, чтобы рядом со шкалой отображались метки с шагом 50. Если щелкнуть на кнопке State в окне этого сценария, будет вызван метод get шкалы для получения и вывода текущего значения без всяких переменных или обратных вызовов:
C:\...\PP4E\Gui\Tour> python demo-scale-simple.py
0
60
-70
Честно говоря, единственный повод использовать переменные tkinter в сценарии demoScale - это синхронизация шкал. Чтобы сделать пример более интересным, в этом сценарии один и тот же объект переменной tkinter связан с обеими шкалами. Как было показано в предыдущем разделе, изменение состояния виджета влечет за собой изменение его переменной, а изменение переменной изменяет состояние всех связанных с ней виджетов. Другими словами, это означает, что перемещение ползунка обновляет переменную, которая, в свою очередь, может обновить все другие виджеты, связанные с той же переменной. Так как в этом сценарии одна переменная связана с двумя шкалами, они автоматически становятся синхронизированными: перемещение одного ползунка вызывает перемещение другого, потому что при этом изменяется совместно используемая переменная, побочным эффектом чего является обновление другого ползунка.
Ваши приложения могут использовать или не использовать подобный прием синхронизации ползунков (граничащий с глубокой магией), но если задуматься, то это очень мощное средство. Связывая несколько виджетов с помощью переменных tkinter, можно автоматически синхронизировать их и избежать необходимости вручную корректировать значения виджетов в обработчиках событий. С другой стороны, синхронизацию можно обеспечить и без совместно используемой переменной, вызывая метод set одного ползунка из обработчика другого. Такое изменение вручную я оставляю читателю в качестве самостоятельного упражнения. Что для одного глубокая магия, для другого может оказаться привычной рутиной.
Три способа использования графических интерфейсов
После того как мы создали ряд похожих программ для запуска демонстрационных примеров, напишем несколько объединяющих их сценариев верхнего уровня. Поскольку демонстрационные примеры были написаны так, что их можно использовать в виде классов или сценариев, они могут быть использованы как компоненты, прикрепляемые к фреймам, могут запускаться в собственных окнах верхнего уровня или как самостоятельные программы. Все три варианта иллюстрируют принцип многократного использования программного кода в действии.
Прикрепление к фреймам
Чтобы проиллюстрировать иерархическое построение графического интерфейса в более крупном масштабе, чем это делалось до сих пор, пример 8.32 объединяет все четыре сценария панелей запуска диалогов из этой главы в одном контейнере. В нем повторно используется программный код примеров 8.9, 8.22, 8.25 и 8.30.
Пример 8.32. PP4E\Gui\Tour\demoAll-frm.py
4 класса демонстрационных компонентов (вложенных фреймов) в одном окне; в одном окне присутствуют также 5 кнопок Quitter, причем щелчок на любой из них приводит к завершению программы; графические интерфейсы могут повторно использоваться, как фреймы в контейнере, независимые окна или процессы;
from tkinter import * from quitter import Quitter
demoModules = [‘demoDlg’, ‘demoCheck’, ‘demoRadio’, ‘demoScale’] parts = []
def addComponents(root): for demo in demoModules:
module = __import__(demo) # импортировать по имени в виде строки
part = module.Demo(root) # прикрепить экземпляр
part.config(bd=2, relief=GROOVE) # или передать параметры
# конструктору Demo()
part.pack(side=LEFT, expand=YES, fill=BOTH) # растягивать
# вместе с окном
parts.append(part) # добавить в список
def dumpState():
for part in parts:
print(part.__module__ + ‘:’, end=’ ‘)
if hasattr(part, ‘report’): # вызвать метод report,
part.report() # если имеется
else:
print(‘none’)
root = Tk() # явно создать корневое окно
root.title(‘Frames’)
Label(root, text=’Multiple Frame demo’, bg=’white’).pack()
Button(root, text=’States’, command=dumpState).pack(fill=X)
Quitter(root).pack(fill=X)
addComponents(root)
root.mainloop()
Поскольку все четыре демонстрационные панели запуска реализованы в виде фреймов, которые могут прикрепляться к родительским виджетам, объединить их в одном графическом интерфейсе намного проще, чем вы думаете. Для этого нужно лишь передать один и тот же родительский виджет (в данном случае окно root) во все четыре вызова конструкторов демонстрационных примеров, после чего скомпоновать и настроить созданные демонстрационные объекты желаемым образом. На рис. 8.32 показано, как выглядит результат - одно окно, в которое встроены экземпляры всех четырех знакомых нам демонстрационных панелей запуска диалогов. В данном примере все четыре встроенных панели изменяют свои размеры при изменении размеров окна (попробуйте убрать параметр expand=YES, чтобы панели сохраняли свои размеры постоянными).
Рис. 8.32. demoAll_frm: вложенные фреймы
Конечно, этот пример является искусственным, но он демонстрирует мощь приема композиции при создании больших графических интерфейсов. Если на месте демонстрационных объектов вы представите себе что-нибудь более полезное, например текстовый редактор, калькулятор или часы, то лучше поймете значение этого примера.
Кроме фреймов демонстрационных объектов это составное окно содержит не менее пяти экземпляров написанной ранее кнопки Quitter (любая из них может завершить работу этой программы) и кнопку States для вывода текущих значений сразу всех встроенных демонстрационных объектов (она вызывает метод report каждого объекта, у которого он есть). Ниже приводится пример вывода в потоке stdout после взаимодействия с виджетами в этом окне; вывод, полученный в результате щелчка на кнопке States, выделен полужирным шрифтом:
C:\...\PP4E\Gui\Tour> python demoAll_frm.py
in onMove 0 in onMove 0 demoDlg: none demoCheck: 0 0 0 0 0 demoRadio: Error demoScale: 0 you pressed Input result: 1.234 in onMove 1 demoDlg: none demoCheck: 1 0 1 1 0 demoRadio: Input demoScale: 1 you pressed Query result: yes in onMove 2 You picked 2 None
in onMove 3 You picked 3
C:/Users/mark/Stuff/Books/4E/PP4E/dev/Examples/PP4E/Launcher.py
3
Query 1 1 1 1 0 demoDlg: none demoCheck: 1 1 1 1 0 demoRadio: Query demoScale: 3
Импортирование по имени в виде строки
Единственным хитроумным приемом в этом сценарии является использование встроенной функции__import__, импортирующей модуль по
его имени в виде строки. Взглянем на следующие две строки из функции addComponents сценария:
module = __import__(demo) # импортировать по имени в виде строки
part = module.Demo(root) # прикрепить экземпляр, созданный его классом Demo
Они эквивалентны следующим строкам:
import ‘demoDlg’
part = ‘demoDlg’.Demo(root)
Однако последние две инструкции являются недопустимыми в языке Python - имя модуля в инструкциях импорта должно быть идентификатором Python, а не строковым значением. Кроме того, имена модулей в инструкциях импорта интерпретируются буквально (то есть не вычисляются), и в точечной нотации идентификаторы должны выражать объект (а не строку с именем). Для обеспечения общности функция ad-
dComponents обходит список строк с именами и с помощью__import__
импортирует и возвращает модуль, идентифицируемый каждой строкой. Фактически действие цикла for эквивалентно следующим инструкциям:
import demoDlg, demoRadio, demoCheck, demoScale
part = demoDlg.Demo(root)
part = demoRadio.Demo(root)
part = demoCheck.Demo(root)
part = demoScale.Demo(root)
Использование в сценарии списка строк с именами упрощает изменение набора встраиваемых демонстраций - достаточно лишь изменить список, не трогая выполняемый код. Кроме того, такая реализация, управляемая данными, оказывается более компактной, менее избыточной и проще в отладке и в сопровождении. Между прочим, имеется еще одна возможность импортировать модули по их именам в виде строк, динамически создавая и выполняя инструкции импорта, как показано ниже:
for demo in demoModules:
exec(‘from %s import Demo’ % demo) # сконструировать и выполнить from part = eval(‘Demo’)(root) # получить ссылку на импортированный
# объект по его имени в виде строки
Функция exec компилирует и выполняет строку с инструкцией Python (в данном случае from, загружающей класс Demo из модуля). Она действует, как если бы вместо вызова функции exec в исходный текст была вставлена строка с инструкцией. Следующий фрагмент позволяет добиться того же эффекта, но конструируя инструкцию import:
for demo in demoModules:
exec(‘import %s’ % demo) # сконструировать и выполнить import part = eval(demo).Demo(root) # получить ссылку на объект модуля
# также по имени в виде строки
Так как функции exec/eval поддерживают любые инструкции Python, этот прием оказывается более универсальным, чем использование
функции__import__, но он может замедлять работу, потому что при
этом требуется производить синтаксический анализ строк программного кода перед их выполнением.1 Такое замедление может быть несущественным для графических интерфейсов - пользователи работают значительно медленнее, чем синтаксические анализаторы.
1 Как будет показано дальше, exec может представлять опасность, если выполняет строки, полученные от пользователей или по сети. Это не относится к жестко определенным строкам в данном примере.
Настройка на этапе конструирования
Еще одна альтернатива, о которой следует упомянуть: обратите внимание, как в примере 8.32 выполняется настройка и компоновка каждого прикрепляемого демонстрационного фрейма:
def addComponents(root): for demo in demoModules:
module = __import__(demo) # импортировать по имени в виде строки
part = module.Demo(root) # прикрепить экземпляр
part.config(bd=2, relief=GROOVE) # или передать параметры
# конструктору Demo()
part.pack(side=LEFT, expand=YES, fill=BOTH) # растягивать
# вместе с окном
Однако благодаря тому что демонстрационные классы поддерживают параметры настройки, используя аргумент **options, мы могли бы выполнять настройки прямо на этапе создания. Например, если изменить реализацию сценария, как показано ниже, он воспроизведет несколько отличающееся окно, изображенное на рис. 8.33 (для иллюстрации несколько растянутое по горизонтали; вы найдете эту реализацию в файле demoAll-frm-ridge.py в пакете с примерами):
def addComponents(root): for demo in demoModules:
module = __import__(demo) # импортировать по имени в виде строки
part = module.Demo(root, bd=6, relief=RIDGE) # прикрепить, настроить part.pack(side=LEFT, expand=YES, fill=BOTH) # экземпляр так, чтобы он
# растягивался с окном
Рис. 8.33. demoAll_frm: настройка на этапе конструирования
Поскольку демонстрационные классы одновременно являются подклассами Frame и поддерживают привычный протокол передачи аргументов конструкторов, они являются настоящими виджетами - специализированными фреймами tkinter, реализующими прикрепляемые пакеты виджетов, и обеспечивающими гибкие возможности настройки.
В главе 7 было показано, что такое прикрепление вложенных фреймов является лишь одним из способов повторного использования программного кода реализации графических интерфейсов, оформленного в виде классов. Столь же просто можно организовывать такие интерфейсы путем создания подклассов, а не встраивания. Однако в данном случае нас больше интересует применение существующего пакета виджетов, чем его изменение, поэтому прием встраивания полностью соответствует нашим потребностям. В следующих двух разделах показаны еще два способа представления таких пакетов виджетов пользователям - в виде независимых окон и в виде автономных программ.
Независимые окна
Когда есть набор классов компонентов, реализованных в виде фреймов, годится любой родительский элемент - и фреймы, и новые окна верхнего уровня. В примере 8.33 все четыре объекта демонстрационных панелей прикрепляются к собственным независимым окнам Toplevel, а не к одному и тому же контейнеру.
Пример 8.33. PP4E\Gui\Tour\demoAll-win.py
4 демонстрационных класса в независимых окнах верхнего уровня; не процессы: при завершении одного щелчком на кнопке Quit завершаются все остальные, потому что все окна выполняются в одном и том же процессе; здесь первое окно Tk создается вручную, иначе будет создано пустое окно
from tkinter import *
demoModules = [‘demoDlg’, ‘demoRadio’, ‘demoCheck’, ‘demoScale’]
def makePopups(modnames): demoObjects = [] for modname in modnames:
module = __import__(modname) # импортировать по имени в виде строки
window = Toplevel() # создать новое окно
demo = module.Demo(window) # родительским является новое окно
window.title(module.__name__)
demoObjects.append(demo) return demoObjects
def allstates(demoObjects): for obj in demoObjects:
if hasattr(obj, ‘report’):
print(obj.__module__, end=’ ‘)
obj.report()
root = Tk() # явно создать корневое окно
root.title(‘Popups’)
demos = makePopups(demoModules)
Label(root, text=’Multiple Toplevel window demo’, bg=’white’).pack()
Button(root, text=’States’, command=lambda: allstates(demos)).pack(fill=X) root.mainloop()
Мы уже встречались с классом Toplevel - каждый его экземпляр создает на экране новое окно. Получаемый результат изображен на рис. 8.34 -каждая демонстрационная панель выполняется не в общем, а в собственном окне.
Рис. 8.34. demoAll_win: новые окна Toplevel
Главное корневое окно на этом рисунке находится в левом нижнем углу. На нем есть кнопка States, которая вызывает метод report каждого демонстрационного объекта, выводя в stdout примерно такой текст:
C:\...\PP4E\Gui\Tour> python demoAll_win.py
in onMove 0 in onMove 0 in onMove 1 you pressed Open
result: C:/Users/mark/Stuff/Books/4E/PP4E/dev/Examples/PP4E/Launcher.py demoRadio Open demoCheck 1 1 0 0 0 demoScale 1
Как было показано ранее в этой главе, окна Toplevel функционируют независимо друг от друга, но в действительности они не являются отдельными программами. Закрытие любого из окон на рис. 8.34 щелчком на кнопке X в правом верхнем углу закрывает только это окно. Но попытка закрыть окно щелчком на кнопке Quit или на кнопке X в главном окне закроет их все и завершит все приложение, потому что все они выполняются в одном и том же программном процессе. В некоторых приложениях это приемлемо, но не во всех. Чтобы обеспечить настоящую независимость, необходимо порождать дочерние процессы, как показано в следующем разделе.
Запуск программ
Для обеспечения большей независимости в примере 8.34 каждая из демонстрационных панелей запускается, как независимая программа (процесс), с помощью модуля launchmodes, который мы написали в конце главы 5. Это работает потому, что все демонстрационные примеры были написаны и как импортируемые классы, и как выполняемые сценарии.
При запуске их таким образом каждая из них получает имя__main__,
потому что являются отдельными, независимыми программами; а это, в свою очередь, приводит к запуску mainloop в конце каждого файла.
Пример 8.34. PP4E\Gui\Tour\demoAll-prg.py
4 демонстрационных класса, выполняемых как независимые процессы: команды; если теперь одно окно будет завершено щелчком на кнопке Quit, остальные продолжат работу; в данном случае не существует простого способа вызвать все методы report (впрочем, для организации взаимодействий между процессами можно было бы воспользоваться сокетами и каналами), а кроме того, некоторые способы запуска могут сбрасывать поток stdout дочерних программ и разрывать связь между родителем и потомком;
from tkinter import *
from PP4E.launchmodes import PortableLauncher
demoModules = [‘demoDlg’, ‘demoRadio’, ‘demoCheck’, ‘demoScale’]
for demo in demoModules: # смотрите главу 5
PortableLauncher(demo, demo + ‘.py’)() # запуск в виде программ верхнего
# уровня
root = Tk()
root.title(‘Processes’)
Label(root, text=’Multiple program demo: command lines’, bg=’white’).pack() root.mainloop()
Перед запуском этого сценария убедитесь, что корневой каталог с примерами PP4E находится в пути поиска модулей (например, включен в переменную окружения PYTHONPATH) - он импортирует модуль из другого подкаталога. Как видно из рис. 8.35, создаваемый данным сценарием интерфейс аналогичен предыдущему - все четыре демонстрации появляются в собственных окнах.
Однако на этот раз окна действительно являются независимыми программами: при завершении любого из пяти имеющихся окон остальные продолжают работу. Демонстрационные программы будут выполняться, даже если закрыть окно родительского процесса. В Windows окно командной строки, откуда был запущен этот сценарий, снова становится активным и готовым для ввода следующей команды, притом, что дочерние программы продолжают выполняться. Здесь мы повторно использовали программный код демонстрационных примеров, запуская их как самостоятельные программы, а не как модули.
Рис. 8.35. demoAll_prg: независимые программы
Запуск графических интерфейсов как самостоятельных программ другими способами: модуль multiprocessing
Если вернуться к главе 5 и рассмотреть реализацию модуля запуска процессов переносимым способом, использованным в примере 8.34, можно заметить, что в Windows он использует функцию os.spawnv, а в других системах - os.fork/exec. То есть графические интерфейсы в данном примере запускаются выполнением команд оболочки. Эти способы прекрасно справляются со своей задачей, но, как мы узнали в главе 5, они входят в состав более обширного набора инструментов запуска программ, в число которых также входят os.popen, os.system, os.startfile и модули subprocess и multiprocessing. Эти инструменты могут отличаться деталями подключения к окну консоли, реакцией на завершение родительского процесса и так далее.
Например, модуль multiprocessing, с которым мы познакомились в главе 5, предоставляет похожий переносимый способ запуска других графических интерфейсов в виде независимых процессов, как показано в примере 8.35. Если запустить его, он воспроизведет точно такое же окно, как на рис. 8.35, но с другими метками в главном окне.
Пример 8.35. PP4E\Gui\Tour\demoAll-prg-multi.py
4 демонстрационных класса, выполняемых как независимые процессы: multiprocessing;
модуль multiprocessing позволяет запускать только именованные функции с аргументами - он не может работать с lambda-выражениями, поскольку в Windows они не могут быть сериализованы (глава 5); кроме того, модуль multiprocessing имеет собственные инструменты взаимодействий между процессами, такие как каналы;
from tkinter import *
from multiprocessing import Process
demoModules = [‘demoDlg’, ‘demoRadio’, ‘demoCheck’, ‘demoScale’]
def runDemo(modname): # запускается в новом процессе
module = import (modname) # создать GUI с нуля
module.Demo().mainloop()
if__name__== ‘__main__’:
for modname in demoModules: # только в __main__!
Process(target=runDemo, args=(modname,)).start()
root = Tk() # граф. интерфейс родительского процесса
root.title(‘Processes’)
Label(root, text=’Multiple program demo: multiprocessing’, bg=’white’).pack() root.mainloop()
При запуске в Windows эта версия имеет только следующие функциональные отличия:
• Вывод дочерних процессов отображается в том же окне консоли, откуда был запущен этот сценарий, включая вывод, порождаемый самими демонстрационными диалогами и всеми кнопками State.
• Сценарий не завершается, если хотя бы один дочерний процесс продолжает выполнение: окно консоли в данном примере блокируется при попытке закрыть окно главного процесса, пока дочерние процессы продолжают работу, если только не установить флаг daemon дочерних процессов в значение True перед их запуском, как было показано в главе 5, - в этом случае все дочерние процессы автоматически будут завершены вместе с их родителем (но родитель по-прежнему может пережить своих потомков).
Обратите также внимание, как мы запускаем простую именованную функцию в новом процессе Process. Как мы узнали в главе 5, в Windows в аргументе target допускается передавать только сериализуемые выполняемые объекты (то есть те, которые можно импортировать), поэтому мы не можем использовать lambda-выражения для передачи дополнительных данных, как мы обычно делали это в обработчиках событий tkinter. Следующие два варианта реализации будут терпеть неудачу в Windows:
Process(target=(lambda: runDemo(modname))).start() # оба терпят неудачу!
Process(target=(lambda: __import__(modname).Demo().mainloop())).start()
Мы не будем здесь пытаться реализовать сценарий запуска программ с графическим интерфейсом всеми возможными способами, но вы можете поэкспериментировать с ними самостоятельно, используя главу 5, как источник информации по этой теме. Хотя это решение и не везде применимо, тем не менее в целом смысл использования инструментов, таких как класс PortableLauncher, - скрыть большинство таких подробностей, что позволило бы нам практически забыть о них.
Обмен данными между программами
Запуск графических интерфейсов в виде самостоятельных программ -вершина независимости кода, но это затрудняет связь между компонентами. Например, поскольку демонстрационные примеры выполняются здесь в виде отдельных программ, нет простого способа вызвать все их методы 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, после того как рассмотрим темы, связанные с созданием многопоточных графических интерфейсов. Но поскольку это выходит далеко за рамки представленных простых демонстрационных программ, я оставляю реализацию таких межпрограммных взаимодействий тем из читателей, кто лучше подготовлен к мышлению в категориях параллельных процессов.
Программирование, обеспечивающее повторное использование
Постскриптум: я реализовал все демонстрационные панели запуска, разворачиваемые в четырех последних примерах так, чтобы продемонстрировать различные способы использования их виджетов. Они разрабатывались без учета возможности многократного их использования - на самом деле они не слишком полезны вне контекста знакомства с виджетами в данной книге.
Так было задумано - большинством графических элементов tkinter легко пользоваться после изучения их интерфейсов, а библиотека tkinter в значительной мере сама обеспечивает значительную гибкость настройки. Но если бы я задумал реализовать классы флажков и переключателей, которые можно повторно использовать как универсальные библиотечные компоненты, их нужно было бы структурировать иным образом:
Лишние виджеты
Они не должны выводить ничего, кроме переключателей и флажков. В существующем виде в каждый демонстрационный пример для иллюстрации встроены кнопки State и Quit, но в действительности у каждого окна верхнего уровня должна быть только одна кнопка Quit.
Управление компоновкой
Они должны допускать различное расположение кнопок и вообще никак не компоновать себя (ни методом pack, ни методом grid). В по-настоящему универсальных реализациях для повторного использования часто лучше передоверить вызывающей программе самой управлять размещением компонентов.
Ограничения режима использования
Они должны либо экспортировать сложные интерфейсы для поддержки всех параметров настройки и режимов tkinter, либо принять ограничивающие решения, поддерживающие только один общий способ применения. Например, эти кнопки могут вызывать обработчики при нажатии или позволить приложению получать их состояние позже.
В примере 8.36 демонстрируется один из способов реализации панелей флажков и переключателей как библиотечных компонентов. Он основывается на связывании переменных tkinter и для обеспечения простоты интерфейса требует, чтобы вызывающая программа использовала наиболее общий режим - получение информации о состоянии вместо обработчиков событий - чтобы упростить интерфейс.
Пример 8.36. PP4E\Gui\Tour\bwttonbars.py
классы панелей флажков и переключателей для приложений, которые запрашивают информацию о состоянии позднее;
передается список вариантов выбора, вызывается метод state(), работа с переменными выполняется автоматически
from tkinter import * class Checkbar(Frame):
def __init__(self, parent=None, picks=[], side=LEFT, anchor=W):
Frame.__init__(self, parent)
self.vars = [] for pick in picks: var = IntVar()
chk = Checkbutton(self, text=pick, variable=var) chk.pack(side=side, anchor=anchor, expand=YES) self.vars.append(var) def state(self):
return [var.get() for var in self.vars] class Radiobar(Frame):
def __init__(self, parent=None, picks=[], side=LEFT, anchor=W):
Frame.__init__(self, parent)
self.var = StringVar() self.var.set(picks[0]) for pick in picks:
rad = Radiobutton(self, text=pick, value=pick, variable=self.var) rad.pack(side=side, anchor=anchor, expand=YES) def state(self):
return self.var.get()
if__name__== ‘__main__’:
root = Tk()
lng = Checkbar(root, [‘Python’, ‘C#’, ‘Java’, ‘C++’])
gui = Radiobar(root, [‘win’, ‘x11’, ‘mac’], side=TOP, anchor=NW)
tgl = Checkbar(root, [‘All’])
gui.pack(side=LEFT, fill=Y) lng.pack(side=TOP, fill=X) tgl.pack(side=LEFT) lng.config(relief=GROOVE, bd=2) gui.config(relief=RIDGE, bd=2)
def allstates():
print(gui.state(), lng.state(), tgl.state())
from quitter import Quitter Quitter(root).pack(side=RIGHT)
Button(root, text=’Peek’, command=allstates).pack(side=RIGHT) root.mainloop()
Для повторного использования этих классов в сценариях нужно импортировать их и вызвать со списком вариантов выбора, которые должны появиться на панелях флажков или переключателей. Программный код самотестирования модуля, находящийся в конце, демонстрирует особенности использования этих классов. Если запустить этот пример как самостоятельный сценарий, на экране появится окно верхнего уровня, изображенное на рис. 8.36, с двумя встроенными панелями Checkbar, одной панелью Radiobar, кнопкой Quitter для завершения, а также кнопкой Peek для вывода информации о состоянии панелей.
Рис. 8.36. Окно самотестирования сценария buttonbars
Ниже приводится содержимое стандартного потока вывода stdout после щелчка на кнопке Peek - результат вызова методов state этих классов:
x11 [1, 0, 1, 1] [0]
win [1, 0, 0, 1] [1]
Два класса из этого модуля демонстрируют, насколько просто создаются оболочки интерфейсов tkinter, облегчающие их использование, - они полностью скрывают замысловатые особенности реализации панелей переключателей и флажков. Например, при использовании таких классов высокого уровня можно полностью забыть о том, как нужно использовать связанные переменные, - достаточно просто создать объекты со списками вариантов выбора и затем вызывать их методы state. Если пойти этим путем до конца, можно прийти к библиотеке виджетов более высокого уровня, такой как пакет Pmw, упоминавшийся в главе 7.
С другой стороны, эти классы все же не готовы для универсального применения. Например, если потребуется выполнять действия при выборе вариантов, придется использовать другие интерфейсы верхнего уровня. К счастью, Python/tkinter предоставляют великое их множество. Далее в этой книге мы снова будем пользоваться комбинациями виджетов и снова будем применять приемы, представленные в этой главе, для создания более крупных графических интерфейсов. А сейчас последняя остановка в этой первой главе, посвященной экскурсии по виджетам, - фотолаборатория.
Изображения
В библиотеке tkinter графические изображения отображаются за счет создания независимых объектов PhotoImage или BitmapImage и прикрепления их к другим виджетов путем установки атрибута image. Кнопки, метки, холсты, текстовые виджеты и меню - все они могут выводить изображения, связывая таким способом готовые графические объекты. Для иллюстрации сценарий в примере 8.36 выводит картинку на кнопке.
Пример 8.37. PP4E\Gui\Tour\imgButton.py
gifdir = "../gifs/” from tkinter import * win = Tk()
igm = PhotoImage(file=gifdir + “ora-pp.gif”)
Button(win, image=igm).pack() win.mainloop()
Трудно было бы придумать более простой пример: этот сценарий всего лишь создает объект PhotoImage для GIF-файла, хранящегося в другом каталоге, и связывает его с параметром image виджета Button. Результат изображен на рис. 8.37.
Рис. 8.37. Сценарий imgButton в действии
Объект PhotoImage и его собрат BitmapImage просто загружают графические файлы и позволяют прикреплять полученные изображения к другим типам виджетов. Чтобы открыть файл с картинкой, его имя необходимо передать в атрибуте file этих виджетов изображений. Несмотря на всю простоту, прикрепление изображений к кнопкам может найти применение во множестве ситуаций - в главе 9, например, мы будем использовать эту простую идею при реализации кнопок для панелей инструментов в нижней части окна.
Виджеты Canvas - универсальные поверхности для вывода графики, подробнее обсуждаемые в следующей главе, тоже могут выводить картинки. Забегая вперед, в качестве предварительного знакомства отмечу, что холсты (объекты Canvas) достаточно просты в обращении, чтобы привести их в примере. Пример 8.38 выводит окно, изображенное на рис. 8.38.
Рис. 8.38. Изображение на холсте
Пример 8.38. PP4E\Gui\Tour\imgCanvas.py
gifdir = “../gifs/” from tkinter import * win = Tk()
img = PhotoImage(file=gifdir + “ora-lp4e.gif”)
can = Canvas(win)
can.pack(fill=BOTH)
can.create_image(2, 2, image=img, anchor=NW) # координаты x, y win.mainloop()
Размеры кнопок автоматически изменяются в соответствии с размерами изображений, холсты свои размеры не изменяют (потому что в холсты можно добавлять объекты, как будет показано в главе 9). Чтобы размер холста соответствовал размерам изображения, нужно установить его размер, исходя из значений, возвращаемых методами width и height объектов изображений, как в примере 8.39. Эта версия сценария при необходимости делает холст больше или меньше, чем размер, устанавливаемый по умолчанию; позволяет передавать имя графического файла в аргументе командной строки и может использоваться в качестве простой утилиты просмотра изображений. Окно, создаваемое этим сценарием, изображено на рис. 8.39.
Пример 8.39. PP4E\Gui\Tour\imgCanvas2.py
gifdir = “../gifs/” from sys import argv from tkinter import *
filename = argv[1] if len(argv) > 1 else ‘ora-lp4e.gif’ # имя файла
# в командной строке?
Рис. 8.39. Изменение размера холста соответственно картинке
win = Tk()
img = PhotoImage(file=gifdir + filename)
can = Canvas(win)
can.pack(fill=BOTH)
can.config(width=img.width(), height=img.height()) # размер соответственно can.create_image(2, 2, image=img, anchor=NW) # картинке
win.mainloop()
Чтобы просмотреть другое изображение, нужно запустить этот сценарий, передав ему имя другого файла (попробуйте сами, на своем компьютере):
C:\...\PP4E\Gui\Tour> imgCanvas2.py ora-ppr-german.gif
Вот и все. В главе 9 будет показано, как помещать изображения в элементы меню, в кнопки на панели инструментов, приведены другие примеры с объектом Canvas и дружественный к изображениям виджет Text. В последующих главах они встретятся в программе просмотра слайдов (PyView), графическом редакторе (PyDraw) и в других. В графических интерфейсах Python/tkinter очень легко добавлять графику.
Однако начав всерьез использовать графические изображения, вы наверняка наткнетесь на два подводных камня, о которых я хочу предупредить заранее:
Поддерживаемые типы файлов
В настоящее время виджет PhotoImage поддерживает только файлы форматов GIF, PPM и PGM, а BitmapImage поддерживает файлы растровых изображений .xbm в стиле X Window. В последующих версиях количество поддерживаемых форматов может расшириться, и, конечно же, вы можете предварительно преобразовать свои изображения в указанные форматы. Но как будет показано далее в этой главе, поддержку дополнительных форматов изображений легко можно обеспечить с помощью открытого пакета PIL и его класса PhotoImage.
Берегите свои фотографии!
В отличие от других виджетов, tkinter изображение будет безвозвратно утрачено, если соответствующий объект изображения будет утилизирован сборщиком мусора. Это значит, что необходимо сохранять явные ссылки на объекты с графикой в течение всего времени, когда они могут понадобиться программе (например, присвоить их долгоживущей переменной, атрибуту объекта или компоненту структуры данных). Интерпретатор не сохраняет автоматически ссылку на графическое изображение, даже если оно связано с другими компонентами графического интерфейса, отображающими его. Кроме того, методы деструкторов объектов изображений стирают их из памяти. Мы уже видели раньше, что переменные tkinter тоже ведут себя неожиданным образом при уничтожении, но для графики этот эффект еще неприятнее и еще более вероятен. В будущих версиях Python такое поведение может измениться; при этом существуют веские причины не держать в памяти большие графические файлы неопределенно долгое время. На данный же момент элементы с графикой таковы, что если не используются, то могут быть утеряны.
Развлечения с кнопками и картинками
Я хотел представить для этого раздела демонстрационный пример работы с графикой, который был бы одновременно забавным и полезным. Но ограничился забавностью. Сценарий в примере 8.40 отображает кнопку, которая случайным образом меняет свою картинку при каждом нажатии.
Пример 8.40. PP4E\Gui\Tour\bwttonpics-func.py
from tkinter import * # импортировать базовый набор виджетов,
from glob import glob # чтобы получить список файлов по расширению
import demoCheck # прикрепить демонстрационный пример с флажками
import random # выбрать случайную картинку
gifdir = ‘../gifs/’ # каталог по умолчанию с GIF-файлами
def draw():
name, photo = random.choice(images)
lbl.config(text=name)
pix.config(image=photo)
root=Tk()
lbl = Label(root, text=”none”, bg=’blue’, fg=’red’)
pix = Button(root, text=”Press me”, command=draw, bg=’white’) lbl.pack(fill=BOTH)
pix.pack(pady=10)
demoCheck.Demo(root, relief=SUNKEN, bd=2).pack(fill=BOTH)
files = glob(gifdir + “*.gif”) # имеющиеся GIF-файлы
images = [(x, PhotoImage(file=x)) for x in files] # загрузить и сохранить print(files) root.mainloop()
В этом примере используются несколько встроенных инструментов из библиотеки Python:
• Модуль glob, с которым мы впервые встретились в главе 4, позволяет получить список всех файлов с расширением .gif в каталоге - иными словами, всех GIF-файлов, которые там хранятся.
• Модуль random используется для выбора случайного GIF-файла из числа имеющихся в каталоге: функция random.choice случайным образом выбирает и возвращает элемент из списка.
• Чтобы изменить отображаемое изображение (и имя GIF-файла в метке в верхней части окна), сценарий просто вызывает метод config виджета с новыми значениями параметров - такое изменение динамически изменяет вид графического элемента.
Для разнообразия этот сценарий также прикрепляет экземпляр демонстрационной панели флажков demoCheck, который, в свою очередь, прикрепляет экземпляр кнопки Quitter, написанной нами ранее в примере 8.7. Конечно, это искусственный пример, но он еще раз демонстрирует мощь классов компонентов.
Обратите внимание, что все изображения, создаваемые в этом сценарии, сохраняются в списке images. В данном случае генератор списков применяет вызов конструктора PhotoImage к каждому файлу .gif в каталоге с картинками и возвращает список кортежей (filename, image-object), ссылка на который сохраняется в глобальной переменной (то же самое можно реализовать с помощью функции map, использующей lambda-функцию с одним аргументом). Напомню, что это убережет объекты изображений от утилизации сборщиком мусора в течение всего времени выполнения программы. На рис. 8.40 изображено окно этого сценария в Windows.
В этой черно-белой книге можно не заметить, что имя GIF-файла выводится красным по голубому фону метки в верхней части окна. Окно этой программы автоматически расширяется или сжимается, когда выводятся большие или меньшие GIF-файлы. На рис. 8.41 показано изображение, случайно выбранное из каталога графических файлов, имеющее большую высоту.
Рис. 8.40. Сценарий buttonpics в действии
И наконец, на рис. 8.42 изображен графический интерфейс этого сценария, отображающий одну из более широких картинок в GIF-файле, выбранную совершенно случайно из каталога с картинками.42
Рис. 8.42. Сценарий buttonpics обретает политический подтекст
В качестве продолжения наших развлечений перепишем этот сценарий в виде класса на случай, если когда-нибудь в будущем потребуется прикрепить или перекроить его (может произойти и такое, особенно в программах, имеющих практическую ценность). В основном такая переделка состоит в добавлении отступов и префикса self перед именами глобальных переменных, как показано в примере 8.41.
Пример 8.41. PP4E\Gui\Tour\bwttonpics.py
from tkinter import * # импортировать базовый набор виджетов,
from glob import glob # чтобы получить список файлов по расширению import demoCheck # прикрепить демонстрационный пример с флажками
import random # выбрать случайную картинку
gifdir = ‘../gifs/’ # каталог по умолчанию с GIF-файлами
class ButtonPicsDemo(Frame):
def __init__(self, gifdir=gifdir, parent=None):
Frame.__init__(self, parent)
self.pack()
self.lbl = Label(self, text=”none”, bg=’blue’, fg=’red’)
self.pix = Button(self, text=”Press me”, command=self.draw, bg=’white’)
self.lbl.pack(fill=BOTH)
self.pix.pack(pady=10)
demoCheck.Demo(self, relief=SUNKEN, bd=2).pack(fill=BOTH) files = glob(gifdir + “*.gif”)
self.images = [(x, PhotoImage(file=x)) for x in files] print(files)
def draw(self):
name, photo = random.choice(self.images)
self.lbl.config(text=name)
self.pix.config(image=photo)
if __name__ == ‘__main__’: ButtonPicsDemo().mainloop()
Эта версия действует точно так же, как и оригинал, но теперь ее можно прикрепить к любому другому графическому интерфейсу, в который вы пожелаете включить такую дурацкую кнопку.
Отображение и обработка изображений с помощью PIL
Как упоминалось ранее, сценарии на языке Python, использующие библиотеку tkinter, отображают изображения, связывая независимо созданные объекты изображений с действующими виджетами. На момент написания данной книги библиотека tkinter была способна отображать графические файлы в форматах GIF, PPM и PGM с помощью объекта PhotoImage, а также растровые файлы в стиле X11 (обычно с расширением .xbm) с помощью объекта BitmapImage.
Данное множество поддерживаемых форматов файлов ограничено лежащей в основе библиотекой Tk, а не самой библиотекой tkinter, и может быть расширено в будущем. Но если вам нужно сейчас вывести файлы в другом формате (например, в популярном формате JPEG), можно либо преобразовать файлы в один из поддерживаемых форматов с помощью программы обработки изображений, либо установить пакет расширения Python PIL, о котором говорилось в начале главы 7.
Пакет PIL, Python Imaging Library, - система, распространяемая с исходными текстами, поддерживает в данное время около 30 форматов графических файлов (в том числе GIF, JPEG, TIFF, PNG и BMP). В дополнение к расширению диапазона поддерживаемых форматов графических файлов пакет PIL также предоставляет инструменты для обработки изображений, включая геометрические преобразования, создание миниатюр, преобразование из одного формата в другой и многое другое.
Основы PIL
Чтобы воспользоваться инструментами из этого пакета, его сначала необходимо получить и установить: инструкции вы найдете на сайте http://www.pythonware.com (или поищите по строке «PIL», воспользовавшись поисковой системой). Затем нужно просто использовать особые объекты PhotoImage и BitmapImage, импортируемые из модуля ImageTk пакета PIL, чтобы открывать файлы в других графических форматах. Это совместимая замена для одноименных классов из библиотеки tkinter, которую можно использовать везде, где tkinter предполагает использование объекта PhotoImage или BitmapImage (то есть в настройках объектов меток, кнопок, холстов, текстовых виджетов и меню).
Это означает, что стандартный программный код, использующий tkinter, как показано ниже:
from tkinter import *
imgobj = PhotoImage(file=imgdir + “spam.gif”)
Button(image=imgobj).pack()
можно заменить таким программным кодом:
from tkinter import * from PIL import ImageTk
photoimg = ImageTk.PhotoImage(file=imgdir + “spam.jpg”) Button(image=photoimg).pack()
или более многословным эквивалентом, который удобно использовать, когда сценарий не только отображает изображения, но и обрабатывает их:
from tkinter import *
from PIL import Image, ImageTk
imageobj = Image.open(imgdir + “spam.jpeg”)
photoimg = ImageTk.PhotoImage(imageobj)
Button(image=photoimg).pack()
В действительности, чтобы задействовать пакет PIL для отображения изображений, достаточно лишь установить его и добавить в сценарий единственную инструкцию from, импортирующую альтернативный класс PhotoImage после загрузки оригинальной версии из tkinter. Остальной программный код можно оставить без изменений, но он будет способен отображать графические изображения в форматах JPEG, PNG и других:
from tkinter import *
from PIL.ImageTk import PhotoImage # <== добавьте эту строку
imgobj = PhotoImage(file=imgdir + “spam.png”)
Button(image=imgobj).pack()
Особенности установки пакета PIL зависят от платформы. В Windows достаточно лишь загрузить и запустить самоустанавливающийся файл. В результате пакет PIL будет сохранен в каталоге установки Python Lib\site-packages, а поскольку мастер установки автоматически добавит каталог пакета в путь поиска модулей, никаких дополнительных настроек путей не потребуется. Просто запустите мастер установки и затем импортируйте модули из пакета PIL. На других платформах вам может потребоваться распаковать загруженный архив с исходным
программным кодом и добавить путь к каталогу пакета PIL в начало переменной окружения PYTHONPATH - за дополнительной информацией обращайтесь на веб-сайт проекта PIL. (При работе над этим изданием книги я использовал предварительную версию PIL для Python 3.1, но к моменту, когда вы будете читать эти строки, должна быть выпущена официальная версия пакета.)
Рассказ о пакете PIL занял бы значительно больше места, чем может позволить эта книга. Например, он предоставляет инструменты для конвертирования изображений, изменения размеров и преобразования, причем некоторые из них можно использовать как самостоятельные программы командной строки, не имеющие непосредственного отношения к графическим интерфейсам. Пакет PIL наверняка станет стандартным компонентом вашего инструментального набора, особенно для ваших программ, выполняющих отображение или обработку изображений.
Дополнительную информацию вы найдете на сайте http://www.python-ware.com, а также в комплекте электронной документации по PIL и tkinter. Однако, чтобы помочь вам начать, мы закроем эту главу несколькими интересными примерами использования пакета PIL для отображения и обработки изображений.
Отображение других типов графических изображений с помощью PIL
В предыдущих примерах работы с изображениями мы прикрепляли виджеты к кнопкам и холстам, однако стандартный набор инструментов библиотеки tkinter позволяет прикреплять изображения к виджетам различных типов, включая простые метки, текстовые виджеты и элементы меню. Так, сценарий в примере 8.42 отображает изображение в метке, находящейся в главном окне приложения, используя только средства библиотеки tkinter. Этот сценарий предполагает, что изображения хранятся в подкаталоге images, а также позволяет передавать имя файла с изображением в аргументе командной строки (при отсутствии аргументов по умолчанию используется файл spam.gif). Кроме того, для большей переносимости он объединяет имена файлов и каталогов с помощью os.path.join и выводит высоту и ширину изображения в пикселях в стандартный поток вывода, исключительно чтобы предоставить дополнительную информацию.
Пример 8.42. PP4E\Gui\PIL\viewer-tk.py
отображает изображение с помощью стандартного объекта PhotoImage из библиотеки tkinter; данная реализация может работать с GIF-файлами, но не может обрабатывать изображения в формате JPEG; использует файл с изображением, имя которого указано в командной строке, или файл по умолчанию; используйте Canvas вместо Label, чтобы обеспечить возможность прокрутки, и т.д.
import os, sys
from tkinter import * # использовать стандартный объект PhotoImage
# работает с форматом GIF, а для работы с форматом JPEG
# требуется пакет PIL
imgdir = ‘images’ imgfile = ‘london-2010.gif’
if len(sys.argv) > 1: # аргумент командной строки задан?
imgfile = sys.argv[1] imgpath = os.path.join(imgdir, imgfile)
win = Tk()
win.title(imgfile)
imgobj = PhotoImage(file=imgpath)
Label(win, image=imgobj).pack() # прикрепить к метке Label
print(imgobj.width(), imgobj.height()) # вывести размеры в пикселях, win.mainloop() # пока объект не уничтожен
На рис. 8.43 изображено окно этого сценария в Windows 7, где отображается изображение из GIF-файла по умолчанию. Запустите его из консоли, передав имя файла в виде аргумента командной строки, чтобы просмотреть другое изображение из подкаталога images (например, python viewer_tk.py filename.gif).
Рис. 8.43. Отображение картинки в формате GIF средствами tkinter
Сценарий в примере 8.42 может работать только с изображениями, форматы которых поддерживаются базовым набором инструментов в библиотеке tkinter. Для отображения изображений в других форматах, таких как JPEG, необходимо установить пакет PIL и использовать его альтернативную реализацию класса PhotoImage. С точки зрения программного кода, для этого достаточно добавить всего одну инструкцию import, как показано в примере 8.43
Пример 8.43. PP4E\Gui\PIL\viewer-pil.py
отображает изображение с помощью альтернативного объекта из пакета PIL поддерживает множество форматов изображений; предварительно установите пакет PIL: поместите его в каталог Lib\site-packages
import os, sys from tkinter import *
from PIL.ImageTk import PhotoImage # <== использовать альтернативный класс из
# PIL, остальной программный код
# без изменений
imgdir = ‘images’
imgfile = ‘florida-2009-1.jpg’ # поддерживает gif, jpg, png, tiff, и др. if len(sys.argv) > 1: imgfile = sys.argv[1] imgpath = os.path.join(imgdir, imgfile)
win = Tk() win.title(imgfile)
imgobj = PhotoImage(file=imgpath) # теперь поддерживает и JPEG!
Label(win, image=imgobj).pack() win.mainloop()
print(imgobj.width(), imgobj.height()) # показать размер в пикселях при выходе
Задействовав пакет PIL, наш сценарий теперь способен отображать изображения в самых разных форматах, включая формат JPEG картинки по умолчанию, изображенной на рис. 8.44. Поэкспериментируйте со сценарием самостоятельно и попробуйте отобразить другие картинки.
Отображение всех изображений в каталоге
В рамках нашего примера не потребуется приложить много усилий, чтобы обеспечить возможность просмотра всех изображений в каталоге, опираясь на некоторые инструменты для работы с каталогами, с которыми мы познакомились в первой части книги. Сценарий в примере 8.44 просто открывает новое окно Toplevel для каждого файла изображения, обнаруженного в каталоге (указанном в в аргументе командной строки или используемом по умолчанию), пропуская файлы, не являющиеся изображениями, за счет обработки исключения, при этом сообщения об ошибках выводятся в окне, открытом для файла.
Puc. 8.44. Отображение картинки в формате GIF средствами tkinter и PIL
Пример 8.44. PP4E\Gui\PIL\viewer-dir.py
выводит все изображения, найденные в каталоге, открывая новые окна GIF-файлы поддерживаются стандартными средствами tkinter, но JPEG-файлы буду-пропускаться при отсутствии пакета PIL
import os, sys from tkinter import *
from PIL.ImageTk import PhotoImage # <== требуется для JPEG и др. форматов imgdir = ‘images’
if len(sys.argv) > 1: imgdir = sys.argv[1]
imgfiles = os.listdir(imgdir) # не включает полный путь к каталогу
main = Tk() main.title(‘Viewer’)
quit = Button(main, text=’Quit all’, command=main.quit, font=(‘courier’, 25))
quit.pack()
savephotos = []
for imgfile in imgfiles:
imgpath = os.path.join(imgdir, imgfile)
win = Toplevel()
win.title(imgfile)
try:
imgobj = PhotoImage(file=imgpath)
Label(win, image=imgobj).pack()
print(imgpath, imgobj.width(), imgobj.height()) # размер в пикселях savephotos.append(imgobj) # сохранить ссылку
except:
errmsg = ‘skipping %s\n%s’ % (imgfile, sys.exc_info()[1])
Label(win, text=errmsg).pack()
main.mainloop()
Запустите этот сценарий у себя, чтобы посмотреть создаваемые им окна. При запуске он создает одно главное окно с кнопкой Quit, щелчок на которой закрывает все дополнительные окна, количество которых совпадает с количеством файлов изображений в каталоге. Этот сценарий удобно использовать для быстрой организации просмотра, но он определенно не является образцом дружественного отношения к пользователю, особенно если в каталоге содержится огромное количество изображений! Каталог images, находящийся в дереве примеров и использовавшийся при тестировании, содержит 59 изображений. В результате при просмотре этого каталога сценарий порождает 60 окон, а каталоги, где вы храните свои снимки, сделанные цифровой фотокамерой, могут содержать гораздо больше изображений. Чтобы улучшить сценарий, перейдем к следующему разделу.
Создание миниатюр изображений с помощью пакета PlL
Как уже упоминалось, пакет PIL позволяет не только отображать картинки в графическом интерфейсе, но и выполнять массу других операций над ними. В его составе имеются инструменты для изменения размеров изображений, преобразования из одного формата в другой и так далее. Один из таких инструментов предоставляет возможность генерировать «миниатюры» изображений из оригиналов. Такие миниатюры могут отображаться в веб-страницах или в инструментах выбора графического интерфейса, дающих пользователю возможность открывать полноразмерные изображения.
В примере 8.45 приводится конкретная реализация этой идеи - он генерирует миниатюры изображений, используя PIL, и отображает их на кнопках, которые открывают соответствующие оригинальные картинки в случае щелчка мышью. В результате получается графический интерфейс, очень напоминающий интерфейс проводников по файловой системе, ставший стандартом в современных операционных системах.
Но данный интерфейс реализован на языке Python, что дает нам полный контроль над его поведением и возможность повторного использования в наших приложениях. Фактически мы повторно будем использовать функцию makeThumbs, уже реализованную в других примерах. Как обычно, этот пример демонстрирует некоторые основные преимущества, характерные для открытого программного обеспечения.
Пример 8.45. PP4E\Gui\PIL\viewer_thumbs.py
выводит все изображения, имеющиеся в каталоге, в виде миниатюр на кнопках, щелчок на которых приводит к выводу полноразмерного изображения; требует наличия пакета PIL для отображения JPEG-файлов и создания миниатюр; что сделать: добавить прокрутку, если в окне выводится слишком много миниатюр!
import os, sys, math from tkinter import *
from PIL import Image # <== required for thumbs
from PIL.ImageTk import PhotoImage # <== required for JPEG display
def makeThumbs(imgdir, size=(100, 100), subdir=’thumbs’):
создает миниатюры для всех изображений в каталоге; для каждого изображения создается и сохраняется новая миниатюра или загружается существующая; при необходимости создает каталог thumb;
возвращает список кортежей (имя_файла_изображения, объект_миниатюры); для получения списка файлов миниатюр вызывающая программа может также воспользоваться функцией listdir в каталоге thumb; для неподдерживаемых типов файлов может возбуждать исключение IOError, или другое;
ВНИМАНИЕ: можно было бы проверять время создания файлов;
thumbdir = os.path.join(imgdir, subdir) if not os.path.exists(thumbdir): os.mkdir(thumbdir)
thumbs = []
for imgfile in os.listdir(imgdir):
thumbpath = os.path.join(thumbdir, imgfile) if os.path.exists(thumbpath):
thumbobj = Image.open(thumbpath) # использовать существующую
thumbs.append((imgfile, thumbobj)) else:
print(‘making’, thumbpath)
imgpath = os.path.join(imgdir, imgfile)
try:
imgobj = Image.open(imgpath) # создать новую миниатюру imgobj.thumbnail(size, Image.ANTIALIAS) # фильтр, дающий
# лучшее качество при
# уменьшении размеров
imgobj.save(thumbpath) # тип определяется расширением
thumbs.append((imgfile, imgobj)) except: # не всегда IOError
print(“Skipping: “, imgpath) return thumbs
class ViewOne(Toplevel):
открывает одно изображение в новом окне; ссылку на объект PhotoImage требуется сохранить: изображение будет утрачено при утилизации объекта;
def __init__(self, imgdir, imgfile):
Toplevel.__init__(self)
self.title(imgfile)
imgpath = os.path.join(imgdir, imgfile) imgobj = PhotoImage(file=imgpath)
Label(self, image=imgobj).pack()
print(imgpath, imgobj.width(), imgobj.height()) # размер в пикселях self.savephoto = imgobj # сохранить ссылку
# на изображение
def viewer(imgdir, kind=Toplevel, cols=None):
создает окно с миниатюрами для каталога с изображениями: по одной кнопке с миниатюрой для каждого изображения;
используйте параметр kind=Tk, чтобы вывести миниатюры в главном окне, или Frame (чтобы прикрепить к фрейму); значение imgfile изменяется в каждой итерации цикла: ссылка на значение должна сохраняться по умолчанию; объекты PhotoImage должны сохраняться: иначе при утилизации изображения будут уничтожены;
компонует в ряды фреймов (в противоположность сеткам, фиксированным размерам, холстам);
win = kind()
win.title(‘Viewer: ‘ + imgdir)
quit = Button(win, text=’Quit’, command=win.quit, bg=’beige’) # добавить quit.pack(fill=X, side=BOTTOM) # первой, чтобы урезалась последней
thumbs = makeThumbs(imgdir) if not cols:
cols = int(math.ceil(math.sqrt(len(thumbs)))) # фиксированное или N x N
savephotos = [] while thumbs:
thumbsrow, thumbs = thumbs[:cols], thumbs[cols:] row = Frame(win) row.pack(fill=BOTH) for (imgfile, imgobj) in thumbsrow: photo = PhotoImage(imgobj) link = Button(row, image=photo)
handler = lambda savefile=imgfile: ViewOne(imgdir, savefile)
link.config(command=handler)
link.pack(side=LEFT, expand=YES)
savephotos.append(photo) return win, savephotos
if __name__ == ‘__main__’:
imgdir = (len(sys.argv) > 1 and sys.argv[1]) or ‘images’
main, save = viewer(imgdir, kind=Tk)
main.mainloop()
Просьба обратить внимание, что функция viewer передает значение imgfile lambda-выражению, генерирующему обработчик, в виде значения по умолчанию аргумента. Это объясняется тем, что imgfile является переменной цикла, и если не сохранять текущее ее значение, все обработчики получат значение переменной, установленное в последней итерации (все кнопки будут открывать одно и то же изображение!). Отметьте также, что мы сохраняем ссылки на объекты изображений в списке - если этого не сделать, изображения будут уничтожены при утилизации их объектов сборщиком мусора, даже если в этот момент они будут отображаться на экране. Чтобы избежать такой неприятности, мы сохраняем ссылки на объекты в долгоживущем списке.
На рис. 8.45 изображено главное окно с миниатюрами, доступными для выбора, созданное сценарием из примера 8.45 при попытке просмотра содержимого каталога по умолчанию images, находящегося в дереве примеров (размер окна был изменен при подготовке снимка с экрана для книги). Как и прежде, вы можете передать сценарию имя другого каталога, чтобы просмотреть его содержимое (например, имя каталога, где вы храните свои цифровые фотографии). Щелчок на кнопке с миниатюрой в главном окне открывает соответствующее изображение в новом окне, как показано на рис. 8.46.
На данный момент большая часть примера 8.45 должна быть вам понятна. В нем кнопки с миниатюрами прикрепляются к рядам фреймов, как и в предыдущих примерах (смотрите альтернативные варианты компоновки форм ввода, реализованные выше в этой главе). Основная часть программного кода, использующего пакет PIL, находится в функции makeThumbs. Он открывает, создает и сохраняет изображения миниатюр, если ранее они не были сохранены (то есть не были кэшированы) в локальных файлах. В данной реализации миниатюры сохраняются в том же формате, что и оригинальные, полноразмерные изображения.
Мы также использовали фильтр PIL ANTIALIAS, дающий наилучшее качество при уменьшении размеров изображения, что особенно заметно для изображений в формате GIF с низким разрешением. Создание миниатюры сводится, по сути, к изменению размеров с сохранением оригинальных пропорций. Из-за невозможности охватить все особенности здесь за дополнительными подробностями, касающимися API, я отсылаю вас к пакету PIL и документации по нему.
В следующей главе мы еще раз коротко вернемся к проблеме создания миниатюр, когда будем создавать кнопки для панели инструментов.
Рис. 8.45. Простой графический интерфейс выбора миниатюр, простые ряды фреймов
Рис. 8.46. Окно с полноразмерным изображением
Однако, прежде чем двинуться дальше, быстро познакомимся с тремя вариантами реализации отображения миниатюр - в первом из них делается акцент на оценке производительности, а в других двух будет улучшена, вероятно, не самая удачная компоновка миниатюр, изображенная на рис. 8.45.
Производительность: сохранение миниатюр в файлах
В текущей реализации сценарий сохраняет созданные миниатюры в файлах, благодаря чему при следующем запуске они могут быть загружены значительно быстрее. Строго говоря, делать это совсем не обязательно - в примере 8.46 реализована измененная версия функции создания миниатюр, которая также генерирует изображения миниатюр в памяти, но не сохраняет их.
Для небольших коллекций изображений разница в скорости выполнения будет незаметна. Однако если испытать эти альтернативы на больших коллекциях изображений, можно будет заметить, что оригинальная версия в примере 8.45, сохраняющая и загружающая миниатюры из файлов, дает значительное преимущество в скорости. В одном из тестов с большой коллекцией файлов изображений на моем компьютере (примерно 320 цифровых фотографий на весьма, по общему мнению, медлительном ноутбуке) оригинальному сценарию потребовалось всего 5 секунд, чтобы открыть графический интерфейс (после первого запуска, в ходе которого было выполнено кэширование миниатюр), тогда как версии, представленной в примере 8.46, потребовалась 1 минута и 20 секунд: в 16 раз больше. Загрузка миниатюр из файлов выполняется значительно быстрее, чем операция изменения размеров.
Пример 8.46. PP4E\Gui\PIL\viewer-thumbs-nosave.py
то же самое, но не сохраняет и не загружает миниатюры из файлов: для маленьких коллекций изображений, кажется, работает также быстро, но для больших коллекций, при сохранении миниатюр в файлах, запуск происходит намного быстрее; в некоторых приложениях (например, в веб-страницах) сохранение может оказаться насущной необходимостью
import os, sys from PIL import Image from tkinter import Tk import viewer_thumbs
def makeThumbs(imgdir, size=(100, 100), subdir=’thumbs’): создает миниатюры в памяти, но не сохраняет их в файлах thumbs = []
for imgfile in os.listdir(imgdir):
imgpath = os.path.join(imgdir, imgfile) try:
imgobj = Image.open(imgpath) # создать новую миниатюру
imgobj.thumbnail(size) thumbs.append((imgfile, imgobj)) except:
print(“Skipping: “, imgpath) return thumbs
if __name__ == ‘__main__’:
imgdir = (len(sys.argv) > 1 and sys.argv[1]) or ‘images’
viewer_thumbs.makeThumbs = makeThumbs
main, save = viewer_thumbs.viewer(imgdir, kind=Tk)
main.mainloop()
Варианты компоновки: по сетке
Следующая версия нашего сценария содержит изменения, носящие исключительно косметический характер, но она демонстрирует некоторые важные понятия компоновки tkinter. Если посмотреть на рис. 8.45 достаточно пристально, можно заметить, что миниатюры располагаются недостаточно однородно. Если расположение отдельных строк еще как-то согласуется благодаря использованию рядов фреймов, то стройность колонок может нарушаться из-за разных размеров изображений. Применение различных параметров компоновки, похоже, не способно исправить этот недостаток (и может даже ухудшить положение дел - попробуйте сами), а компоновка по фреймам-колонкам просто переместит проблему в другую размерность. При работе с крупными коллекциями это может осложнить поиск какого-то определенного изображения.
Приложив совсем немного усилий, мы можем добиться более стройного размещения миниатюр, либо разместив их по сетке, либо использовав кнопки фиксированного размера. Сценарий в примере 8.47 располагает кнопки по сетке, используя менеджер компоновки grid - более подробно мы будем рассматривать его в следующей главе. Как и представление холстов выше, некоторые фрагменты этого примера следует рассматривать, как предварительное знакомство. В двух словах, функция grid располагает содержимое по рядам и колонкам - все приемы, обеспечивающие неподвижность кнопки Quit, будут рассматриваться в главе 9.
Пример 8.47. PP4E\Gui\PIL\viewer-thumbs-grid.py
то же, что и viewer_thumbs, но использует менеджер компоновки grid, чтобы добиться более стройного размещения миниатюр; того же эффекта можно добиться с применением фреймов и менеджера pack, если кнопки будут иметь фиксированный и одинаковый размер;
import sys, math
from tkinter import *
from PIL.ImageTk import PhotoImage
from viewer_thumbs import makeThumbs, ViewOne def viewer(imgdir, kind=Toplevel, cols=None):
измененная версия, размещает миниатюры по сетке win = kind()
win.title(‘Viewer: ‘ + imgdir) thumbs = makeThumbs(imgdir) if not cols:
cols = int(math.ceil(math.sqrt(len(thumbs))))# фиксированное или N x N
rownum = 0 savephotos = [] while thumbs:
thumbsrow, thumbs = thumbs[:cols], thumbs[cols:] colnum = 0
for (imgfile, imgobj) in thumbsrow: photo = PhotoImage(imgobj) link = Button(win, image=photo)
handler = lambda savefile=imgfile: ViewOne(imgdir, savefile) link.config(command=handler) link.grid(row=rownum, column=colnum) savephotos.append(photo) colnum += 1 rownum += 1
Button(win, text=’Quit’, command=win.quit).grid(columnspan=cols, stick=EW) return win, savephotos
if __name__ == ‘__main__’:
imgdir = (len(sys.argv) > 1 and sys.argv[1]) or ‘images’
main, save = viewer(imgdir, kind=Tk)
main.mainloop()
Эффект размещения по сетке изображен на рис. 8.47 - наши кнопки образовали более стройные ряды и колонки, чем на рис. 8.45, потому что они позиционируются не только по рядам, но и по колонкам. Как мы увидим в следующей главе, размещение по сетке можно использовать всякий раз, когда схема размещения элементов интерфейса носит двухмерный характер.
Варианты компоновки: кнопки фиксированного размера
Компоновка по сетке улучшает картину, - картинки располагаются ровными рядами и колонками - но сама форма картинок оставляет желать лучшего. Мы могли бы добиться еще более стройного размещения, использовав кнопки фиксированного размера. По умолчанию размеры кнопок автоматически подстраиваются под размер изображения (или текста), но мы всегда можем зафиксировать размер кнопок. Эта уловка используется в примере 8.48. Данный сценарий устанавливает высоту и ширину каждой кнопки в соответствии с максимальным размером миниатюр, чтобы ни одна кнопка не оказалась ни слишком узкой, ни слишком низкой. Если для всех миниатюр будет установлен один и тот же максимальный размер (что гарантируется нашей функцией создания миниатюр), это обеспечит желаемое размещение кнопок.
Рис. 8.47. Графический интерфейс выбора миниатюр с размещением по сетке
Пример 8.48. PP4E\Gui\PIL\viewer-thumbs-fixed.py
использует кнопки фиксированного размера для миниатюр, благодаря чему достигается еще более стройное размещение; размеры определяются по объектам изображений, при этом предполагается, что для всех миниатюр был установлен один и тот же максимальный размер; по сути именно это и делают графические интерфейсы файловых менеджеров;
import sys, math
from tkinter import *
from PIL.ImageTk import PhotoImage
from viewer_thumbs import makeThumbs, ViewOne
def viewer(imgdir, kind=Toplevel, cols=None):
измененная версия, выполняет размещение с использованием кнопок фиксированного размера
win = kind()
win.title(‘Viewer: ‘ + imgdir) thumbs = makeThumbs(imgdir) if not cols:
cols = int(math.ceil(math.sqrt(len(thumbs))))# фиксированное или N x N
savephotos = [] while thumbs:
thumbsrow, thumbs = thumbs[:cols], thumbs[cols:]
row = Frame(win)
row.pack(fill=BOTH)
for (imgfile, imgobj) in thumbsrow:
size = max(imgobj.size) # ширина, высота
photo = PhotoImage(imgobj) link = Button(row, image=photo)
handler = lambda savefile=imgfile: ViewOne(imgdir, savefile) link.config(command=handler, width=size, height=size) link.pack(side=LEFT, expand=YES) savephotos.append(photo)
Button(win, text=’Quit’, command=win.quit, bg=’beige’).pack(fill=X) return win, savephotos
if __name__ == ‘__main__’:
imgdir = (len(sys.argv) > 1 and sys.argv[1]) or ‘images’
main, save = viewer(imgdir, kind=Tk)
main.mainloop()
Результат применения кнопок фиксированного размера изображен на рис. 8.48 - теперь все кнопки имеют одинаковые размеры, вычисленные на основании размеров имеющихся изображений. Все миниатюры отображаются как одинаковые элементы мозаики независимо от их формы, что упрощает и просмотр. Естественно, возможны и другие схемы размещения - поэкспериментируйте с некоторыми параметрами настройки в этом сценарии, чтобы посмотреть их воздействие на графический интерфейс.
Прокрутка и холсты (забегая вперед)
Сценарий отображения миниатюр, представленный в этом разделе, неплохо справляется со своей задачей при умеренном количестве изображений в каталогах; для просмотра крупных коллекций изображений можно также задать настройки с уменьшенными размерами миниатюр. Но, вероятно, самое большое ограничение этих программ состоит в том, что для каталогов с очень большим количеством изображений окна бу-
Рис. 8.48. Графический интерфейс выбора миниатюр с кнопками фиксированного размера и рядами фреймов
дут получаться слишком большими и неудобными в работе (при этом часть миниатюр вообще может не поместиться в окне).
Даже при просмотре каталога с изображениями из дерева примеров для этой книги мы потеряли кнопку Quit в нижней части окна, как показано на двух последних рисунках, потому что миниатюр оказалось слишком много, чтобы уместить их в этом окне. В качестве иллюстрации различий посмотрите оригинальную версию в примере 8.45: там кнопка Quit добавляется первой именно поэтому - чтобы ее урезание происходило в последнюю очередь, после всех миниатюр, и поэтому она остается видимой даже при слишком большом количестве картинок. Мы могли бы применить тот же прием и в других версиях, но при большом количестве миниатюр они все равно не поместились бы все в окно. При просмотре каталогов с огромным количеством цифровых фотографий может получиться окно, слишком большое, чтобы поместиться на экране компьютера.
Чтобы добиться большего успеха, можно было бы поместить миниатюры на виджет, поддерживающий возможность прокрутки. Свободно распространяемый пакет Pmw предоставляет удобный фрейм с прокруткой, который можно было бы использовать. Кроме того, в библиотеке tkinter имеется стандартный виджет Canvas, обеспечивающий возможность более точного управления параметрами отображения картинок (включая их размещение по абсолютным координатам в пикселях) и поддерживающий горизонтальную и вертикальную прокрутку своего содержимого.
В следующей главе мы напишем последнюю версию этого примера, которая реализует все эти идеи, - она отображает миниатюры в холсте с прокруткой и потому лучше подходит для работы с большими коллекциями изображений. В ней используются кнопки фиксированного размера, как и в последнем примере здесь, но позиционирование их выполняется по вычисленным координатам. Я не буду обсуждать здесь дальнейшие детали, потому что новую версию мы будем рассматривать в соединении с холстами в следующей главе. А в главе 11 мы используем этот прием в еще более полноценной программе для работы с изображениями, которая называется PyPhoto.
Чтобы узнать, как действуют эти программы, необходимо перейти к следующей главе - второй части нашего тура по виджетам.
Рис. 8.41. Сценарий buttonpics, отображающий более высокую картинку
Экскурсия по tkinter, часть 2
«Меню дня: Spam, Spam и еще раз Spam»
Это вторая глава обзора библиотеки tkinter, состоящего из двух частей. Она продолжает движение с того места, на котором остановилась глава 8, и рассказывает о некоторых более сложных виджетах и инструментах из арсенала tkinter. В этой главе представлены следующие темы:
• Виджеты Menu, Menubutton и OptionMenu
• Виджет Scrollbar: для прокрутки текста, списков и холстов
• Виджет Listbox: список с возможностью выбора нескольких вариантов
• Виджет Text: универсальный инструмент отображения и редактирования текста
• Виджет Canvas: универсальный инструмент вывода графики
• Менеджер компоновки grid, принцип действия которого основан на использовании таблиц
• Инструменты измерения интервалов времени: after, update, wait и потоки выполнения
• Основы анимации в tkinter
• Буферы обмена, удаление виджетов и окон и так далее.
К концу этой главы вы будете знакомы с основным содержанием библиотеки tkinter и овладеете всей информацией, необходимой для самостоятельного построения больших переносимых интерфейсов пользователя. Также вы будете готовы справиться с объемными примерами, представленными в главах 10 и 11. А сейчас продолжим обзор виджетов.
Меню
Меню представляют собой раскрывающиеся списки, которые обычно можно увидеть в верхней части окна (или всего экрана, если вы работаете на Macintosh). Переместите указатель мыши на панель меню, щелкните на имени (например, Файл (FiLe)), и под этим именем появится список вариантов выбора (например, Открыть (Open), Сохранить (Save)). Пункты меню могут запускать какие-либо действия, как щелчок на кнопке. Они могут также открывать другие «каскадные» подменю, выводящие дополнительные списки вариантов, показывать окна диалогов и так далее. В библиотеке tkinter есть два типа меню, которые можно добавлять в сценарии: меню окон верхнего уровня и меню, основанные на фреймах. Первый вид лучше подходит для окон в целом, а второй может использоваться в качестве вложенных компонентов.
Меню окон верхнего уровня
Во всех последних версиях Python (где используется библиотека Tk версии 8.0 и выше) можно связывать горизонтальную панель меню с объектом окна верхнего уровня (например, Tk или Toplevel). В Windows и Unix (X Window ) эта строка меню выводится вдоль верхнего края окна. В некоторых версиях Mac OS это меню при выборе окна заменяет то, что отображается в верхней части экрана. Иными словами, меню окон выглядят так, как принято на той платформе, на которой выполняется сценарий.
В основе этой схемы лежит построение деревьев, состоящих из объектов виджетов Menu. Нужно просто связать с окном один элемент Menu верхнего уровня, добавить другие объекты раскрывающихся меню в качестве каскадов для меню верхнего уровня и добавить элементы в каждый из раскрывающихся списков. Виджеты Menu перекрестно связываются со следующим, более высоким уровнем, с помощью аргумента родительского виджета и метода add_cascade виджета Menu. Делается это так:
1. Создать меню Menu верхнего уровня как дочерний элемент окна и записать ссылку на новый виджет Menu в атрибут menu.
2. Для каждого раскрывающегося меню создать новый объект Menu как дочерний для самого верхнего меню и добавить его как каскадный для самого верхнего меню с помощью метода add_cascade.
3. В каждое раскрывающееся меню, созданное на шаге 2, добавить элементы выбора вызовом метода add_comand, которому в аргументе command передать обработчик события выбора этого элемента.
4. Добавить каскадные подменю, создавая новые виджеты Menu как дочерние для того объекта Menu, который должен расширяться каскад-но, и связывая родительский и дочерний объекты с помощью метода
add_cascade.
В конечном итоге получится дерево виджетов Menu с ассоциированными обработчиками событий. Однако все это, вероятно, проще показать в программном коде, чем на словах. В примере 9.1 создается главное меню с двумя раскрывающимися меню, File и Edit; в раскрывающемся меню Edit имеется собственное вложенное подменю.
Пример 9.1. PP4E\Gui\Tour\menu_win.py
# меню окна верхнего уровня в стиле Tk8.0
from tkinter import * # импортировать базовый набор виджетов
from tkinter.messagebox import * # импортировать стандартные диалоги
def notdone():
showerror(‘Not implemented’, ‘Not yet available’) def makemenu(win):
top = Menu(win) # win = окно верхнего уровня
win.config(menu=top) # установить его параметр menu
file = Menu(top)
file.add_command(label=’New...’, command=notdone, underline=0) file.add_command(label=’Open...’, command=notdone, underline=0) file.add_command(label=’Quit’, command=win.quit, underline=0) top.add_cascade(label=’File’, menu=file, underline=0)
edit = Menu(top, tearoff=False)
edit.add_command(label=’Cut’, command=notdone, underline=0) edit.add_command(label=’Paste’, command=notdone, underline=0) edit.add_separator()
top.add_cascade(label=’Edit’, menu=edit, underline=0) submenu = Menu(edit, tearoff=True)
submenu.add_command(label=’Spam’, command=win.quit, underline=0) submenu.add_command(label=’Eggs’, command=notdone, underline=0) edit.add_cascade(label=’Stuff’, menu=submenu, underline=0)
if__name__== ‘__main__’:
root = Tk() # или Toplevel()
root.title(‘menu_win’) # информация для менеджера окон
makemenu(root) # создать строку меню
msg = Label(root, text=’Window menu basics’) # добавить что-нибудь ниже msg.pack(expand=YES, fill=BOTH)
msg.config(relief=SUNKEN, width=40, height=7, bg=’beige’) root.mainloop()
Значительная часть программного кода в этом примере выполняет установку обработчиков событий и тому подобного, поэтому полезно будет выделить фрагменты, участвующие в процессе построения дерева меню. Для меню FiLe:
top = Menu(win) # прикрепить Menu к окну
win.config(menu=top) # связать окно и меню
file = Menu(top) # прикрепить Menu к Menu верх. ур.
top.add_cascade(label=’File’, menu=file) # связать родителя с потомком
Помимо построения дерева объектов меню этот сценарий демонстрирует некоторые часто встречающиеся параметры конфигурации меню:
Линии-разделители
С помощью метода add_separator сценарий создает в меню Edit разделитель - это просто линия, используемая для разделения групп родственных пунктов.
Линии отрыва
Сценарий запрещает отрыв раскрывающегося меню Edit, передавая параметр tearoff=0 при создании виджета Menu. Линии отрыва - это пунктирные линии, по умолчанию появляющиеся в меню tkinter верхнего уровня. Щелчок на этой линии создает новое окно, содержащее меню. Они могут служить удобным средством упрощения навигации (можно сразу щелкнуть на пункте отрывного меню, не блуждая по дереву вложенных пунктов), но не на всех платформах принято их использовать.
Горячие клавиши
Сценарий использует параметр underline, чтобы назначить уникальную букву в пункте меню горячей клавишей. Параметр задает смещение буквы в строке метки пункта меню. Например, в Windows пункт Quit в меню FiLe этого сценария можно выбрать, как обычно, с помощью мыши, а также нажатием клавиши Alt, затем f и затем q. Использовать параметр underline не обязательно - в Windows первая буква имени раскрывающегося меню автоматически становится горячей клавишей, а кроме того, для перемещения по меню и выбора раскрывающихся пунктов можно использовать клавиши со стрелками и Enter. Но явное определение горячих клавиш может облегчить использование больших меню. Например, последовательность клавиш Alt+E+S+S выполняет действие по завершению программы, предусмотренное пунктом Spam во вложенном подменю Stuff, без каких-либо перемещений с помощью мыши или клавиш со стрелками.
Посмотрим, во что все это превращается в переводе на пиксели. На рис. 9.1 изображено окно, появляющееся при запуске этого сценария в Windows 7 с моими настройками системы. Оно несколько иначе, но похоже отображается в Unix и Macintosh.
На рис. 9.2 изображено, что происходит при выборе раскрывающегося меню File. Обратите внимание, что виджеты Menu связываются, а не присоединяются с помощью менеджера компоновки - в действительности менеджер компоновки здесь вообще не участвует. Если запустить этот
Рис. 9.1. Сценарий menu_win: строка меню окна верхнего уровня
Рис. 9.2. Открытое меню File
сценарий, можно также заметить, что все элементы меню либо завершают выполнение программы, либо выводят стандартный диалог ошибки «Not Implemented» (Не реализовано). Этот пример просто демонстрирует работу с меню, но на практике обработчики событий выбора пунктов меню обычно выполняют более полезные вещи.
И наконец, на рис. 9.3 изображено, что происходит после щелчка по линии отрыва в меню FiLe и выбора каскадного подменю в раскрывающемся меню Edit. Каскадные меню можно вкладывать друг в друга на любую глубину (но злоупотребление этой возможностью может запутать пользователей).
В библиотеке tkinter любое окно верхнего уровня может иметь собственное меню, в том числе и всплывающие окна, создаваемые виджетом Toplevel. Сценарий в примере 9.2 создает три всплывающих окна с такой же панелью меню, как в предыдущем примере. Если запустить его, он создаст картину, изображенную на рис. 9.4.
Рис. 9.3. Отрывное меню File и каскадное Edit
Рис. 9.4. Несколько окон верхнего уровня с меню
Пример 9.2. PP4E\Gui\Towr\menu_win-multi.py
from menu_win import makemenu # повторно использовать функцию создания меню from tkinter import *
root = Tk()
for i in range(3): # три всплывающих окна с меню
win = Toplevel(root) makemenu(win)
Label(win, bg=’black’, height=5, width=25).pack(expand=YES, fill=BOTH) Button(root, text=”Bye”, command=root.quit).pack() root.mainloop()
Меню на основе виджетов Frame и Menubutton
Хотя это не совсем обычно для окон верхнего уровня, но допустимо создание строки меню в виде горизонтального фрейма Frame. Однако прежде чем показывать, как это делается, я хочу объяснить, зачем это может понадобиться. Поскольку такая схема, основанная на фреймах, не зависит от протоколов окон верхнего уровня, она может применяться для добавления меню в качестве вложенных компонентов более крупных интерфейсов. Иными словами, она в основном применяется не к окнам верхнего уровня. Например, текстовый редактор PyEdit из главы 11 может использоваться как программа и как прикрепляемый компонент. Мы реализуем выбор в PyEdit с помощью оконных меню при выполнении его как самостоятельной программы и с помощью меню, основанного на фрейме, когда PyEdit будет встраиваться в интерфейсы PyMailGUI и PyView. Поэтому стоит знать обе схемы.
Для меню на основе фреймов требуется написать несколько дополнительных строчек программного кода, но они ненамного сложнее оконных меню. Для создания такого меню нужно разместить виджеты Me-nubutton в контейнере Frame, связать виджеты Menu и Menubutton и присоединить Frame к верхней части окна-контейнера. В примере 9.3 создается такое же меню, как в примере 9.2, но с использованием фрейма.
Пример 9.3. PP4E\Gui\Tour\menu_frm.py
# Меню на основе фреймов: пригодно для окон верхнего уровня и компонентов
from tkinter import * # импортировать базовый набор виджетов
from tkinter.messagebox import * # импортировать стандартные диалоги
def notdone():
showerror(‘Not implemented’, ‘Not yet available’) def makemenu(parent):
menubar = Frame(parent) # relief=RAISED, bd=2...
menubar.pack(side=TOP, fill=X)
fbutton = Menubutton(menubar, text=’File’, underline=0)
fbutton.pack(side=LEFT)
file = Menu(fbutton)
file.add_command(label=’New...’, command=notdone, underline=0) file.add_command(label=’Open...’, command=notdone, underline=0) file.add_command(label=’Quit’, command=parent.quit, underline=0) fbutton.config(menu=file)
ebutton = Menubutton(menubar, text=’Edit’, underline=0)
ebutton.pack(side=LEFT)
edit = Menu(ebutton, tearoff=False)
edit.add_command(label=’Cut’, command=notdone, underline=0)
edit.add_command(label=’Paste’, command=notdone, underline=0)
edit.add_separator()
ebutton.config(menu=edit)
submenu = Menu(edit, tearoff=True)
submenu.add_command(label=’Spam’, command=parent.quit, underline=0) submenu.add_command(label=’Eggs’, command=notdone, underline=0) edit.add_cascade(label=’Stuff’, menu=submenu, underline=0) return menubar
if __name__ == ‘__main__’:
root = Tk() # или TopLevel, или Frame
root.title(‘menu_frm’) # информация для менеджера окон
makemenu(root) # создать строку меню
msg = Label(root, text=’Frame menu basics’) # добавить что-нибудь ниже msg.pack(expand=YES, fill=BOTH)
msg.config(relief=SUNKEN, width=40, height=7, bg=’beige’) root.mainloop()
Снова выделим здесь логику связывания, чтобы не отвлекали другие детали. Для меню FiLe она сводится к следующему:
menubar = Frame(parent) # создать Frame для строки меню
fbutton = Menubutton(menubar, text=’File’) # прикрепить Menubutton к Frame file = Menu(fbutton) # прикрепить Menu к Menubutton
fbutton.config(menu=file) # связать кнопку и меню
В этой схеме появился дополнительный виджет Menubutton, но это не сделало ее намного сложнее создания оконных меню верхнего уровня. На рис. 9.5 и 9.6 изображено, как этот сценарий выполняется в Windows.
Рис. 9.5. Сценарий menu_frm: фрейм и полоса меню Menubutton
Виджеты меню в этом сценарии по умолчанию предоставляют набор связанных событий, автоматически отображающих меню при выборе мышью. Такие внешний вид и поведение не вполне совпадают с продемонстрированной выше схемой оконного меню верхнего уровня, хотя
Рис. 9.6. С выбранным меню Edit
и близки к ней; виджеты могут настраиваться теми способами, которые допускают фреймы (то есть с помощью цветов и границ), и будут иметь одинаковый внешний вид на всех платформах (что, возможно, является недостатком).
Однако самым большим преимуществом строк меню на основе фреймов является возможность прикрепления в качестве вложенных компонентов к более крупным интерфейсам. Пример 9.4 и создаваемый им интерфейс (рис. 9.7) показывают, каким образом это делается, - обе полосы меню в одном окне полностью функциональны.
Рис. 9.7. Несколько меню на основе фреймов в одном окне
Пример 9.4. PP4E\Gui\Tour\menu_frm-multi.py
from menu_frm import makemenu # здесь нельзя использовать menu_win--одно окно from tkinter import * # но можно прикреплять меню на основе фреймов
root = Tk()
for i in range(2): # 2 меню в одном окне
mnu = makemenu(root) mnu.config(bd=2, relief=RAISED)
Label(root, bg=’black’, height=5, width=25).pack(expand=YES, fill=BOTH) Button(root, text=”Bye”, command=root.quit).pack() root.mainloop()
Благодаря отсутствию привязки к охватывающему окну меню на основе фреймов можно использовать в составе другого прикрепляемого компонента. Например, прием встраивания меню, представленный в примере 9.5, действует, даже когда родителем меню является другой контейнер Frame, а не окно верхнего уровня. Этот сценарий похож на предыдущий, но он создает три полнофункциональных строки меню, прикрепленных к фреймам внутри окна.
Пример 9.5. PP4E\Gui\Tour\menu_frm-multi2.py
from menu_frm import makemenu # нельзя использовать menu_win--корень=Frame from tkinter import * root = Tk()
for i in range(3): # три меню, вложенные в контейнеры
frm = Frame()
mnu = makemenu(frm)
mnu.config(bd=2, relief=RAISED)
frm.pack(expand=YES, fill=BOTH)
Label(frm, bg=’black’, height=5, width=25).pack(expand=YES, fill=BOTH)
Button(root, text=”Bye”, command=root.quit).pack()
root.mainloop()
Использование виджетов Menubutton и Optionmenu
В действительности меню, основанные на Menubutton, являются еще более универсальными, чем следует из примера 9.3, - они могут появляться в любом месте интерфейса, где может располагаться обычная кнопка, а не только в строке меню во фрейме Frame. В примере 9.6 создается раскрывающийся список Menubutton, который отображается самостоятельно и прикреплен к корневому окну. На рис. 9.8 приведен графический интерфейс, создаваемый этим примером.
Пример 9.6. PP4E\Gui\Tour\mbwtton.py
from tkinter import * root = Tk()
mbutton = Menubutton(root, text=’Food’) # отдельное раскрывающееся меню
picks = Menu(mbutton)
mbutton.config(menu=picks)
picks.add_command(label=’spam’, command=root.quit) picks.add_command(label=’eggs’, command=root.quit) picks.add_command(label=’bacon’, command=root.quit) mbutton.pack()
mbutton.config(bg=’white’, bd=4, relief=RAISED) root.mainloop()
В библиотеке tkinter имеется родственный виджет Optionmenu, который отображает выбранный элемент раскрывающегося меню. Он похож на Menubutton, к которому добавлена метка, и при щелчке на нем выводит меню вариантов выбора. Однако, чтобы получить результат выбора, нужно не регистрировать обработчик, а связывать переменные tkinter (описанные в главе 8), при этом элементы меню передаются конструктору в виде аргументов вслед за переменной.
Рис. 9.8. Виджет Menubutton сам по себе
Пример 9.7 иллюстрирует типичное использование виджета Optionmenu и создает интерфейс, изображенный на рис. 9.9. Щелчок на любой из первых двух кнопок открывает раскрывающееся меню. Щелчок на третьей кнопке state выводит текущие значения, отображаемые на первых двух.
Пример 9.7. PP4E\Gui\Tour\optionmenu.py
from tkinter import * root = Tk()
var1 = StringVar() var2 = StringVar()
opt1 = OptionMenu(root, var1, ‘spam’, ‘eggs’, ‘toast’) # как и Menubutton,
opt2 = OptionMenu(root, var2, ‘ham’, ‘bacon’, ‘sausage’) # но отображает
opt1.pack(fill=X) # выбранный вариант
opt2.pack(fill=X) var1.set(‘spam’) var2.set(‘ham’)
def state(): print(var1.get(), var2.get()) # связанные переменные
Button(root, command=state, text=’state’).pack()
root.mainloop()
Рис. 9.9. Виджет Optionmenu в действии
Есть и другие относящиеся к меню темы, которые мы пропустим в интересах экономии места. Например, сценарии могут добавлять элементы в системные меню и создавать всплывающие меню (отображаемые в ответ на события, не будучи связанными с кнопкой). Подробности по этой теме вы найдете в ресурсах Tk и tkinter.
Кроме простых пунктов и каскадов, меню могут также содержать неактивные пункты, флажки и переключатели, графические изображения. В следующем разделе демонстрируется, как программируются некоторые из этих специальных пунктов меню.
Окна с меню и панелью инструментов
Помимо меню, отображаемого в верхней части, окна часто содержат ряд кнопок в нижней части. Этот нижний ряд кнопок обычно называют панелью инструментов, и он нередко содержит кнопки для выполнения наиболее часто используемых операций, присутствующих в главном меню. С помощью библиотеки tkinter добавить в окно панель инструментов достаточно просто: нужно прикрепить кнопки (и другие виджеты) к фрейму, прикрепить фрейм к нижней границе окна и определить для него возможность растягивания только в горизонтальном направлении. Это просто очередная реализация иерархической структуры графического интерфейса, однако нужно следить, чтобы панели инструментов (и строки меню, основанные на фреймах) прикреплялись раньше других виджетов, чтобы при сжатии окна сначала обрезались виджеты, находящиеся в середине экрана, - обычно бывает желательно, чтобы панели инструментов и полосы меню имели приоритет перед другими виджетами.
В примере 9.8 представлен один из способов добавления панели инструментов в окно. Он демонстрирует также, как добавлять изображения в пункты меню (присвоить атрибуту image ссылку на объект PhotoImage) и как делать пункты меню недоступными для выбора, изображая их в серых тонах (вызвать метод меню entryconfig, передав ему индекс отключаемого пункта; отсчет начинается с 1). Обратите внимание, что объекты PhotoImage сохраняются в виде списка - напомню, что в отличие от других виджетов, они будут утеряны, если не сохранить ссылки на них (загляните в главу 8, если вам требуется освежить память).
Пример 9.8. PP4E\Gui\Tour\menuDemo.py
#!/usr/local/bin/python
главное меню окна в стиле Tk8.0
строка меню и панель инструментов прикрепляются к окну в первую очередь, fill=X (прикрепить первым = обрезать последним); добавляет изображения в элементы меню; смотрите также: add_checkbutton, add_radiobutton
from tkinter import * # импортировать базовый набор виджетов
from tkinter.messagebox import * # импортировать стандартные диалоги
class NewMenuDemo(Frame): # расширенный фрейм
def __init__(self, parent=None): # прикрепляется к корневому окну?
Frame.__init__(self, parent) # вызвать метод суперкласса
self.pack(expand=YES, fill=BOTH)
self.createWidgets() # прикрепить фреймы/виджеты
self.master.title("Toolbars and Menus”) # для менеджера окон self.master.iconname(“tkpython”) # текст метки при свертывании
def createWidgets(self): self.makeMenuBar() self.makeToolBar()
L = Label(self, text=’Menu and Toolbar Demo’)
L.config(relief=SUNKEN, width=40, height=10, bg=’white’) L.pack(expand=YES, fill=BOTH)
def makeToolBar(self):
toolbar = Frame(self, cursor=’hand2’, relief=SUNKEN, bd=2) toolbar.pack(side=BOTTOM, fill=X)
Button(toolbar, text=’Quit’, command=self.quit ).pack(side=RIGHT) Button(toolbar, text=’Hello’, command=self.greeting).pack(side=LEFT)
def makeMenuBar(self):
self.menubar = Menu(self.master)
self.master.config(menu=self.menubar) # master^^ верхнего уровня
self.fileMenu()
self.editMenu()
self.imageMenu()
def fileMenu(self):
pulldown = Menu(self.menubar)
pulldown.add_command(label=’Open...’, command=self.notdone) pulldown.add_command(label=’Quit’, command=self.quit) self.menubar.add_cascade(label=’File’, underline=0, menu=pulldown)
def editMenu(self):
pulldown = Menu(self.menubar)
pulldown.add_command(label=’Paste’, command=self.notdone) pulldown.add_command(label=’Spam’, command=self.greeting) pulldown.add_separator()
pulldown.add_command(label=’Delete’, command=self.greeting) pulldown.entryconfig(4, state=DISABLED)
self.menubar.add_cascade(label=’Edit’, underline=0, menu=pulldown) def imageMenu(self):
photoFiles = (‘ora-lp4e.gif’, ‘pythonPowered.gif’,
‘python_conf_ora.gif’) pulldown = Menu(self.menubar) self.photoObjs = [] for file in photoFiles:
img = PhotoImage(file=’../gifs/’ + file) pulldown.add_command(image=img, command=self.notdone) self.photoObjs.append(img) # сохранить ссылку
self.menubar.add_cascade(label=’Image’, underline=0, menu=pulldown)
def greeting(self):
showinfo(‘greeting’, ‘Greetings’) def notdone(self):
showerror(‘Not implemented’, ‘Not yet available’) def quit(self):
if askyesno(‘Verify quit’, ‘Are you sure you want to quit?’): Frame.quit(self)
if __name__ == ‘__main__’: NewMenuDemo().mainloop() # если запущен как
# самостоятельный сценарий
Если запустить этот сценарий, он сначала создаст интерфейс, изображенный на рис. 9.10. На рис. 9.11 изображено это же окно после того как оно было несколько растянуто, с оторванным меню Image и выбранным меню Edit. Панель инструментов в нижней части окна растягивается вместе с окном только по горизонтали. Обратите также внимание, что этот сценарий изменяет форму указателя мыши, когда он находится над панелью инструментов. Поэкспериментируйте с ним самостоятельно, чтобы получить более полное представление о том, как он действует.
Использование изображений в панелях инструментов
Как видно на рис. 9.11, пункты меню легко могут быть украшены графическими изображениями. Хотя это и не было продемонстрировано в примере 9.8, тем не менее элементы панелей инструментов могут также снабжаться картинками, как и элементы меню Image в примере. Для этого достаточно просто поместить небольшие изображения на кнопки в панели инструментов, как мы делали это в примерах с миниатюрами, в последнем разделе главы 8. Как вы уже знаете, при наличии предварительно созданных изображений для кнопок на панели инструментов не составляет никакого труда ассоциировать их с кнопками. Фактически для динамического создания таких изображений требуется приложить ненамного больше труда - навыки создания миниатюр с помощью пакета PIL, полученные нами в предыдущей главе, придутся кстати и в этом контексте.
Рис. 9.10. Сценарий menuDemo: меню и панели инструментов
Рис. 9.11. Изображения в меню и отрывные меню в действии
Для иллюстрации сказанного убедитесь, что у вас расширение PIL установлено, и замените метод конструирования панели инструментов в примере 9.8 следующим фрагментом (я выполнил такую замену в файле menuDemo2.py в пакете с примерами, поэтому вы можете запускать его и экспериментировать с ним):
# изменяет размеры изображений для кнопок на панели инструментов с помощью PIL def makeToolBar(self, size=(40, 40)):
from PIL.ImageTk import PhotoImage, Image # для jpeg или новых миниатюр imgdir = r’../PIL/images/’
toolbar = Frame(self, cursor=’hand2’, relief=SUNKEN, bd=2)
toolbar.pack(side=BOTTOM, fill=X)
photos = ‘ora-lp4e-big.jpg’, ‘PythonPoweredAnim.gif’,
‘python_conf_ora.gif’ self.toolPhotoObjs = [] for file in photos:
imgobj = Image.open(imgdir + file) # создать новую миниатюру
imgobj.thumbnail(size, Image.ANTIALIAS) # фильтр с лучшим качеством img = PhotoImage(imgobj)
btn = Button(toolbar, image=img, command=self.greeting) btn.config(relief=RAISED, bd=2) btn.config(width=size[0], height=size[1]) btn.pack(side=LEFT)
self.toolPhotoObjs.append((img, imgobj)) # сохранить ссылку Button(toolbar, text=’Quit’, command=self.quit).pack(side=RIGHT, fill=Y)
Если запустить этот альтернативный сценарий, он создаст окно, изображенное на рис. 9.12, - три пункта меню Image, присутствующего в верхней части окна, теперь также доступны в виде кнопок на панели инстру-
Рис. 9.12. Сценарий menuDemo2: добавление изображений в панель инструментов с помощью PIL
ментов в нижней части окна, наряду с кнопкой завершения программы, содержащей текстовую метку. Как и прежде, указатель мыши меняет свою форму при наведении на кнопки в панели инструментов.
Пакет PIL можно не использовать при наличии изображений в формате GIF или в поддерживаемом растровом формате, созданных вручную. Достаточно просто загружать изображения из файлов, используя стандартный объект PhotoImage из библиотеки tkinter, как показано в следующей альтернативной реализации метода конструирования панели инструментов (эта версия сценария сохранена в файле menuDemo3.py в пакете с примерами):
# использует подготовленные изображения gif и стандартные средства tkinter
def makeToolBar(self, size=(30, 30)): imgdir = r’../gifs/’
toolbar = Frame(self, cursor=’hand2’, relief=SUNKEN, bd=2) toolbar.pack(side=BOTTOM, fill=X)
photos = ‘ora-lp4e.gif’, ‘pythonPowered.gif’, ‘python_conf_ora.gif’ self.toolPhotoObjs = [] for file in photos:
img = PhotoImage(file=imgdir + file)
btn = Button(toolbar, image=img, command=self.greeting)
btn.config(bd=5, relief=RIDGE)
btn.config(width=size[0], height=size[1])
btn.pack(side=LEFT)
self.toolPhotoObjs.append(img) # сохранить ссылку
Button(toolbar, text=’Quit’, command=self.quit).pack(side=RIGHT, fill=Y)
Если запустить эту альтернативную версию, использующую изображения в формате GIF, она воспроизведет окно, изображенное на рис. 9.13. В зависимости от предпочтений ваших пользователей вам может потребоваться изменить размеры изображений GIF, используемых в этом качестве, с помощью других инструментов - изображения на кнопках фиксированного размера здесь выводится только частично, что может оказаться нежелательным.
Данный пример является первым приблизительным решением для создания кнопок с картинками на панели инструментов. Существует множество других способов настройки таких кнопок. Однако, поскольку мы собираемся еще вернуться к пакету PIL далее в этой главе, когда будем исследовать холсты, мы оставим дальнейшую доработку сценария для самостоятельного упражнения.
Автоматизация создания меню
Меню служат мощным инструментом создания интерфейса в tkinter. Однако если вы рассуждаете, как я, примеры из этого раздела могут показаться вам слишком трудоемкими. Конструирование меню требует писать много программного кода, и велика вероятность ошибок. Лучше
Рис. 9.13. Сценарий menuDemo3: заранее подготовленные изображения GIF в панели инструментов
было бы автоматически строить и связывать меню, описывая их содержимое на более высоком уровне. В главе 10 мы познакомимся с инструментом, носящим название GuiMixin, который автоматизирует процесс создания меню исходя из структуры данных, описывающей все необходимые меню. Дополнительным преимуществом этого инструмента является поддержка обоих типов меню - оконных и на основе фреймов, благодаря чему они могут использоваться как в самостоятельных программах, так и во вложенных компонентах. Важно понимать, какие вызовы лежат в основе создания меню, но не обязательно запоминать их навсегда.
Виджеты Listbox и Scrollbar
Возобновим наш обзор виджетов. Виджеты Listbox позволяют отображать списки элементов, доступных для выбора, а виджеты Scrollbar предназначаются для прокрутки содержимого других виджетов. Эти виджеты часто используются друг с другом, поэтому будем изучать их одновременно. В примере 9.9 виджеты Listbox и Scrollbar образуют упакованный набор.
Пример 9.9. PP4E\Gui\Tour\scrolledlist.py
“простой настраиваемый компонент окна списка с прокруткой”
from tkinter import * class ScrolledList(Frame):
def __init__(self, options, parent=None):
Frame.__init__(self, parent)
self.pack(expand=YES, fill=BOTH) # сделать растягиваемым self.makeWidgets(options)
def handleList(self, event):
index = self.listbox.curselection() # при двойном щелчке на списке label = self.listbox.get(index) # извлечь выбранный текст
self.runCommand(label) # и вызвать действие
# или get(ACTIVE)
def makeWidgets(self, options): sbar = Scrollbar(self) list = Listbox(self, relief=SUNKEN)
sbar.config(command=list.yview) # связать sbar и list
list.config(yscrollcommand=sbar.set) # сдвиг одного = сдвиг другого sbar.pack(side=RIGHT, fill=Y) # первым добавлен - посл. обрезан
list.pack(side=LEFT, expand=YES, fill=BOTH) # список обрезается первым pos = 0
for label in options: # добавить в виджет списка
list.insert(pos, label) # или insert(END,label)
pos += 1 # или enumerate(options)
#list.config(selectmode=SINGLE, setgrid=1) # режимы выбора, измен. разм. list.bind(‘’, self.handleList) # установить обр-к события self.listbox = list
def runCommand(self, selection): # необходимо переопределить
print(‘You selected:’, selection)
if __name__ == ‘__main__’:
options = ((‘Lumberjack-%s’ % x) for x in range(20)) # или map/lambda,
ScrolledList(options).mainloop() # [...]
Этот модуль можно запускать как самостоятельный сценарий, чтобы поэкспериментировать с этими виджетами, или использовать в качестве библиотечного объекта. Передавая различные списки выбора в аргументе options и переопределяя метод runCommand в подклассе, можно повторно использовать определенный здесь класс компонента ScrolledList всякий раз когда потребуется вывести список с прокруткой. Мы еще будем использовать этот класс в главе 11, в примере программы PyEdit. При грамотном подходе можно легко расширить библиотеку tkinter классами на языке Python таким способом.
Если запустить этот пример как самостоятельный сценарий, он создаст окно, подобное изображенному на рис. 9.14, которое было получено в Windows 7. Это фрейм Frame со списком Listbox в левой части, содержащим 20 сгенерированных элементов (на пятом выполнен щелчок) и связанным с виджетом Scrollbar в правой части, предназначенным для прокрутки списка. Если переместить ползунок в полосе прокрутки, список также будет прокручиваться, и наоборот.
Рис. 9.14. Сценарий scrolledlist в действии
Программирование виджетов списков
Виджеты списков достаточно просты в использовании, но в сравнении с виджетами, которые рассматривались до сих пор, они заполняются и обрабатываются довольно своеобразными способами. Многие методы виджета списка принимают индекс, указывающий на элемент списка. Нумерация элементов начинается с 0, но библиотека tkinter вместо целочисленных смещений принимает также особые строки имен: end - для ссылки на конец списка, active - для обозначения выбранной строки и другие. Поэтому обращение к виджету списка обычно можно оформить несколькими способами.
Например, следующий сценарий добавляет элементы к списку, находящемуся в окне, вызывая его метод insert и последовательно увеличивая смещение (начиная с нуля - эту операцию можно было бы автоматизировать с помощью встроенной функции enumerate):
list.insert(pos, label) pos = pos + 1
Но список можно также заполнить, добавляя элементы в конец, вообще не используя счетчик, - с помощью любой из следующих инструкций:
list.insert(‘end’, label) # добавление в конец: подсчет позиций не нужен list.insert(END, label) # END - константа со значением ‘end’ в tkinter
Виджет Listbox не имеет параметра, такого как command, с помощью которого обычно регистрируются обработчики событий нажатий кнопок, поэтому выделенные в нем элементы следует получать во время обработки событий других виджетов (например, щелчков на кнопках) либо обрабатывать сделанные пользователем выделения, внедряясь в протоколы других событий. Чтобы получить выбранное значение, в следующем сценарии выполняется привязка обработчика события двойного щелчка левой кнопкой мыши с помощью bind (рассмотренного ранее в этом обзоре).
В обработчике двойного щелчка этот сценарий получает выделенный в списке элемент с помощью следующей пары методов:
index = self.listbox.curselection() # получить индекс выделенного элемента label = self.listbox.get(index) # текст, соответствующий этому индексу
Эту операцию можно реализовать иначе. Обе следующие строки дают одинаковый результат: они получают содержимое строки с индексом ‘active’, то есть выбранной в данный момент:
label = self.listbox.get(‘active’) # получить по индексу active label = self.listbox.get(ACTIVE) # в tkinter ACTIVE=’active’
Для иллюстрации, метод класса по умолчанию runCommand выводит выбранное значение при каждом двойном щелчке на элементе списка -сценарий получает его в виде строки с текстом выбранного элемента:
C:\...\PP4E\Gui\Tour> python scrolledlist.py
You selected: Lumberjack-2 You selected: Lumberjack-19 You selected: Lumberjack-4 You selected: Lumberjack-12
Виджеты списков могут служить отличными инструментами ввода данных даже без полос прокрутки. Они принимают также параметры настройки, определяющие цвет, шрифт и рельеф. Наряду с режимом выбора единственного элемента они также поддерживают возможность выбора нескольких элементов одновременно. По умолчанию используется режим выбора единственного элемента, но вы можете передать в аргументе selectmode четыре значения: SINGLE, BROWSE, MULTIPLE и EXTENDED (по умолчанию: BROWSE). Первые два из них определяют режимы выбора единственного элемента, а последние два позволяют выбирать сразу несколько элементов.
Эти режимы имеют очень тонкие отличия. Например, режим BROWSE напоминает SINGLE, но дополнительно позволяет перетаскивать выделенный элемент. Щелчок на элементе в режиме MULTIPLE изменяет его состояние, не оказывая влияния на состояние других элементов. Режим EXTENDED также позволяет выбирать несколько элементов, но использует порядок выделения, как принято в интерфейсе проводника файлов Windows - первый элемент выбирается простым щелчком, несколько элементов - щелчком, при удерживаемой клавише CtrL, а диапазон элементов - щелчком, при удерживаемой клавише Shift. Режим множественного выбора можно реализовать, как показано ниже:
listbox = Listbox(window, bg=’white’, font=(‘courier’, fontsz)) listbox.config(selectmode=EXTENDED)
listbox.bind(‘’, (lambda event: onDoubleClick()))
# onDoubeClick: извлекает сообщения, выбранные в списке
selections = listbox.curselection() # кортеж строк чисел, 0..N-1
selections = [int(x)+1 for x in selections] # преобразует в int,
# переводит в диапазон 1..N
В режиме множественного выбора метод curselection возвращает список строк цифр, соответствующих позициям выбранных элементов, -если не выбран ни один элемент, возвращается пустой кортеж. В действительности этот метод всегда возвращает кортеж строк цифр, даже в режиме выбора единственного элемента (нам не пришлось беспокоиться об этом в примере 9.9, потому что метод get виджета при извлечении значения корректно воспринимает кортеж с одним элементом).
Вы можете самостоятельно поэкспериментировать с альтернативными режимами выбора, раскомментировав строку в примере 9.9, где определяется параметр selectmode, и изменяя значение. При этом двойной щелчок мышью в режиме множественного выбора может порождать сообщение об ошибке, потому что методу get будет передаваться кортеж более чем с одним индексом выбранного элемента (выведите его, чтобы убедиться в этом). Режим множественного выбора мы будем использовать в примере PyMailGUI, далее в этой книге (в главе 14), поэтому дальнейшее обсуждение этой темы я отложу до будущих примеров.
Программирование полос прокрутки
Однако самое большое таинство в примере 9.9 свершается в следующих двух строках:
sbar.config(command=list.yview) # вызвать list.yview при перемещении list.config(yscrollcommand=sbar.set) # вызвать sbar.set при перемещении
С помощью этих параметров настройки производится связывание полосы прокрутки и окна списка - их значения просто ссылаются на связанные методы друг друга. Благодаря такому соединению библиотека tkinter автоматически синхронизирует два виджета при перемещениях в них. Вот как это действует:
• Перемещение полосы прокрутки вызывает обработчик, зарегистрированный с помощью ее параметра command. Здесь list.yview ссылается на встроенный метод виджета списка, который пропорционально настраивает отображение списка, исходя из аргументов, переданных обработчику.
• При вертикальном перемещении в окне списка вызывается обработчик, зарегистрированный в его параметре yscrollcommand. В данном сценарии встроенный метод sbar.set пропорционально настраивает полосу прокрутки.
Иными словами, прокрутка в одном виджете автоматически вызывает прокрутку в другом. В tkinter у всех прокручиваемых элементов - Listbox, Entry, Text и Canvas - есть встроенные методы yview и xview для обработки прокрутки по вертикали и по горизонтали, а также параметры yscrollcommand и xscrollcommand, в которых определяются обработчики связанной с ними полосы прокрутки. У полос прокрутки есть параметр command, в котором указывается обработчик, вызываемый при прокрутке. Библиотека tkinter передает этим методам информацию, определяющую новое положение (например, «прокрутить вниз на 10%»), но программисту не требуется опускаться в сценариях до таких деталей.
Так как полоса прокрутки и окно списка взаимно связаны путем установки их параметров, при перемещении движка полосы прокрутки автоматически происходит прокрутка содержимого списка, а при прокрутке содержимого списка автоматически перемещается движок в полосе прокрутки. Чтобы выполнить перемещение с помощью полосы прокрутки, нужно перетащить ее движок либо щелкнуть на стрелке или в пустой области. Чтобы выполнить прокрутку в списке, следует щелкнуть на нем и использовать клавиши со стрелками или переместить указатель мыши выше или ниже окна, не отпуская кнопки мыши. В обоих случаях список и полоса прокрутки двигаются в унисон. На рис. 9.15 показано, что произойдет после перемещения в списке на несколько элементов вниз тем или иным способом.
Рис. 9.15. Прокрутка до середины списка
Компоновка полос прокрутки
Наконец, вспомним, что виджеты, присоединяемые к интерфейсу последними, всегда обрезаются первыми при уменьшении размеров окна. По этой причине важно добавлять полосы прокрутки как можно раньше, чтобы они исчезли последними, когда окно уменьшится до таких размеров, что в нем ничего нельзя будет показать. Обычно можно справиться с тем, что окно списка выведено не полностью, но полоса прокрутки необходима для перемещения по списку. Как показано на
Рис. 9.16. Список уменьшился
рис. 9.16, при уменьшении окна сценария отрезается часть списка, но полоса прокрутки сохраняется.
В то же время, обычно не требуется, чтобы полоса прокрутки расширялась вместе с окном, поэтому компоновка ее должна выполняться с одним параметром fill=Y (или fill=X для прокрутки по горизонтали), без expand=YES. В частности, расширение окна этого примера увеличивает окно списка, но изменяет ширину полосы прокрутки, прикрепленной справа.
В примерах этой и последующих глав мы неоднократно будем встречаться с полосами прокрутки и виджетами списков (можно заглянуть вперед и посмотреть примеры PyEdit, PyMailGUI, PyForm, PyTree и ShellGui). И хотя основы их применения охватываются в данной главе, следует отметить, что за кадром осталось многое, что могут предложить эти виджеты.
Например, столь же легко к прокручиваемым виджетам можно добавить горизонтальные полосы прокрутки. Они программируются почти так же, как вертикальные, только имена обработчиков начинаются с «х», а не «y» (например, xscrollcommand), а для объекта полосы прокрутки устанавливается параметр orient= ’horizontal’. Чтобы добавить сразу две полосы прокрутки, вертикальную и горизонтальную, и связать их с виджетом, можно использовать такой прием:
window = Frame(self)
vscroll = Scrollbar(window)
hscroll = Scrollbar(window, orient=’horizontal’)
listbox = Listbox(window)
# прокрутить список при перемещении движка в полосе прокрутки vscroll.config(command=listbox.yview, relief=SUNKEN) hscroll.config(command=listbox.xview, relief=SUNKEN)
# переместить движок в полосе прокрутки при прокрутке списка listbox.config(yscrollcommand=vscroll.set, relief=SUNKEN) listbox.config(xscrollcommand=hscroll.set)
Смотрите пример использования холста для вывода изображений далее в этой главе, а также в программах PyEdit, PyTree и PyMailGUI далее в этой книге, где демонстрируется использование горизонтальных полос прокрутки. Полосы прокрутки могут действовать в графических интерфейсах различными способами - их можно связывать с виджетами других типов. Например, их часто прикрепляют к виджету Text, что приводит нас к следующей теме данного обзора.
Виджет Text
Уже отмечалось, что наиболее сильными сторонами библиотеки tkinter являются виджеты Text и Canvas. Оба они обладают богатым набором функций. Например, виджет Text оказался достаточно мощным, чтобы на его основе можно было создать веб-броузер Grail - экспериментальный веб-броузер, реализованный на языке Python. Виджет Text поддерживает сложные настройки стилей шрифтов, позволяет встраивать графику, имеет неограниченное количество уровней отката и возврата изменений и многое другое. Виджет Canvas, универсальный графический инструмент, позволяет отображать произвольные изображения и также положен в основу многих приложений для сложной обработки изображений и визуализации.
В главе 11 мы воспользуемся двумя этими виджетами для реализации текстового редактора (PyEdit), графического редактора (PyDraw), часов с графическим интерфейсом (PyClock) и программ для просмотра изображений (PyPhoto и PyView). Однако в этой, экскурсионной главе мы будем использовать эти виджеты в более простых примерах. В примере 9.10 реализован простой интерфейс отображения текста с прокруткой, который может вывести строку текста или файл.
Пример 9.10. PP4E\Gui\Tour\scrolledtext.py
"простой компонент просмотра текста или содержимого файла”
print(‘PP4E scrolledtext’)
from tkinter import *
class ScrolledText(Frame):
def __init__(self, parent=None, text=’’, file=None):
Frame.__init__(self, parent)
self.pack(expand=YES, fill=BOTH) # сделать растягиваемым
self.makewidgets()
self.settext(text, file)
def makewidgets(self): sbar = Scrollbar(self) text = Text(self, relief=SUNKEN)
sbar.config(command=text.yview) # связать sbar и text
text.config(yscrollcommand=sbar.set) # сдвиг одного = сдвиг другого sbar.pack(side=RIGHT, fill=Y) # первым добавлен - посл. обрезан
text.pack(side=LEFT, expand=YES, fill=BOTH) # Text обрезается первым self.text = text
def settext(self, text=’’, file=None): if file:
text = open(file, ‘r’).read()
self.text.delete(‘1.0’, END) # удалить текущий текст
self.text.insert(‘1.0’, text) # добавить в стр. 1, кол. 0
self.text.mark_set(INSERT, ‘1.0’) # установить курсор вставки
self.text.focus() # сэкономить щелчок мышью
def gettext(self): # возвращает строку
return self.text.get(‘1.0’, END+’-1c’) # от начала до конца
if__name__== ‘__main__’:
root = Tk() if len(sys.argv) > 1:
st = ScrolledText(file=sys.argv[1]) # имя файла в командной строке else:
st = ScrolledText(text=’Words\ngo here’) # иначе: две строки def show(event):
print(repr(st.gettext())) # вывести как простую строку
root.bind(‘’, show) # esc = выводит дамп текста
root.mainloop()
Подобно объекту ScrolledList из примера 9.9 объект ScrolledText в этом файле создавался как многократно используемый компонент, но точно так же этот сценарий может выполняться автономно, выводя содержимое текстового файла. Так же, как в предыдущем разделе, этот сценарий сначала прикрепляет полосу прокрутки, чтобы при сжатии окна она исчезала последней, и настраивает встроенный объект Text, чтобы он растягивался в обоих направлениях при увеличении размеров окна. Если при запуске передать сценарию аргумент с именем файла, он создаст окно, изображенное на рис. 9.17: сценарий встраивает виджет Text в левую часть окна, а связанную с ним полосу прокрутки - в правую.
Для забавы я заполнил текстовый файл43, отображаемый в окне, с помощью следующего сценария и команд (и не только потому, что я жил в Колорадо рядом с отелем, пользующимся дурной славой):
C:\...\PP4E\Gui\Tour> type makefile.py
f = open(‘jack.txt’, ‘w’) for i in range(250):
f.write(‘%03d) All work and no play makes Jack a dull boy.\n’ % i) f.close()
C:\...\PP4E\Gui\Tour> python makefile.py
C:\...\PP4E\Gui\Tour> python scrolledtext.py jack.txt
PP4E scrolledtext
Рис. 9.17. Сценарий scrolledtext в действии
Для просмотра файла его имя нужно передать сценарию в аргументе командной строки - текст файла будет автоматически выведен в новом окне. По умолчанию он выводится шрифтом, который может оказаться разным на разных платформах (и может оказаться не моноширинным в некоторых их них), но в следующем примере мы устраним это несоответствие, передав виджету Text параметр font. Нажатие клавиши Escape вызывает извлечение и вывод всего текстового содержимого виджета в виде единственной строки (подробнее об этом чуть ниже).
Обратите внимание на сообщение PP4E scrolledtext, которое выводится при выполнении сценария. Поскольку в стандартном дистрибутиве Python также есть файл scrolledtext.py (в модуле tkinter.scrolledtext) с совершенно иной реализацией и интерфейсом, данный сценарий идентифицирует себя при выполнении или импортировании, чтобы можно было отличить один от другого. Если сценарий стандартной библиотеки когда-либо будет исключен из дистрибутива, импортируйте тот, что приведен здесь, чтобы получить простое средство просмотра текста, и измените вызовы настройки параметров, чтобы они содержали спецификатор .text (например, x.text.config вместо x.config - библиотечная версия создает подкласс Text, а не Frame).
Программирование виджета Text
Чтобы понять, как вообще работает этот сценарий, необходимо разобраться с некоторыми особенностями виджета Text. Мы уже знакомы с виджетами Entry и Message, которые охватывают некоторое подмножество возможных применений виджета Text. В отличие от них, виджет Text обладает более широкими функциональными возможностями - он поддерживает ввод и отображение нескольких строк текста, операции редактирования для программ и интерактивных пользователей, различные шрифты и цвета и многое другое. Объекты Text создаются, настраиваются и прикрепляются к графическому интерфейсу так же, как любые другие виджеты, но у них есть особые свойства.
Текст является строкой Python
Несмотря на всю мощь виджета Text, его интерфейс можно свести к двум базовым понятиям. Во-первых, содержимое элемента Text представляется в сценариях Python в виде единой строки, где несколько строчек разделяются обычным символом \n завершения строки. Например, строка 'Words\ngo here’ представляет две строчки при записи в виджет Text и при получении из него. Обычно текстовое содержимое имеет замыкающий символ \n, но это не обязательно.
Чтобы проиллюстрировать эту особенность, данный сценарий связывает событие нажатия клавиши Escape с обработчиком, который получает и выводит все содержимое виджета Text:
C:\...\PP4E\Gui\Tour> python scrolledtext.py
PP4E scrolledtext
‘ Words\ngo here’
‘Always look\non the bright\nside of life\n’
Если запустить этот сценарий с аргументом, он запишет в виджет Text все содержимое файла. При запуске без аргументов сценарий вставит в виджет простую литеральную строку, отображаемую при первом нажатии Escape (напомню, что \n является экранированной последовательностью, соответствующей символу конца строки). Второй вывод был получен после редактирования текста, нажатием клавиши Escape в уменьшенном окне, изображенном на рис. 9.18.
Рис. 9.18. Сценарий scrolledtext учит смотреть на жизнь позитивно
Позиция в строке
Вторым ключом к пониманию виджета Text является определение позиции в строке текста. Как и виджеты списков, виджеты Text позволяют указывать эту позицию различными способами. Методы Text, ожидающие получить позицию, принимают индекс, метку или тег. Кроме того, некоторые особые операции вызываются с предопределенными метками или тегами - текстовый курсор вставки имеет метку INSERT, а текущее выделение имеет тег SEL. Так как они являются фундаментальными при работе с виджетом Text и обеспечивают большую часть его выразительности, рассмотрим поближе эти параметры настройки.
Индексы в Text. Будучи многострочным виджетом, Text поддерживает индексы строк и колонок. Например, рассмотрим интерфейсы базовых операций ввода, удаления и извлечения текста, используемые в этом сценарии:
self.text.insert(‘1.0’, text) # вставить текст в начало
self.text.delete(‘1.0’, END) # полностью удалить текущий текст
return self.text.get(‘1.0’, END+’-1c’) # получить текст от начала до конца
Во всех этих предложениях первый аргумент является абсолютным индексом, ссылающимся на начало строки с текстом: строка ‘1.0’ означает строку 1, колонку 0 (строки нумеруются с 1, а колонки - с 0, однако аргумент ‘0.0’ также считается допустимым и интерпретируется как ссылка на начало текста). Индекс ‘2.1’ ссылается на второй символ во второй строке.
Как и в случае с виджетом списка, при работе с текстовым виджетом также можно использовать символические имена: END в предшествующем вызове метода delete указывает на позицию, находящуюся сразу за последним символом в строке текста (библиотека tkinter записывает в эту переменную ‘end’). Аналогично символический индекс INSERT (на самом деле строка ‘insert’) ссылается на позицию, находящуюся сразу за курсором вставки, - место, где будут появляться символы, вводимые с клавиатуры. Символические имена, такие как INSERT, можно также назвать метками, которые будут описаны ниже.
Дополнительной точности можно достичь, добавляя к строкам индексов простые арифметические расширения. Индексное выражение END+’-1c’ в вызове метода get в предыдущем примере в действительности является строкой end-1c’ и ссылается на позицию за один символ до END. Поскольку END указывает на место сразу за последним символом строки текста, это выражение ссылается на сам последний символ. В результате расширение -1c отрезает замыкающий символ \n, который виджет добавляет к своему содержимому (и который может добавить пустую строку при сохранении в файле).
Аналогичные расширения строк индексов позволяют ссылаться на символы, находящиеся впереди (+1c), строки, находящиеся впереди и позади (+2l, -2l), а также на концы строк и начала слов, в которых находится индекс (lineend, wordstart). Индексы передаются большинству методов виджета Text.
Метки в Text. Помимо идентификаторов строка/колонка, позиции можно определять в виде имен меток - символических имен позиций между двумя символами. В отличие от абсолютных позиций строка/колонка, метки являются виртуальными адресами, которые перемещаются при вставке нового текста или его удалении (выполняемых сценарием или пользователем). Метка всегда ссылается на первоначальное местоположение, даже если оно смещается с течением времени в другую строку или колонку.
Для создания метки используется метод mark_set объекта Text, которому передается строка имени и индекс, определяющий ее логическое положение. Например, этот сценарий устанавливает текстовый курсор вставки в начало текста с помощью первого из вызовов:
self.text.mark_set(INSERT, ‘1.0’) # установить курсор вставки в начало
self.text.mark_set(‘linetwo’, ‘2.0’) # пометить текущую строку 2
Имя INSERT является специальной предопределенной меткой, идентифицирующей позицию текстового курсора вставки, - изменение ее влечет изменение позиции курсора вставки. Чтобы создать собственную метку, достаточно просто передать уникальное имя, как показано во втором вызове выше, и использовать его везде, где требуется указать позицию в тексте. Вызов метода mark_unset удаляет метку по имени.
Теги в Text. Кроме абсолютных индексов и символических имен меток виджет Text поддерживает понятие тегов - символических имен, ассоциируемых с одной или несколькими подстроками в текстовом содержимом виджета Text. Теги можно применять с разными целями, в том числе для представления позиции там, где это требуется: помеченные тегами элементы определяются индексами начала и конца, которые можно впоследствии передавать методам, требующим указания позиции.
Например, библиотека tkinter предоставляет встроенный тег с именем SEL - переменную с предопределенным строковым значением ‘sel', -которое автоматически ссылается на текст, выделенный в данный момент. Чтобы получить текст, выделенный (подсвеченный) с помощью мыши, вызовите любой из следующих методов:
text = self.text.get(SEL_FIRST, SEL_LAST) # теги для индексов от/до
text = self.text.get(‘sel.first’, ‘sel.last’) # или строки и константы
Имена SEL_FIRST и SEL_LAST являются обычными переменными в модуле tkinter с предопределенными значениями, используемыми во втором вызове. Метод get ожидает получить два индекса. Чтобы получить текст по тегу, добавьте к его имени расширения .first и .last, которые дают индексы начала и конца.
Чтобы пометить тегом подстроку, можно вызвать метод tag_add виджета Text, передав ему строку с именем тега и позиции начала и конца (тегами можно помечать текст, добавляемый методом insert). Чтобы снять тег со всех символов в некоторой области текста, можно вызвать метод
tag_remove:
self.text.tag_add(‘alltext’, ‘1.0’, END) # пометить тегом весь текст self.text.tag_add(SEL, index1, index2) # выделить от index1 до index2 self.text.tag_remove(SEL, ‘1.0’, END) # снять выделение со всего текста
Здесь в первой строке создается новый тег для всего текста в виджете -от начальной до конечной позиции. Во второй строке во встроенный тег выделения SEL добавляется диапазон символов - эти символы автоматически подсвечиваются, поскольку для этого тега предопределена такая настройка его элементов. В третьей строке все символы текста исключаются из тега SEL (снимаются все выделения). Обратите внимание, что метод tag_remove просто снимает тег с текста в указанном диапазоне - чтобы полностью удалить тег, нужно вызвать метод tag_delete. Кроме того, имейте в виду, что эти методы применяются к самим тегам - чтобы удалить фактический текст, следует использовать метод delete, представленный выше.
Можно также динамически отображать индексы в теги. Например, метод search возвращает индекс row.column первого вхождения строки между начальной и конечной позициями. Чтобы автоматически выделить найденный текст, его индекс следует добавить во встроенный тег SEL:
where = self.text.search(target, INSERT, END) # поиск от курсора вставки pastit = where + (‘+%dc’ % len(target)) # индекс за найденной строкой
self.text.tag_add(SEL, where, pastit) # пометить и выделить найденную строку self.text.focus() # выбрать сам виджет Text
Если требуется выделить только одну строку, нужно сначала вызвать метод tag_remove, о котором говорилось выше, - этот фрагмент добавляет новое выделение к тем, которые уже существуют (таким способом на экране можно создать нескольких выделений). Вообще в тег можно добавить любое количество подстрок и обрабатывать их группой.
Подведем итоги: индексы, метки и позиции тегов можно использовать везде, где требуется указать позицию в тексте. Например, метод see прокручивает содержимое, пока требуемая позиция не окажется в области видимости, - он позволяет указывать позиции всеми тремя способами:
self.text.see(‘1.0’) # прокрутить вверх
self.text.see(INSERT) # прокрутить до метки курсора вставки
self.text.see(SEL_FIRST) # прокрутить до тега выделения
Теги также могут применяться для форматирования и привязки событий, но эти подробности будут обсуждаться в конце раздела.
Операции редактирования текста
В примере 9.11 используются некоторые из этих понятий. Он расширяет пример 9.10, добавляя поддержку четырех наиболее часто используемых операций редактирования - сохранение в файл, удаление и вставка текста и поиск строки - за счет создания подкласса, наследующего класс ScrolledText, с дополнительными кнопками и методами. В виджете Text есть набор готовых привязок клавиш, выполняющих некоторые часто используемые операции редактирования, но они могут оказаться совсем не теми, которые можно было бы ожидать на конкретных платформах. Чаще в текстовом редакторе с графическим интерфейсом предоставляются специальные элементы управления, выполняющие операции редактирования, что более дружественно по отношению к пользователю.
Пример 9.11. PP4E\Gui\Tour\simpleedit.py
за счет наследования добавляет в ScrolledText типичные инструменты редактирования; аналогичного результата можно было бы добиться, применив прием композиции (встраивания); ненадежно! -- надмножество функций имеется в PyEdit;
from tkinter import *
from tkinter.simpledialog import askstring from tkinter.filedialog import asksaveasfilename from quitter import Quitter
from scrolledtext import ScrolledText # наш, не из библиотеки Python
class SimpleEditor(ScrolledText): # доп. ф-ции смотрите в PyEdit
def __init__(self, parent=None, file=None):
frm = Frame(parent) frm.pack(fill=X)
Button(frm, text=’Save’, command=self.onSave).pack(side=LEFT)
Button(frm, text=’Cut’, command=self.onCut).pack(side=LEFT)
Button(frm, text=’Paste’, command=self.onPaste).pack(side=LEFT) Button(frm, text=’Find’, command=self.onFind).pack(side=LEFT) Quitter(frm).pack(side=LEFT)
ScrolledText.__init__(self, parent, file=file)
self.text.config(font=(‘courier’, 9, ‘normal’))
def onSave(self):
filename = asksaveasfilename() if filename:
alltext = self.gettext() # от начала до конца
open(filename, ‘w’).write(alltext) # сохранить текст в файл
def onCut(self):
text = self.text.get(SEL_FIRST, SEL_LAST) # ошибка, если нет выделения self.text.delete(SEL_FIRST, SEL_LAST) # следует обернуть в try self.clipboard_clear() self.clipboard_append(text)
def onPaste(self): # добавляет текст из буфера
try:
text = self.selection_get(selection=’CLIPBOARD’)
self.text.insert(INSERT, text) except TclError:
pass # не вставлять
def onFind(self):
target = askstring(‘SimpleEditor’, ‘Search String?’) if target:
where = self.text.search(target, INSERT, END) # от позиции курсора if where: # вернуть индекс
print(where)
pastit = where + (‘+%dc’ % len(target)) # индекс за целью #self.text.tag_remove(SEL, ‘1.0’, END) # снять выделение self.text.tag_add(SEL, where, pastit) # выделить найденное self.text.mark_set(INSERT, pastit) # установить метку вставки
self.text.see(INSERT) # прокрутить текст
self.text.focus() # выбрать виджет Text
if __name__ == ‘__main__’: if len(sys.argv) > 1:
SimpleEditor(file=sys.argv[1]).mainloop() # имя файла в ком. строке else:
SimpleEditor().mainloop() # или нет: пустой виджет
Этот сценарий также был написан с оглядкой на многократное использование - определяемый в нем класс SimpleEditor можно прикрепить или унаследовать в другой реализации графического интерфейса. Однако, как будет разъяснено в конце раздела, данный пример не настолько надежен, как требуется от библиотечного инструмента общего назначения. Тем не менее в нем реализован действующий текстовый редактор, программный код которого переносим и имеет небольшой объем. Если запустить пример как самостоятельный сценарий, он выведет окно, изображенное на рис. 9.19 (здесь он был запущен в Windows). После каждой успешной операции поиска позиции индексов выводятся в stdout - в этом примере логика снятия предыдущего выделения закомментирована, поэтому вторая операция поиска, как видно на рисунке, выделила вторую строку «def», не сняв предыдущее выделение (раскомментируйте эту строку в сценарии, чтобы операция поиска снимала предыдущее выделение):
C:\...\PP4E\Gui\Tour> python simpleedit.py simpleedit.py
PP4E scrolledtext
14.4
25.4
Операция сохранения выводит имеющийся в библиотеке tkinter стандартный диалог сохранения, который выглядит естественным в каждой из платформ. На рис. 9.20 изображен этот диалог в Windows 7. Операция поиска тоже выводит стандартный диалог для ввода строки поиска (рис. 9.21); в полноценном редакторе можно было бы сохранить эту строку для повторного поиска (что мы и сделаем в главе 11, в реа-
Рис. 9.19. Сценарий simpleedit в действии
Рис. 9.20. Диалог сохранения файла в Windows
Рис. 9.21. Диалог поиска
лизации редактора PyEdit). Для реализации операции завершения повторно был использован компонент кнопки Quit, реализованный нами в главе 8, - этот код гарантирует, что приложение не может быть завершено без подтверждения.
Использование буфера обмена
Помимо операций с виджетом Text в примере 9.11 применяются функции из библиотеки tkinter доступа к буферу обмена для реализации операций удаления и вставки текста. В совокупности эти операции позволяют перемещать текст в файле (вырезать в одном месте и вставлять в другом). Используемый ими буфер обмена служит местом для временного хранения данных - удаленный текст помещается в буфер при вырезании и извлекается оттуда при вставке. Если все происходит в одной программе, нет смысла вырезать строку текста вместо того чтобы просто сохранить ее в обычной переменной Python. Но буфер обмена является значительно более широким понятием.
Буфер обмена, используемый в этом сценарии, является общесистемным хранилищем, совместно используемым всеми программами, выполняющимися в компьютере. Поэтому его можно использовать для передачи данных между приложениями, в числе которых могут быть такие, которые понятия не имеют о библиотеке tkinter. Например, текст, вырезанный или скопированный в Microsoft Word, можно вставлять в окно SimpleEditor, а текст, вырезанный в SimpleEditor, можно вставить в Блокнот (можете попробовать). Используя буфер обмена для реализации операций вырезания и вставки, SimpleEditor автоматически интегрируется с оконной системой в целом. Кроме того, буфер обмена используется не одним только виджетом Text - его можно применять для вырезания и вставки графических объектов в виджете Canvas (обсуждается далее).
Базовый интерфейс к буферу обмена в библиотеке tkinter, использованный в сценарии из примера 9.11, выглядит так:
self.clipboard_clear() # очистить буфер
self.clipboard_append(text) # сохранить строку текста
text = self. selection_get(selection=’ CLIPBOARD’ ) # получить содержимое, если есть
Все эти вызовы доступны в виде методов, наследуемых всеми объектами виджетов tkinter, потому что они разрабатывались как глобальные. Использованное в этом сценарии выделение CLIPBOARD может применяться на всех платформах (существует еще выделение PRIMARY, но обычно им можно пользоваться только в X Window, поэтому мы здесь его не рассматриваем). Обратите внимание, что в случае неудачи метод selection_get возбуждает исключение TclError - данный сценарий ее просто игнорирует и прерывает операцию вставки, но в дальнейшем мы реализуем более удачное решение.
Композиция и наследование
В данном примере класс SimpleEditor использует наследование для расширения ScrolledText дополнительными кнопками и методами обработчиков. Как мы уже видели, допускается также прикреплять (встраивать) объекты графического интерфейса, реализованные как компоненты, подобно ScrolledText. Модель, когда компоненты прикрепляются, обычно называется композицией; существует мнение, что она проще для понимания и реже приводит к конфликту имен, чем расширение наследованием.
Чтобы дать представление о различиях между этими двумя подходами, ниже приводится набросок программного кода, в котором объект ScrolledText прикрепляется к объекту SimpleEditor. Измененные строки выделены в нем полужирным шрифтом (полную реализацию приема композиции можно найти в файле simpleedit2.py, в пакете с примерами). В основном задача состоит в передаче правильных родительских элементов и добавлении атрибута st каждый раз, когда требуется получить доступ к методам виджета Text:
class SimpleEditor(Frame):
def __init__(self, parent=None, file=None):
Frame.__init__(self, parent)
self.pack() frm = Frame(self)
frm.pack(fill=X)
Button(frm, text=’Save’, command=self.onSave).pack(side=LEFT)
...часть программного кода опущена...
Quitter(frm).pack(side=LEFT)
self.st = ScrolledText(self, file=file) # прикрепить, не подкласс self.st.text.config(font=('courier', 9, 'normal'))
def onSave(self):
filename = asksaveasfilename() if filename:
alltext = self.st.gettext() # доступ через атрибут
open(filename, ‘w’).write(alltext)
def onCut(self):
text = self.st.text.get(SEL_FIRST, SEL_LAST)
self.st.text.delete(SEL_FIRST, SEL_LAST)
...часть программного кода опущена...
При таком подходе нет необходимости наследовать класс Frame (виджеты можно было прикреплять непосредственно к родителю), а принадлежность к фреймам позволяет весь этот пакет встраивать и настраивать целиком. Если запустить этот сценарий, он создаст схожее окно. Что лучше - композиция или наследование - судить вам. При правильном использовании классов графического интерфейса они будут работать в любом режиме.
«Простым» он назван обоснованно: PyEdit (забегая вперед)
Наконец, прежде чем вы зарегистрируете в системном реестре редактор SimpleEditor как средство по умолчанию для просмотра текстовых файлов, я должен заметить, что хотя он и обладает всеми основными функциями, но является в некотором роде урезанной версией (в действительности - прототипом) редактора PyEdit, с которым мы познакомимся в главе 11. Вы можете захотеть уже сейчас посмотреть пример с PyEdit, если вы ищете более полную реализацию обработки текста на основе библиотеки tkinter. В нем мы будем также использовать более сложные операции с текстом, такие как откат (undo) и возврат (redo) ввода, поиск с учетом регистра символов, поиск во внешних файлах и многие другие. Виджет Text обладает такой мощью, что трудно продемонстрировать диапазон его возможностей в программном коде меньшего объема, чем тот, который приведен в программе PyEdit.
Я должен также отметить, что реализация SimpleEditor не только ограничена в своих возможностях, но и весьма небрежна - многие граничные случаи проходят без проверки и вызывают неперехватываемые исключения, которые не приводят к завершению графического интерфейса, но и не обрабатываются и не выводят сообщений. Даже о перехваченных ошибках пользователю не сообщается (например, при попытке вставки, когда буфер обмена пуст). Обязательно посмотрите PyEdit, как пример более устойчивой и полной реализации операций, введенных в SimpleEditor.
Юникод и виджет Text
Я уже говорил выше, что текстовое содержимое в виджете Text всегда представлено в виде строки. Однако в Python 3.X существует два типа строк: str - для представления текста Юникода, и bytes - для представления строк байтов. Кроме того, текст Юникода может сохраняться в файлы в различных кодировках. Оказывается, что оба эти фактора могут оказывать влияние на порядок использования виджета Text в Python 3.X.
В двух словах: виджет Text и другие виджеты, так или иначе связанные с текстом, такие как Entry, поддерживают возможность отображения национальных наборов символов для обоих типов строк, str и bytes, но, чтобы обеспечить поддержку самого широкого диапазона символов, при работе с виджетом необходимо использовать декодированный текст Юникода типа str. В этом разделе мы по полочкам разберем механизмы работы с текстом в библиотеке tkinter, чтобы объяснить причину.
Типы строк в виджете Text
Вы могли обратить внимание на это или нет, но во всех предыдущих примерах текстовое содержимое было представлено в виде строк str -либо жестко определенных в тексте сценариев, либо извлекаемых из простых текстовых файлов и сохраняемых в них, что предполагает использование кодировки по умолчанию для текущей платформы. Однако технически виджет Text позволяет вставлять строки обоих типов, и str и bytes:
>>> from tkinter import Text >>> T = Text()
>>> T.insert('1.0', 'spam') # вставить строку типа str
>>> T.insert('end', b'eggs') # вставить строку типа bytes
>>> T.pack() # теперь виджет отображает строку “spameggs”
>>> T.get('1.0', 'end') # извлечь содержимое
‘spameggs\n’
Возможность вставки текста в виде строки типа bytes может пригодиться при просмотре различных видов текста Юникода, особенно когда имя кодировки не известно. Например, текст, полученный из Интернета (скажем, во вложении к электронному письму или полученный по FTP), может быть представлен в любой кодировке - сохранение его в файлах в двоичном режиме и отображение, как строк типа bytes в виджете Text, может показаться обходным решением проблемы использования кодировок в наших сценариях.
Однако, к большому сожалению, виджет Text возвращает свое содержимое только в виде строки str независимо от того, строки какого типа в него вставлялись, str или bytes, - в любом случае мы получаем обратно уже декодированный текст Юникода:
>>> T = Text()
>>> T.insert('1.0', 'Textfileline1\n')
>>> T.insert('end', 'Textfileline2\n') # при вставке str, содержимое - str >>> T.get('1.0', 'end') # вызывать pack() не обязательно,
‘Textfileline1\nTextfileline2\n\n’ # чтобы обратиться к get()
>>> T = Text()
>>> T.insert('1.0', b'Bytesfileline1\r\n') # для bytes содержимое тоже str!
>>> T.insert('end', b'Bytesfileline2\r\n') # а \r отображается, как пробел >>> T.get('1.0', 'end')
‘Bytesfileline1\r\nBytesfileline2\r\n\n’
Фактически мы получаем содержимое виджета в виде строки типа str, даже если мы вставляли строки обоих типов, str и bytes, с единственным символом \n, добавленным в конец, как показано в первом примере в этом разделе. Ниже приводится более полная иллюстрация:
>>> T = Text()
>>> T.insert('1.0', 'Textfileline1\n')
>>> T.insert('end', 'Textfileline2\n') # добавлены две строки str
>>> T.insert('1.0', b'Bytesfileline1\r\n') # \n добавляется для любого типа
>>> T.insert('end', b'Bytesfileline2\r\n') # pack() отображает 4 строки текста
>>> T.get('1.0', 'end')
‘Bytesfileline1\r\nTextfileline1\nTextfileline2\nBytesfileline2\r\n\n’
>>>
>>> print(T.get('1.0', 'end'))
Bytesfileline1
Textfileline1
Textfileline2
Bytesfileline2
Это упрощает обработку текста содержимого после его извлечения: мы можем интерпретировать его, как строку типа str независимо от того, строки каких типов вставлялись. Однако эта же особенность усложняет обработку текстовых данных с точки зрения Юникода: мы не можем сохранить возвращаемую строку str в двоичный файл, потому что операция записи в двоичном режиме ожидает получить строку типа bytes. Нам необходимо будет либо закодировать строку в тип bytes вручную, либо открыть файл в текстовом режиме и уповать на то, что строка str сможет быть закодирована. В любом случае нам необходимо будет знать имя применяемой кодировки; положиться на кодировку по умолчанию для данной платформы; в крайнем случае, сделать какие-либо предположения и надеяться, что они оправдаются; или запросить кодировку у пользователя.
Иными словами, даже при том, что библиотека tkinter позволяет вставлять текст в неизвестной кодировке, как строку типа bytes, и просматривать его, тот факт, что содержимое возвращается в виде строки str, в общем случае означает необходимость знать, как кодировать текст при сохранении, чтобы удовлетворить интерфейс файлов в Python 3.X. Кроме того, так как строки bytes, вставляемые в виджеты Text, также должны быть декодируемыми согласно ограничениям поддержки Юникода в библиотеке Tk, будет лучше, если мы будем декодировать текст в строки str самостоятельно, чтобы обеспечить более широкую поддержку Юникода. Чтобы убедиться в правоте этих слов, нам необходимо совершить короткий экскурс в страну Юникода.
Текст Юникода в строках
Причина всех этих сложностей заключается, конечно же, в том, что в мире Юникода мы не можем больше думать о «тексте», не задавая вопрос «какого он вида». Вообще текст может быть закодирован с использованием самых разных схем кодирования. В языке Python это обстоятельство неразрывно связано со строками str и может иметь отношение к строкам bytes, если они содержат кодированный текст. Строки str Юникода в языке Python - это просто строки, но вам придется принимать во внимание кодировки при записи строк в файлы и чтении их из файлов, а также при передаче их в библиотеки, накладывающие ограничения на кодирование текста.
Мы не будем рассматривать здесь проблемы кодирования Юникода во всех подробностях (подробное описание вы найдете в книге «Изучаем Python», а краткое упоминание о том, какое значение это имеет для файлов, - в главе 4), но коротко рассмотрим некоторые положения, чтобы увидеть - какое отношение они имеют к виджетам Text. Для начала вам следует запомнить, что проблемы с текстом ASCII не возникают лишь потому, что ASCII является подмножеством большинства схем кодирования Юникода. Однако данные, выходящие за диапазон представления 7-битовых символов ASCII, в разных схемах кодирования могут быть представлены разными байтами.
Например, следующие строки байтов должны декодироваться с использованием кодировки Latin-1 - попытка использовать кодировку по умолчанию или явно указанную кодировку, не соответствующую строке байтов, будет терпеть неудачу:
>>> b = b'A\xc4B\xe4C' # эти байты - текст в кодировке latin-1
>>> b
b’A\xc4B\xe4C’
>>> s = b.decode('utf8')
UnicodeDecodeError: ‘utf8’ codec can’t decode bytes in position 1-2: invalid dat...
>>> s = b.decode()
UnicodeDecodeError: ‘utf8’ codec can’t decode bytes in position 1-2: invalid dat...
>>> s = b.decode('latin1')
>>> s
‘ AABaC’
Декодировав байты в строку Юникода, вы сможете «преобразовать» ее обратно в строку байтов с применением различных кодировок. В действительности при этом будет произведено преобразование в альтернативное двоичное представление, которое позднее мы опять сможем декодировать в строку - по существу строка Юникода не относится к «типу Юникод», к нему могут относиться только двоичные данные:
>>> s.encode('latin-1')
b’A\xc4B\xe4C’
>>> s.encode('utf-8')
b’A\xc3\x84B\xc3\xa4C’
>>> s.encode('utf-16')
b’\xff\xfeA\x00\xc4\x00B\x00\xe4\x00C\x00’
>>> s.encode('ascii')
UnicodeEncodeError: ‘ascii’ codec can’t encode character ‘\xc4’ in position 1: o...
Обратите внимание на последнюю операцию в этом примере: кодируемая строка должна быть совместима с используемой схемой кодирования, в противном случае будет возбуждено исключение. В данном случае диапазон ASCII оказался слишком узким для представления символов, полученных в результате декодирования из байтов в кодировке Latin-1. То есть вы можете преобразовать строку в различные (совместимые) двоичные представления, но тем не менее для декодирования этих данных обратно в строку в общем случае вам необходимо знать кодировку, использовавшуюся при кодировании:
>>> s.encode('utf-16').decode('utf-16')
‘ AABaC’
>>> s.encode('latin-1').decode('latin-1')
‘AABaC’
>>> s.encode('latin-1').decode('utf-8')
UnicodeDecodeError: ‘utf8’ codec can’t decode bytes in position 1-2: invalid dat... >>> s.encode('utf-8').decode('latin-1')
UnicodeEncodeError: ‘charmap’ codec can’t encode character ‘\xc3’ in position 2:...
Снова обратите внимание на последнюю операцию. Технически кодирование кодовых пунктов (символов) Юникода в байты UTF-8 и обратное их декодирование с применением кодировки Latin-1 не возбуждает ошибку, но попытка вывести результат приводит к исключению: с точки зрения функции вывода он является зашифрованным мусором. Чтобы обеспечить необходимую точность, необходимо знать, какая кодировка применялась при создании двоичного представления:
>>> s ‘ AABaC’
>>> x = s.encode('utf-8').decode('utf-8') # OK: кодировки совпадают
>>> x ‘ AABaC’
>>> x = s.encode('latin-1').decode('latin-1') # можно использовать любые >>> x # совместимые кодировки
‘ AABaC’
>>> x = s.encode('utf-8').decode('latin-1') # декодирование выполняется,
>>> x # но получается мусор
UnicodeEncodeError: ‘charmap’ codec can’t encode character ‘\xc3’ in position 2:...
>>> len(s), len(x) # уже не та же самая строка
(5, 7)
>>> s.encode('utf-8') # не те же самые кодовые пункты
b’A\xc3\x84B\xc3\xa4C’
>>> x.encode('utf-8')
b’A\xc3\x83\xc2\x84B\xc3\x83\xc2\xa4C’
>>> s.encode('latin-1')
b’A\xc4B\xe4C’
>>> x.encode('latin-1')
b’A\xc3\x84B\xc3\xa4C’
Самое интересное, что после применения несовпадающих кодировок иногда оригинальную строку все еще можно восстановить. Если снова закодировать полученный мусор в кодировку Latin-1 (8-битовые символы) и затем декодировать с применением корректной кодировки, оригинальная строка будет восстановлена (благодаря этому обстоятельству в некоторых ситуациях вы можете все поправить, если при первой попытке данные были декодированы неправильно):
>>> s ‘ AABaC’
>>> s.encode('utf-8').decode('latin-1')
UnicodeEncodeError: ‘charmap’ codec can’t encode character ‘\xc3’ in position 2:... >>> s.encode('utf-8').decode('latin-1').encode('latin-1')
b’A\xc3\x84B\xc3\xa4C’
>>> s.encode('utf-8').decode('latin-1').encode('latin-1').decode('utf-8')
‘AABaC’
>>> s.encode('utf-8').decode('latin-1').encode('latin-1').decode('utf-8') == s
True
С другой стороны, для декодирования данных можно использовать различные кодировки, при условии, что они совместимы с кодировкой данных - при использовании кодировок ASCII, UTF-8 и Latin-1, например, операция декодирования текста ASCII возвращает один и тот же результат:
>>> 'spam'.encode('utf8').decode('latin1')
‘spam’
>>> 'spam'.encode('latin1').decode('ascii')
‘spam’
Важно помнить, что декодированная строка никак не зависит от кодировки, с применением которой она была получена. После декодирования понятие кодировки не может применяться к строке - она является обычной последовательностью символов Юникода («кодовых пунктов»). Таким образом, заботиться о кодировках необходимо только в точках передачи данных между программой и файлами:
>>> s ‘AABaC’
>>> s.encode('utf-16').decode('utf-16') == s.encode('latin-1').decode('latin-1')
True
Текст Юникода в файлах
Те же правила действуют и для текстовых файлов, потому что строки Юникода сохраняются в файлах в виде декодированных байтов. При записи мы можем закодировать строку с применением любой кодировки, совместимой с символами, имеющимися в строке. Однако при чтении необходимо заранее знать кодировку или использовать ту, которая декодирует байты в те же самые символы:
>>> open('ldata', 'w', encoding='latin-1').write(s) # сохранить в latin-1 5
>>> open('udata', 'w', encoding='utf-8').write(s) # сохранить в utf-8 5
>>> open('ldata', 'r', encoding='latin-1').read() # OK: корректное имя ‘ AABaC’
>>> open('udata', 'r', encoding='utf-8').read()
‘ AABaC’
>>> open('ldata', 'r').read() # иначе может вернуть ошибку
‘ AABaC’
>>> open('udata', 'r').read()
UnicodeEncodeError: ‘charmap’ codec can’t encode characters in position 2-3: cha... >>> open('ldata', 'r', encoding='utf-8').read()
UnicodeDecodeError: ‘utf8’ codec can’t decode bytes in position 1-2: invalid dat... >>> open('udata', 'r', encoding='latin-1').read()
UnicodeEncodeError: ‘charmap’ codec can’t encode character ‘\xc3’ in position 2:...
Напротив, при чтении из файлов в двоичном режиме попытка декодировать данные в строку Юникода не производится. Они благополучно будут прочитаны независимо от того, в каком режиме были записаны эти данные - в текстовом, с автоматическим кодированием строк str (как в предыдущем интерактивном сеансе), или в двоичном, в виде строк bytes, закодированных вручную:
>>> open('ldata', 'rb').read()
b’A\xc4B\xe4C’
>>> open('udata', 'rb').read()
b’A\xc3\x84B\xc3\xa4C’
>>> open('sdata', 'wb').write( s.encode('utf-16') ) # вернет число: 12 >>> open('sdata', 'rb').read()
b’\xff\xfeA\x00\xc4\x00B\x00\xe4\x00C\x00’
Юникод и виджет Text
Все вышеизложенное имеет прямое отношение к виджету Text: если файл открывается в двоичном режиме, отпадает необходимость беспокоиться о кодировках - библиотека tkinter будет интерпретировать данные в соответствии с нашими ожиданиями, по крайней мере, для этих двух кодировок:
>>> from tkinter import Text >>> t = Text()
>>> t.insert('1.0', open('ldata', 'rb').read())
>>> t.pack() # строка появится в графическом интерфейсе >>> t.get('1.0', 'end')
‘ AABaC\n’
>>>
>>> t = Text()
>>> t.insert('1.0', open('udata', 'rb').read())
>>> t.pack() # строка появится в графическом интерфейсе
>>> t.get('1.0', 'end')
‘ AABaC\n’
Виджет действует, как если бы мы передали ему строку str, извлеченную в текстовом режиме, но при использовании текстового режима нам необходимо передать интерпретатору Python имя кодировки - операции чтения будут терпеть неудачу при использовании кодировки, несовместимой с данными, хранящимися в файле:
>>> t = Text()
>>> t.insert('1.0', open('ldata', 'r', encoding='latin-1').read())
>>> t.pack()
>>> t.get('1.0', 'end')
‘ AABaC\n’
>>>
>>> t = Text()
>>> t.insert('1.0', open('udata', 'r', encoding='utf-8').read())
>>> t.pack()
>>> t.get('1.0', 'end')
‘ AABaC\n’
В любом случае содержимое, извлеченное из файла, всегда будет представлено строкой Юникода str, поэтому двоичный режим оказывает влияние только на операцию чтения. Но нам тем не менее необходимо знать кодировку, сохраняем мы данные непосредственно в текстовом режиме или выполняем запись в двоичном режиме после кодирования вручную:
>>> c = t.get('1.0', 'end')
>>> c # содержимое - строка str
‘ AABaC\n’
>>> open('cdata', 'wb').write(c) # binary mode needs bytes TypeError: must be bytes or buffer, not str
>>> open('cdata', 'w', encoding='latin-1').write(c) # каждая операция записи >>> open('cdata', 'rb').read() # возвращает число 6
b’A\xc4B\xe4C\r\n’
>>> open('cdata', 'w', encoding='utf-8').write(c) # другие байты в файле >>> open('cdata', 'rb').read()
b’A\xc3\x84B\xc3\xa4C\r\n’
>>> open('cdata', 'w', encoding='utf-16').write(c)
>>> open('cdata', 'rb').read() b’\xff\xfeA\x00\xc4\x00B\x00\xe4\x00C\x00\r\x00\n\x00’
>>> open('cdata', 'wb').write( c.encode('latin-1') ) # закодировать вручную >>> open('cdata', 'rb').read() # то же, но с \r в Win
b’A\xc4B\xe4C\n’
>>> open('cdata', 'w', encoding='ascii').write(c) # должна быть совместимой UnicodeEncodeError: ‘ascii’ codec can’t encode character ‘\xc4’ in position 1: o
Обратите внимание на последнюю операцию в этом примере: операция кодирования вручную и записи в файл может терпеть неудачу, если данные не смогут быть закодированы с применением указанной кодировки. Когда такое случается, программа, вероятно, должна восстановиться после исключения и попробовать альтернативную кодировку -это особенно справедливо для платформ, где в качестве кодировки по умолчанию используется ASCII.
Проблемы обработки текста, представленного байтами
Правила, описанные в предыдущем разделе, могут показаться слишком сложными, но в действительности все они сводятся к следующему:
• Кодировку, используемую в операциях чтения/записи в текстовом режиме и при кодировании/декодировании вручную, необходимо знать только при работе со строками, кодировка символов в которых не совпадает с кодировкой, используемой на текущей платформе по умолчанию.
• Для записи в новые файлы можно использовать практически любую кодировку, при условии, что она может применяться к символам в строках, но при чтении необходимо указывать кодировку, совместимую с имеющимися двоичными данными.
• При чтении текста в двоичном режиме для отображения в виджете знать кодировку необязательно, но виджет Text всегда возвращает содержимое в виде строки str, поэтому, чтобы закодировать его перед сохранением в файл, необходимо знать кодировку.
Так почему бы всегда не загружать текст для отображения в виджете Text в двоичном режиме? Хотя чтение из файлов в двоичном режиме и кажется решением проблем кодирования, тем не менее передача текста библиотеке tkinter в виде строк bytes вместо str в действительности просто перекладывает проблему кодирования на библиотеку Tk, которая налагает собственные ограничения.
В частности, может показаться, что открывая входные файлы в двоичном режиме, мы обеспечиваем возможность отображения произвольных текстовых данных, но у этого решения есть два недостатка:
• Оно снимает бремя выбора кодировки с нашего сценария и перекладывает его на библиотеку Tk. Библиотеке все равно придется решать, как отображать полученные байты, и может так случиться, что она не будет поддерживать какие-то необходимые кодировки.
• Оно позволяет открывать и просматривать файлы, которые по своей природе не являются текстовыми, сводя к нулю некоторые из преимуществ, предлагаемых проверками, выполняемыми при декодировании текста.
Первый пункт является, пожалуй, наиболее важным. Поэкспериментировав в Windows, я выяснил, что библиотека Tk корректно обрабатывает строки bytes в кодировках ASCII, UTF-8 и Latin-1, но не справилась с кодировкой UTF-16 и другими, такими как CP500. Однако все эти строки отображаются корректно, когда перед передачей библиотеке Tk двоичные данные декодируются в строку str. В программах, предназначенных для использования по всему миру, такая расширенная поддержка становится жизненно значимой. Если у вас есть возможность определить кодировку или запросить ее у пользователя, то для отображения и сохранения текста в файлы лучше использовать строки str.
Независимо от того, передаете вы текстовые данные в виде строк типа str или bytes, графические интерфейсы на основе библиотеки tkinter подчиняются ограничениям, накладываемым библиотекой Tk и языком программирования Tcl, а также всеми приемами использования библиотеки tkinter в языке Python, которая служит интерфейсом к библиотеке Tk. Например:
• Tcl, внутренний язык реализации библиотеки Tk, хранит строки в кодировке UTF-8 и требует, чтобы строки передавались через его прикладной интерфейс на языке C именно в этом формате.
• Tcl пытается преобразовать строки байтов, используя кодировку UTF-8, и в целом поддерживает преобразования с использованием кодировок, определяемых региональными настройками системы и кодировки Latin-1, как последнего средства.
• Реализация библиотеки tkinter на языке Python передает строки bytes языку Tcl без промежуточных преобразований, но при использовании строк Юникода типа str копируются объекты Юникода языка Tcl.
• Библиотека Tk унаследовала все ограничения языка Tcl, связанные с Юникодом, и добавляет свои ограничения, связанные с выбором шрифта для отображения.
Иными словами, графические интерфейсы, отображающие текст с использованием средств библиотеки tkinter, находятся во власти нескольких слоев программного обеспечения, расположенных выше и ниже программного кода на языке Python. Но, как бы то ни было, Юникод достаточно полно поддерживается виджетом Text из библиотеки Tk при использовании строк типа str, хотя это не относится к строкам bytes. Как вы уже наверняка заметили, обсуждение этой проблемы быстро начинает обрастать техническими деталями, поэтому мы не будем исследовать ее дальше в этой книге - дополнительные сведения о tkinter, Tk и Tcl и интерфейсах между ними ищите в Сети или в других источниках информации.
Другие проблемы двоичного режима
Даже в ситуациях, когда достаточно использовать файлы, открытые в двоичном режиме, обойти проблемы с кодировками оказывается сложнее, чем можно было бы подумать. При записи в двоичном режиме нам всегда придется проявлять осторожность, чтобы прочитанные данные позднее были корректно записаны в файл, - при чтении в двоичном режиме строки в Windows будут завершаться последовательностью символов \r\n и было бы нежелательно, чтобы при записи в текстовом режиме они превращались в последовательности \r\r\n. Кроме того, между строками типа str и bytes в tkinter существует еще одно отличие. Строки str, прочитанные из файла в текстовом режиме, выводятся в графическом интерфейсе в ожидаемом виде, и в Windows символы конца строки отображаются должным образом:
C:\...\PP4E\Gui\Tour> python >>> from tkinter import *
>>> T = Text() # str в текстовом режиме
>>> T.insert('1.0', open('jack.txt').read()) # кодировка по умолчанию >>> T.pack() # нормально отображается в GUI
>>> T.get('1.0', 'end')[:75]
‘000) All work and no play makes Jack a dull boy.\n001) All work and no pla’
Однако если передать в графический интерфейс строку bytes, прочитанную из файла в двоичном режиме, в Windows она будет выглядеть на экране довольно странно - в конце каждой строки текста появится лишний пробел, соответствующий символу \r, который не отсекается при чтении из файлов в двоичном режиме:
C:\...\PP4E\Gui\Tour> python >>> from tkinter import *
>>> T = Text() # bytes в двоичном режиме
>>> T.insert('1.0', open('jack.txt', 'rb').read()) # без декодирования >>> T.pack() # появились пробелы в конце
>>> T.get('1.0', 'end')[:75] # строк!
‘000) All work and no play makes Jack a dull boy.\r\n001) All work and no pl’
При использовании строк bytes, чтобы обеспечить отображение произвольного текста в ожидаемом виде, нам дополнительно придется вручную удалять символы \r в концах строк. Вследствие этого предполагается, что комбинация \r\n не имеет какого-то специального значения в схеме кодирования текста, хотя, если эта последовательность в данных не будет означать конец строки, такие данные с большой долей вероятности будут вызывать другие проблемы при отображении. В следующем фрагменте реализовано удаление лишних пробелов в концах строк - входной файл открывается в двоичном режиме, и при чтении недекодированных байтов вручную удаляются символы \r:
C:\...\PP4E\Gui\Tour> python
>>> from tkinter import * # используется тип bytes, удаляются символы \r
>>> T = Text()
>>> data = open('jack.txt', 'rb').read()
>>> data = data.replace(b'\r\n', b'\n')
>>> T.insert('1.0', data)
>>> T.pack()
>>> T.get('1.0', 'end')[:75]
‘000) All work and no play makes Jack a dull boy.\n001) All work and no pla’
Чтобы позднее сохранить это содержимое, можно либо добавить символы \r, при выполнении в Windows, вручную выполнить кодирование в тип bytes и сохранить данные в двоичном режиме; либо открыть файл в текстовом режиме, чтобы объект файла сам добавил символы \r, если это необходимо, выполнил кодирование и записал содержимое строки str. Второй путь, вероятно, более простой, так как он не требует беспокоиться о различиях между платформами.
Однако в любом случае мы вновь оказываемся лицом к лицу с проблемой кодирования - мы можем либо положиться на кодировку по умолчанию для текущей платформы, либо получить имя кодировки из пользовательского интерфейса. В следующем фрагменте, например, объект текстового файла сам преобразует символы конца строки и применяет кодировку по умолчанию для текущей платформы. Если бы было необходимо обеспечить поддержку произвольного текста Юникода или работоспособность сценария на платформах, где кодировка по умолчанию не соответствует отображаемым символам, мы могли бы передавать имя кодировки явно (операция извлечения среза, используемая здесь, имеет тот же эффект, что и применение спецификатора позиции «end-1c» в библиотеке Tk):
...продолжение предыдущего сеанса...
>>> content = T.get('1.0', 'end')[:-1] # отбросит \n в конце
>>> open('copyjack.txt', 'w').write(content) # кодировка по умолчанию 12500 # текстовый режи* в*Win добавит \n
>>> ^Z
C:\...\PP4E\Gui\Tour> fc jack.txt copyjack.txt
Comparing files jack.txt and COPYJACK.TXT FC: no differences encountered
Поддержка Юникода в PyEdit (забегая вперед)
Пример использования поддержки Юникода в виджете Text мы увидим в главе 11, когда будем разбирать реализацию приложения PyEdit. В действительности под поддержкой Юникода подразумевается лишь поддержка различных кодировок при работе с файлами, открытыми в текстовом режиме, - как только текст окажется в памяти, его обработка всегда выполняется в терминах типа str, потому что библиотека tkinter возвращает содержимое именно в таком виде. Чтобы обеспечить поддержку Юникода, редактор PyEdit открывает файлы для чтения и записи в текстовом режиме, явно указывая кодировку, если это возможно, а двоичный режим использует только как последнее средство. Благодаря этому отпадает необходимость полагаться на ограниченную поддержку Юникода в библиотеке Tk, предусмотренную для отображения строк байтов.
Для этого редактор PyEdit реализует возможность получения имен кодировок из самых разных источников и позволяет пользователям указывать, какие из них желательно использовать. Кодировка может быть получена в результате диалога с пользователем, из параметров настройки в конфигурационных файлах, из настроек системы по умолчанию, из значения, сохраненного ранее в файле, и даже из внутренних значений в программе (полученных в результате анализа заголовков сообщений электронной почты, например). Все эти источники опробуются друг за другом, пока не встретится первая подходящая кодировка, при этом в некоторых ситуациях может потребоваться ограничиться единственным источником.
Эту реализацию вы увидите а главе 14. Честно признаться, версия редактора PyEdit в этом издании изначально предусматривала чтение и запись в файлы в текстовом режиме с использованием кодировки по умолчанию. Я не предполагал заострять внимание на поддержке Юникода в PyEdit, пока не столкнулся с необходимостью поддержки самых разнообразных кодировок, существующих в Интернете, при подготовке примера PyMailGUI. Если вы считаете, что строки стали намного сложнее, чем могли бы быть, то это скорее всего, потому, что спектр ваших представлений остается слишком узким.
Более сложные операции с текстом и тегами
Но достаточно разговоров о сложностях Юникода - вернемся к программированию графических интерфейсов. Помимо указания позиции, теги виджета Text могут также использоваться для форматирования и выполнения операций как над всеми символами подстроки, так и над всеми подстроками, помещенными в тег. Эта особенность составляет значительную часть мощи, предоставляемой виджетом Text:
• Теги имеют атрибуты форматирования, позволяющие определять цвет, шрифт, ширину табуляции, величину межстрочных интервалов и параметры выравнивания. Они могут применяться одновременно к нескольким фрагментам текста, если связать их с тегом и выполнить настройку тега с помощью метода tag_config, который очень напоминает общий метод config виджетов.
• Теги позволяют выполнять привязку событий, что дает возможность реализовать, например, гиперссылки в виджете Text: щелчок на тексте вызывает обработчик события его тега. Привязка событий к тегам осуществляется с помощью метода tag_bind, во многом подобного уже знакомому общему методу bind виджетов.
С помощью тегов можно отображать текст с различными настройками внутри одного и того же виджета Text; например, ко всему виджету Text можно применить один шрифт, а к тексту в тегах - другие шрифты. Кроме того, виджет Text позволяет встраивать другие виджеты в заданное индексом место (они интерпретируются, как отдельный символ), а также графические изображения.
Пример 9.12 иллюстрирует основы применения сразу всех этих дополнительных возможностей и воспроизводит интерфейс, изображенный на рис. 9.22. Этот сценарий применяет форматирование и выполняет привязку событий к трем подстрокам, помеченным тегами, выводит текст с помощью двух разных комбинаций шрифтов и цветов, а также встраивает графическое изображение и кнопку. Двойной щелчок мышью на любой из подстрок, заключенных в теги (или на встроенной кнопке), генерирует событие, которое выводит в поток stdout сообщение «Got tag event».
Пример 9.12. PP4E\Gui\Towr\texttags.py
"демонстрация дополнительных возможностей тегов и виджета Text”
from tkinter import * root = Tk()
def hello(event): print(‘Got tag event’)
# создать и настроить виджет Text text = Text()
text.config(font=(‘courier’, 15, ‘normal’)) # общий шрифт
text.config(width=20, height=12) text.pack(expand=YES, fill=BOTH)
text.insert(END, ‘This is\n\nthe meaning\n\nof life.\n\n’) # вставить 6 строк
# встроить окна и изображения
btn = Button(text, text=’Spam’, command=lambda: hello(0)) # встроить кнопку btn.pack()
text.window_create(END, window=btn) # встроить изображение
text.insert(END, ‘\n\n’)
img = PhotoImage(file=’../gifs/PythonPowered.gif’) text.image_create(END, image=img)
# применить теги к подстрокам
text.tag_add(‘demo’, ‘1.5’, ‘1.7’) # добавить ‘is’ в тег
text.tag_add(‘demo’, ‘3.0’, ‘3.3’) # добавить ‘the’ в тег
text.tag_add(‘demo’, ‘5.3’, ‘5.7’) # добавить ‘life’ в тег
text.tag_config(‘demo’, background=’purple’) # изменить цвета тега
text.tag_config(‘demo’, foreground=’white’) # называются не bg/fg
text.tag_config(‘demo’, font=(‘times’, 16, ‘underline’)) # изменить шрифт тега text.tag_bind(‘demo’, ‘’, hello) # привязать события
root.mainloop()
Рис. 9.22. Теги виджета Text в действии
Такие средства встраивания и работы с тегами тегов можно в конечном итоге использовать для отображения веб-страницы. А стандартный модуль html.parser анализа разметки HTML может помочь с автоматизацией построения графического интерфейса веб-страницы. Как можно догадаться, виджет Text предоставляет больше возможностей программирования графических интерфейсов, чем позволяет описать объем книги. За подробностями о возможностях, предоставляемых тегами и виджетом Text, обращайтесь к другим справочникам по библиотекам Tk и tkinter. А сейчас начнутся занятия в художественной школе.
Виджет Canvas
Что касается графики, то виджет Canvas (холст) из tkinter является самым свободным по форме инструментом в этой библиотеке. Он позволяет рисовать фигуры, динамически перемещать объекты и располагать другие виджеты. Холст основан на структурированной модели графического объекта: все, что изображается на холсте, может обрабатываться как объект. Можно опуститься до уровня обработки пикселей, а можно оперировать более крупными объектами, такими как фигуры, графические изображения и встроенные виджеты. Все это делает холст достаточно мощным инструментом, как для использования в простых графических редакторах, так и в полноценных программах визуализации и воспроизведения анимации.
Базовые операции с виджетом Canvas
Холсты повсеместно используются во многих нетривиальных графических интерфейсах, и далее в этой книге можно будет увидеть более крупные примеры использования холстов, в программах PyDraw, PyPhoto, PyView, PyClock и PyTree. А сейчас сразу займемся примером, в котором демонстрируются основы его применения. В примере 9.13 используется большинство основных методов создания изображений на холсте.
Пример 9.13. PP4E\Gui\Tour\canvas1.py
"демонстрация основных возможностей холста”
from tkinter import *
canvas = Canvas(width=525, height=300, bg=’white’) # 0,0 - верхний левый угол
canvas.pack(expand=YES, fill=BOTH) # рост вниз и вправо
canvas.create_line(100, 100, 200, 200) # fromX, fromY, toX, toY
canvas.create_line(100, 200, 200, 300) # рисование фигур
for i in range(1, 20, 2):
canvas.create_line(0, i, 50, i)
canvas.create_oval(10, 10, 200, 200, width=2, fill=’blue’) canvas.create_arc(200, 200, 300, 100)
canvas.create_rectangle(200, 200, 300, 300, width=5, fill=’red’) canvas.create_line(0, 300, 150, 150, width=10, fill=’green’)
photo=PhotoImage(file=’../gifs/ora-lp4e.gif’)
canvas.create_image(325, 25, image=photo, anchor=NW) # встроить изображение
widget = Label(canvas, text=’Spam’, fg=’white’, bg=’black’) widget.pack()
canvas.create_window(100, 100, window=widget) # встроить виджет
canvas.create_text(100, 280, text=’Ham’) # нарисовать текст
mainloop()
Запущенный сценарий создаст окно, изображенное на рис. 9.23. Ранее уже было показано, как поместить на холст графическое изображение и установить соответствующие ему размеры холста (раздел «Изображения» в конце главы 8). Этот сценарий изображает также фигуры, текст и даже встроенный виджет Label. Его окно пока ограничивается только отображением - чуть ниже будет показано, как добавить обработчики событий, дающие пользователю возможность взаимодействовать с отображаемыми элементами.
Рис. 9.23. Окно сценария canvas1 с изображениями объектов
Программирование виджета Canvas
Холсты просты в использовании, при этом они имеют свою систему координат, определяют уникальные методы рисования и именуют объекты с помощью идентификаторов или тегов. Данный раздел знакомит с этими базовыми понятиями холста.
Координаты
Все элементы, отображаемые на холсте, представляют собой отдельные объекты, которые в действительности не являются виджетами. Если внимательно изучить сценарий canvas1, можно заметить, что холсты создаются и прикрепляются к родительскому контейнеру, как и любые другие виджеты tkinter. Однако к предметам, изображаемым на холсте, это не относится: фигуры, графические изображения и другие элементы располагаются и перемещаются по холсту с помощью координат, идентификаторов и тегов. При этом координаты являются наиболее фундаментальной составляющей модели холста.
Холст определяет собственную систему координат (X,Y) для своей области отображения; X обозначает горизонтальную ось, Y - вертикальную. По умолчанию координаты измеряются в пикселях (точках); левый верхний угол холста имеет координаты (0,0), а координаты X и Y возрастают вправо и вниз соответственно. Чтобы нарисовать или разместить объект на холсте, необходимо указать одну или более пар координат (X,Y), определяющих абсолютные местоположения на холсте. Такой способ отличается от ограничений, использовавшихся до сих пор для прикрепления виджетов, но он позволяет управлять графической структурой с очень большой точностью и поддерживает более свободные по форме технологии, например, анимацию.44
Создание объектов
Холст позволяет рисовать и отображать простые фигуры, такие как линии, овалы, прямоугольники, дуги и многоугольники. Кроме того, имеется возможность встраивать текст, графические изображения и другие виджеты tkinter, такие как метки и кнопки. В сценарии canvas1 продемонстрированы все основные методы конструирования графических объектов - каждому из них передается один или более наборов координат (X,Y), определяющих координаты нового объекта, начальные и конечные точки или противоположные углы рамки, содержащей фигуру:
id = canvas.create_line(fromX, fromY, toX, toY) # начало, конец отрезка прямой
id = canvas.create_oval(fromX, fromY, toX, toY) # противоположные углы овала
id = canvas.create_arc( fromX, fromY, toX, toY) # противоположные углы дуги
id = canvas.create_rectangle(fromX, fromY, toX, toY) # противоположные углы
# прямоугольника
В других методах рисования указывается только одна пара координат (X,Y), определяющая координаты левого верхнего угла объекта:
id = canvas.create_image(250, 0, image=photo, anchor=NW) # встроить изображ. id = canvas.create_window(100, 100, window=widget) # встроить виджет
id = canvas.create_text(100, 280, text=’Ham’) # нарисовать текст
Холст также предоставляет метод create_polygon, принимающий произвольное множество аргументов координат, определяющих точки, соединенные линиями. Его удобно использовать для рисования произвольных фигур, образованных отрезками прямых линий.
Помимо координат большинство методов рисования позволяет определять обычные параметры настройки, такие как ширина границы (width), цвет заливки (fill), цвет границы (outline) и так далее. У некоторых типов объектов есть собственные уникальные параметры настройки; например, для линий можно указать форму необязательной стрелки, а текст, виджеты и изображения можно привязывать по направлениям сторон света (что похоже на параметр anchor менеджера компоновки, но в действительности определяет точку объекта, помещаемую в координаты (X,Y), указанные в вызове метода create; NW, например, помещает в координаты (X,Y) левый верхний угол объекта).
Важнее всего, вероятно, отметить здесь, что библиотека tkinter по большей части сама выполняет «черновую» работу - рисуя фигуры, вы только указываете координаты, а библиотека сама вычерчивает и отображает их. Если вам когда-либо приходилось заниматься графикой на низком уровне, то вы оцените разницу.
Идентификаторы объектов и операции
Сценарий canvas1 не использует тот факт, что у каждого помещаемого на холст объекта есть идентификатор. Его возвращает метод create_, который рисует или встраивает объект (в примерах предыдущего раздела он был представлен переменной id). Этот идентификатор можно впоследствии передавать другим методам, чтобы переместить объект в новые координаты, установить параметры его настройки, удалить с холста, поднять или опустить относительно других перекрывающихся объектов и так далее
Например, метод move холста может принимать идентификатор объекта и смещения (не координаты) X и Y, и перемещать объект согласно заданному смещению:
canvas.move(objectIdOrTag, offsetX, offsetY) # переместить объект(ы)
Если при этом объект смещается за пределы холста, он просто обрезается (не показывается). К объектам можно также применять другие часто используемые операции:
canvas.delete(objectIdOrTag) # удалить объект(ы) с холста
canvas.tkraise(objectIdOrTag) # поднять объект(ы) вверх
canvas.lower(objectIdOrTag) # опустить объект(ы) вниз
canvas.itemconfig(objectIdOrTag, fill=’red’) # залить объект(ы) красным цветом
Обратите внимание на имя tkraise - слово raise является в языке Python зарезервированным. Заметьте также, что для настройки объектов, изображенных на холсте, после их создания используется метод itemconfig; метод config применяется для изменения параметров самого холста. Однако главное, что нужно отметить, - это возможность обработать сразу весь графический объект, поскольку библиотека tkinter оперирует структурированными объектами - не нужно поднимать и перерисовывать каждый пиксель вручную, чтобы осуществить перемещение или подъем объекта.
Теги объектов в виджете Canvas
Однако холсты способны предложить еще более мощные возможности, чем мы видели до сих пор. Помимо идентификаторов объектов существуют теги. Тег - создаваемое программистом имя, с которым можно связать ряд отображаемых объектов и применить ту или иную операцию сразу ко всей группе. Пометка объектов тегами в виджете Canvas по крайней мере по духу сходна с пометкой тегами подстрок в виджете Text, рассматривавшемся в предшествующем разделе. В общих чертах методы холста принимают идентификатор отдельного объекта или имя тега.
Например, можно переместить целую группу отображаемых объектов, привязав их к одному и тому же тегу и передав его методу move холста. Именно по этой причине метод move принимает смещения, а не координаты - получая тег, он перемещает каждый ассоциированный с этим тегом объект на указанные смещения (X,Y); если бы метод принимал абсолютные координаты, все связанные с тегом объекты могли бы оказаться в одном и том же месте друг над другом.
Чтобы связать объект с тегом, нужно указать имя тега в параметре tag метода, отображающего объект, или вызвать метод холста addtag_ withtag(tag, objectIdOrTag) (или родственный ему). Например:
canvas.create_oval(x1, y1, x2, y2, fill=’red’, tag=’bubbles’) canvas.create_oval(x3, y3, x4, y4, fill=’red’, tag=’bubbles’) objectId = canvas.create_oval(x5, y5, x6, y6, fill=’red’) canvas.addtag_withtag(‘bubbles’, objectId) canvas.move(‘bubbles’, diffx, diffy)
Эти инструкции создают три овала и перемещают их одновременно, благодаря связыванию с одним и тем же именем тега. У многих объектов может быть один и тот же тег, многие теги могут ссылаться на один и тот же объект, и каждый тег можно настраивать и обрабатывать независимо.
Как и виджет Text, виджет Canvas имеет теги с предопределенными именами: тег all ссылается на все объекты, имеющиеся на холсте, а current ссылается на тот объект, который находится под указателем мыши. Можно не только запрашивать идентификатор объекта под указателем мыши, но и осуществлять поиск объектов с помощью методов find_ холста: например, метод canvas.find_closest(X,Y) возвращает кортеж, первый элемент которого содержит идентификатор объекта, находящегося ближе всего к точке с указанными координатами, - это удобно, когда уже есть координаты, полученные в обработчике события, сгенерированного щелчком мыши.
К представлению о тегах холста мы вернемся снова в более позднем примере из этой главы (если вам нужны подробности прямо сейчас, можете посмотреть сценарии воспроизведения анимации ближе к концу). Холсты поддерживают другие операции и параметры, для рассказа о которых здесь недостаточно места (например, метод холста postscript позволяет сохранить холст в файле в формате PostScript). Дополнительные сведения можно найти в примерах, имеющихся далее в книге, таких как PyDraw, а полный список параметров объекта холста можно найти в справочниках по библиотеке Tk или tkinter.
Прокрутка холстов
Однако одна из операций над холстами настолько часто используется в практике, что действительно заслуживает внимания. Как демонстрирует пример 9.14, полосы прокрутки можно перекрестно связывать с холстами, используя те же протоколы, которые ранее использовались для добавления их к виджетам Listbox и Text, но с некоторыми особыми требованиями.
Пример 9.14. PP4E\Gui\Tour\scrolledcanvas.py
"простой компонент холста с вертикальной прокруткой”
from tkinter import *
class ScrolledCanvas(Frame):
def __init__(self, parent=None, color=’brown’):
Frame.__init__(self, parent)
self.pack(expand=YES, fill=BOTH) # сделать растягиваемым
canv = Canvas(self, bg=color, relief=SUNKEN)
canv.config(width=300, height=200) # размер видимой области
canv.config(scrollregion=(0, 0, 300, 1000)) # углы холста
canv.config(highlightthickness=0) # без рамки
sbar = Scrollbar(self)
sbar.config(command=canv.yview) # связать sbar и canv canv.config(yscrollcommand=sbar.set) # сдвиг одного = сдвиг другого sbar.pack(side=RIGHT, fill=Y) # первым добавлен - посл. обрезан
canv.pack(side=LEFT, expand=YES, fill=BOTH) # canv обрезается первым
self.fillContent(canv)
canv.bind(‘’, self.onDoubleClick) # установить обр. события self.canvas = canv
def fillContent(self, canv): # переопределить при
for i in range(10): # наследовании
canv.create_text(150, 50+(i*100), text=’spam’+str(i),fill=’beige’)
def onDoubleClick(self, event): # переопределить при
print(event.x, event.y) # наследовании
print(self.canvas.canvasx(event.x), self.canvas.canvasy(event.y))
if __name__ == ‘__main__’: ScrolledCanvas().mainloop()
Этот сценарий создает окно, изображенное на рис. 9.24. Оно аналогично предыдущим примерам реализации прокрутки, но в модели прокрутки холстов есть две особенности:
Размеры области прокрутки и видимой области
Можно указать размер видимой области холста, но при этом обязательно следует указать и размер прокручиваемой области холста в целом. Видимая область - это область, отображаемая в окне, размер которой может изменяться при изменении размеров окна. Прокручиваемая область в общем случае должна быть больше - она включает все содержимое холста, из которого только часть отображается в видимой области. Операция прокрутки как бы перемещает окно просмотра по прокручиваемой области холста.
Отображение координат в области просмотра в абсолютные координаты.
Кроме того, нужно устанавливать соответствие между координатами видимой области и координатами всего холста, если холст больше, чем видимая его область. Если холст поддерживает возможность прокрутки, он почти всегда больше видимой его области, и в этих случаях часто требуется вычислять это соответствие. В некоторых случаях необходимость в таком вычислении отсутствует, потому что виджеты, встраиваемые в холст, самостоятельно откликаются на действия пользователей (например, кнопки в примере PyPhoto, в главе 11). Однако если пользователь взаимодействует непосредственно с холстом (например, в графическом редакторе), преобразование из системы координат видимой области в систему координат всего холста становится насущной необходимостью.
Рис. 9.24. Сценарий scrolledcanvas в действии
Размеры определяются как параметры настройки. Размер видимой области определяется с помощью параметров холста width и height. Чтобы определить общий размер холста, в параметре scrollregion следует передать кортеж с четырьмя координатами верхнего левого и нижнего правого углов холста. Если размер видимой области не указан, используется размер по умолчанию. Если не задан параметр scrollregion, он принимается по умолчанию равным размеру видимой области. При этом полоса прокрутки становится бесполезной, так как видимая область в этом случае вмещает весь холст целиком.
Пересчет координат осуществляется несколько более сложным образом. Если прокручиваемая видимая область холста оказывается меньше, чем холст в целом, то координаты (X,Y), возвращаемые в объектах событий, представляют собой координаты в видимой области, а не в холсте в целом. Обычно требуется перевести координаты события в координаты холста, для чего они передаются методам canvasx и can-vasy прежде чем их можно будет использовать для обработки объектов.
Например, если запустить сценарий реализации прокручиваемого холста и посмотреть на сообщения, выводимые при выполнении двойных щелчков мышью, можно заметить, что координаты события всегда относятся к видимой области, а не холсту в целом:
C:\...\PP4E\Gui\Tour> python scrolledcanvas.py
2 0 координаты x,y события, если холст прокручен доверху
2.0 0.0 координаты х,у холста - те же, если нет пикселей границы
150 106
150.0 106.0
299 197
299.0 197.0
3 2 координаты x,y события, если холст прокручен донизу
3.0 802.0 координаты x,y холста - координата y отличается
296 192
296.0 992.0
152 97 при прокрутке в среднюю часть холста
152.0 599.0
16 187
16.0 689.0
Здесь отображаемая координата X видимой области холста всегда совпадает с координатой X всего холста, поскольку видимая область и холст имеют одинаковую ширину 300 пикселей (из-за автоматической установки границ могло бы появиться расхождение в два пикселя, если бы не значение highlightthickness, установленное в сценарии). Обратите внимание, что после щелчка на вертикальной полосе прокрутки отображаемая координата Y видимой области становится отличной от координаты Y холста. Без преобразования координат значение координаты Y события неверно указывало бы на место, находящееся на холсте значительно выше.
В большинстве примеров с холстами в этой книге выполнять такое преобразование не требуется - координаты (0,0) всегда соответствует левому верхнему углу холста, в котором происходит щелчок мышью, но лишь потому, что эти холсты не поддерживают прокрутку. Пример холста с двумя полосами прокрутки, горизонтальной и вертикальной, вы найдете в следующем разделе. Программа PyTree, что приводится далее в этой книге, также демонстрирует похожий холст, но при этом она динамически изменяет размеры области прокрутки при отображении новых деревьев.
Как правило, если холст поддерживает возможность прокрутки, то в обработчиках событий, учитывающих позицию, необходимо преобразовывать координаты события в действительные координаты холста. Для некоторых обработчиков это не требуется, если они привязаны к отдельным объектам или виджетам на холсте, а не к самому холсту; в следующих двух разделах показано, что происходит в этом случае.
Холсты с поддержкой прокрутки и миниатюр изображений
В конце главы 8 мы рассматривали коллекцию сценариев, отображающих миниатюры всех изображений, хранящихся в каталоге. Там отмечалось, что поддержка прокрутки является важным требованием для больших коллекций изображений. Теперь, когда мы знаем, как объединять холсты и полосы прокрутки, можно, наконец, задействовать их для реализации этого крайне необходимого расширения и закончить реализацию инструмента просмотра изображений, начатую в главе 8 (ну, или почти закончить).
Пример 9.15 представляет собой измененную версию последнего примера из предыдущей главы, которая отображает миниатюры в холсте с прокруткой. Описание особенностей функционирования сценария, а также модуля ImageTk (необходим для создания миниатюр и отображения изображений в формате JPEG), импортируемого из сторонней библиотеки Python Imaging Library (PIL), смотрите в предыдущей главе.
Фактически, чтобы полностью понять реализацию примера 9.15, необходимо также вспомнить пример 8.45, поскольку здесь мы повторно используем инструменты создания миниатюр и просмотра изображений из этого модуля. Здесь мы просто добавляем холст, позиционируем кнопки фиксированного размера по абсолютным координатам в холсте и вычисляем размеры прокручиваемой области, используя понятия, обозначенные в предыдущем разделе. Наличие горизонтальной и вертикальной полос прокрутки обеспечивает возможность свободного перемещения по всему холсту с кнопками независимо от их количества.
Пример 9.15. PP4E\Gui\PIL\viewer_thumbs_scrolled.py
расширенная версия сценария просмотра изображений: отображает миниатюры на кнопках фиксированного размера, чтобы обеспечить равномерное их размещение, и добавляет возможность прокрутки при просмотре больших коллекций изображений, отображая миниатюры в виджете Canvas с полосами прокрутки; требует наличия библиотеки PIL для отображения изображений в таких форматах, как JPEG, и повторно использует инструменты создания миниатюр и просмотра единственного изображения из сценария viewer_thumbs.py; предостережение/что сделать: можно также реализовать возможность прокрутки при отображении единственного изображения, если его размеры оказываются больше размеров экрана, которое сейчас обрезается в Windows; более полная версия представлена в виде приложения PyPhoto в главе 11;
import sys, math
from tkinter import *
from PIL.ImageTk import PhotoImage
from viewer_thumbs import makeThumbs, ViewOne
def viewer(imgdir, kind=Toplevel, numcols=None, height=300, width=300):
использует кнопки фиксированного размера и холст с возможностью прокрутки; определяет размер области прокрутки (всего холста) и располагает миниатюры по абсолютным координатам x,y холста; предупреждение: предполагается, что все миниатюры имеют одинаковые размеры
win = kind()
win.title(‘Simple viewer: ‘ + imgdir)
quit = Button(win, text=’Quit’, command=win.quit, bg=’beige’) quit.pack(side=BOTTOM, fill=X)
canvas = Canvas(win, borderwidth=0) vbar = Scrollbar(win)
hbar = Scrollbar(win, orient=’horizontal’)
vbar.pack(side=RIGHT, fill=Y) # прикрепить холст после полос прокрутки hbar.pack(side=BOTTOM, fill=X) # чтобы он обрезался первым canvas.pack(side=TOP, fill=BOTH, expand=YES)
vbar.config(command=canvas.yview) # обработчики событий
hbar.config(command=canvas.xview) # перемещения полос прокрутки
canvas.config(yscrollcommand=vbar.set) # обработчики событий
canvas.config(xscrollcommand=hbar.set) # прокрутки холста
canvas.config(height=height, width=width) # начальные размеры видимой
# области, изменяемой при
# изменении размеров окна
thumbs = makeThumbs(imgdir) # [(imgfile, imgobj)]
numthumbs = len(thumbs) if not numcols:
numcols = int(math.ceil(math.sqrt(numthumbs))) # фиксиров. или N x N numrows = int(math.ceil(numthumbs / numcols)) # истинное деление в 3.x
linksize = max(thumbs[0][1].size) # (ширина, высота)
fullsize = (0, 0, # верхний левый угол X,Y
(linksize * numcols), (linksize * numrows) ) # нижний правый угол X,Y canvas.config(scrollregion=fullsize) # размер области
# прокрутки
rowpos = 0 savephotos = [] while thumbs:
thumbsrow, thumbs = thumbs[:numcols], thumbs[numcols:] colpos = 0
for (imgfile, imgobj) in thumbsrow: photo = PhotoImage(imgobj) link = Button(canvas, image=photo)
handler = lambda savefile=imgfile: ViewOne(imgdir, savefile) link.config(command=handler, width=linksize, height=linksize) link.pack(side=LEFT, expand=YES) canvas.create_window(colpos, rowpos, anchor=NW,
window=link, width=linksize, height=linksize) colpos += linksize savephotos.append(photo) rowpos += linksize return win, savephotos
if __name__ == ‘__main__’:
imgdir = ‘images’ if len(sys.argv) < 2 else sys.argv[1]
main, save = viewer(imgdir, kind=Tk)
main.mainloop()
Чтобы увидеть эту программу в действии, убедитесь, что у вас установлено расширение PIL, как описывается в главе 8, и запустите сценарий из командной строки, передав ему имя каталога с изображениями в виде аргумента:
...\PP4E\Gui\PIL> viewer_thumbs_scrolled.py C:\Users\mark\temp\101MSDCF
Как и прежде, щелчок на миниатюре открывает соответствующее полноразмерное изображение в новом окне. На рис. 9.25 изображено окно сценария при просмотре каталога с большим количеством цифровых фотографий. При первом запуске сценарий тратит значительное время на подготовку кэша с миниатюрами, зато последующие запуски выполняются быстро.
Можно также просто запустить сценарий без аргументов из командной строки щелчком на ярлыке файла или из среды IDLE. В этом случае он отобразит содержимое подкаталога с примерами изображений в дереве примеров для книги, как показано на рис. 9.26.
Еще о прокрутке изображений: PyPhoto (забегая вперед)
Несмотря на все эволюционные изменения, сценарий отображения миниатюр с прокруткой из примера 9.15 все еще имеет одно ограничение: изображения, размеры которых превышают размеры физического экрана, просто обрезаются при отображении в Windows. Этот недостаток наиболее очевидно проявляется при открытии больших цифровых фотографий, таких как на рис. 9.25. Кроме того, сценарий не позволяет изменять размеры уже открытых изображений, открывать другие ка-
Рис. 9.25. Сценарий отображения коллекции миниатюр с прокруткой
Рис. 9.26. Отображение каталога с изображениями по умолчанию
талоги и так далее. Это довольно упрощенная демонстрация приемов программирования холста.
В главе 11 мы узнаем, как решить все эти проблемы, когда встретимся с программой PyPhoto. Эта программа добавляет возможность прокрутки и в окно просмотра полноразмерного изображения. Кроме того, она позволяет изменять размеры изображения, поддерживает возможность сохранения изображений в файлы и открытия других каталогов в процессе выполнения. При этом в основе PyPhoto лежат те же приемы, которые были продемонстрированы в простом сценарии, представленном здесь, а также реализация генератора миниатюр, написанная в предыдущей главе. Как и простой текстовый редактор, демонстрировавшийся выше в этой главе, данная реализация является, по сути, прототипом более полнофункциональной программы PyPhoto, которую мы рассмотрим в главе 11. Оставайтесь с нами до волнующего финала истории развития PyPhoto (или, если ожидание для вас слишком томительно, шагайте вперед прямо сейчас).
Продолжая тему этой главы, обратите внимание, что операции просмотра изображений в примере 9.15 ассоциированы со встроенными виджетами кнопок, а не с самим холстом. Фактически холст здесь является не более, чем инструментом отображения. Чтобы увидеть, как обогатить его собственными событиями, перейдем к следующему разделу.
События холстов
Подобно виджетам Text и Listbox виджет Canvas не имеет параметра настройки command для назначения обработчика событий. Вместо этого программы, содержащие холсты, обычно используют другие виджеты (такие как кнопки с миниатюрами в примере 9.15) или низкоуровневый метод bind, чтобы установить обработчики щелчков мышью, нажатий клавиш и других событий (как в примере 9.14 реализации холста с прокруткой). Пример 9.16 берет за основу последний подход и демонстрирует, как привязать события самого холста, чтобы реализовать некоторые наиболее типичные операции рисования.
Пример 9.16. PP4E\Gui\Tour\canvasDraw.py
реализует возможность рисования эластичных фигур на холсте при перемещении указателя мыши с нажатой правой кнопкой; версии этого сценария, дополненные тегами и анимацией, вы найдете в файлах canvasDraw_tags*.py
from tkinter import * trace = False
class CanvasEventsDemo:
def __init__(self, parent=None):
canvas = Canvas(width=300, height=300, bg=’beige’) canvas.pack()
canvas.bind(‘’, self.onStart) # щелчок canvas.bind(‘’, self.onGrow) # и вытягивание canvas.bind(‘’, self.onClear) # удалить все canvas.bind(‘’, self.onMove) # перемещать последнюю self.canvas = canvas
self.drawn = None
self.kinds = [canvas.create_oval, canvas.create_rectangle]
def onStart(self, event):
self.shape = self.kinds[0]
self.kinds = self.kinds[1:] + self.kinds[:1] # начало вытягивания self.start = event self.drawn = None
def onGrow(self, event): # удалить и перерисовать
canvas = event.widget if self.drawn: canvas.delete(self.drawn)
objectId = self.shape(self.start.x, self.start.y, event.x, event.y) if trace: print(objectId) self.drawn = objectId
def onClear(self, event):
event.widget.delete(‘all’) # использовать тег all
def onMove(self, event):
if self.drawn: # передвинуть в позицию
if trace: print(self.drawn) # щелчка
canvas = event.widget
diffX, diffY = (event.x - self.start.x), (event.y - self.start.y) canvas.move(self.drawn, diffX, diffY) self.start = event
if __name__ == ‘__main__’:
CanvasEventsDemo()
mainloop()
Этот сценарий перехватывает и обрабатывает три действия, выполняемые мышью:
Очистка холста
Чтобы удалить все имеющееся на холсте, сценарий привязывает событие двойного щелчка левой кнопкой к методу delete холста с тегом all - встроенным тегом, который автоматически ассоциируется с каждым объектом на экране. Обратите внимание, что доступ к виджету холста, на котором выполнен щелчок, осуществляется через объект события, передаваемый обработчику (он также доступен через self.canvas).
Вытягивание фигур
При нажатии левой кнопки мыши и перетаскивании (перемещении при нажатой кнопке) создается прямоугольник или овал. Этот прием часто называется вытягиванием фигуры - фигура увеличивается и сжимается как резиновая, и окончательный ее размер и положение определяются позицией указателя мыши, где будет отпущена кнопка мыши.
Чтобы выполнить такую работу с помощью tkinter, нужно всякий раз, когда возникает событие перетаскивания, стирать старую фигуру и рисовать новую. Обе операции, удаления и рисования, выполняются настолько быстро, что возникает эффект эластичного вытягивания. Конечно, чтобы начертить фигуру в соответствии с текущим положением указателя мыши, нужна начальная точка, а чтобы удалить фигуру перед тем, как вычерчивать новую, нужно запоминать идентификатор объекта, нарисованного последним. Здесь участвуют два события: исходное событие нажатия кнопки сохраняет начальные координаты (точнее, объект события нажатия кнопки, который содержит начальные координаты), а события перемещения указателя мыши стирают прежнюю фигуру и рисуют новую от начальных координат до новых координат мыши, сохраняя идентификатор нового объекта для операции стирания в следующем событии.
Перемещение объектов
При щелчке правой кнопкой мыши (кнопкой 3) сценарий сразу перемещает объект, нарисованный последним, в то место, где произведен щелчок. Аргумент события event дает координаты (X,Y) щелчка, из которых вычитаются начальные координаты последнего нарисованного объекта, чтобы получить смещения (X,Y), передаваемые методу move холста (напомню, что метод move ожидает получить смещения, а не координаты). Не следует забывать о необходимости сначала пересчитать координаты события, если холст прокручен.
В итоге после взаимодействия с пользователем получается окно, подобное изображенному на рис. 9.27. При вытягивании объектов сценарий поочередно вычерчивает овалы и прямоугольники. Установите в сценарии глобальную переменную trace и вы увидите в stdout идентификаторы новых объектов, вычерчиваемых при вытягивании и перемещении. Этот снимок экрана получен после вытягивания и перемещения нескольких объектов, что невозможно понять, только глядя на снимок -запустите пример на своем компьютере, чтобы лучше ощутить выполняемые им операции.
Привязка событий к конкретным элементам
Подобно тому как мы делали это для виджета Text, мы можем привязать события к одному или нескольким конкретным объектам, нарисованным в виджете Canvas, с помощью его метода tag_bind. Этот метод принимает в качестве первого аргумента строку с именем тега или идентификатор объекта. Например, можно зарегистрировать отдельные обработчики событий щелчков мыши для каждого нарисованного элемента или для группы нарисованных и помеченных тегом элементов вместо обработчика для холста в целом. В примере 9.17 для иллюстрации выполняется привязка обработчика двойного щелчка как к самому холсту, так и к двум конкретным текстовым элементам на нем. Он создает окно, изображенное на рис. 9.28.
Рис. 9.27. Окно сценария canvasDraw после нескольких вытягиваний и перемещений
Рис. 9.28. Окно сценария canvas-bind
Пример 9.17. PP4E\Gui\Tour\canvas-bind.py
# привязка обработчиков событий к холсту и к элементам на нем from tkinter import *
def onCanvasClick(event):
print(‘Got canvas click’, event.x, event.y, event.widget) def onObjectClick(event):
print(‘Got object click’, event.x, event.y, event.widget, end=’ ‘) print(event.widget.find_closest(event.x, event.y)) # найти ID текстового
# объекта
root = Tk()
canv = Canvas(root, width=100, height=100)
obj1 = canv.create_text(50, 30, text=’Click me one’)
obj2 = canv.create_text(50, 70, text=’Click me two’)
canv.bind(‘’, onCanvasClick) # привязать к самому холсту
canv.tag_bind(obj1, ‘’, onObjectClick) # привязать к элементу canv.tag_bind(obj2, ‘’, onObjectClick) # теги тоже можно canv.pack() # использовать
root.mainloop()
Здесь методу tag_bind передаются идентификаторы объектов, но ему можно также передавать строку с именем тега, что позволяет привязывать обработчики событий к группам элементов. Когда щелчок выполняется в окне сценария за границами текстовых элементов, вызывается обработчик события холста. Когда щелчок выполняется на любом текстовом элементе, вызываются оба обработчика событий - холста и элемента. Ниже показан вывод в stdout после двух щелчков на холсте и одного щелчка на каждом из текстовых элементов. Чтобы получить идентификатор объекта для конкретного текстового элемента, ближайшего к точке щелчка, вызывается метод find_closest холста:
C:\...\PP4E\Gui\Tour> python canvas-bind.py
Got canvas click 3 6 .8217952 щелчки на холсте
Got canvas click 46 52 .8217952
Got object click 51 33 .8217952 (1,) щелчок на первом текстовом элементе
Got canvas click 51 33 .8217952
Got object click 55 69 .8217952 (2,) щелчок на втором текстовом элементе
Got canvas click 55 69 .8217952
Мы еще раз вернемся к идее событий, привязываемых к холсту, в примере PyDraw, в главе 11, где они будут использоваться для реализации полнофункционального графического редактора. Мы также вернемся к сценарию canvasDraw далее в этой главе, где добавим перемещения, основанные на тегах, и простую анимацию с применением инструментов, отмеряющих время, поэтому сделайте закладку на этой странице для справок в дальнейшем. Однако сначала давайте свернем немного в сторону и исследуем другой способ компоновки виджетов в окнах -модель компоновки по сетке.
Сетки
До сих пор мы размещали виджеты на экране, вызывая их метод pack -интерфейс к менеджеру компоновки в библиотеке tkinter. Мы также использовали абсолютные координаты в холстах, которые тоже можно считать своеобразным механизмом компоновки, хотя и не таким высокоуровневым, как методы менеджера компоновки. В данном разделе мы познакомимся с методом grid, наиболее часто используемой альтернативой методу pack. Мы предварительно уже рассматривали эту альтернативу в главе 8, когда обсуждали формы ввода и упорядочивали миниатюры изображений. А сейчас познакомимся с механизмом компоновки по сетке во всей полноте.
Как уже говорилось, действие менеджеров компоновки в библиотеке tkinter заключается в размещении дочерних виджетов внутри контейнера - родительского виджета (обычно родительскими являются элементы Frame или окна верхнего уровня). Когда виджету предлагается присоединить себя вызовом метода pack или grid, в действительности мы предлагаем его родительскому элементу расположить данный виджет среди собратьев. При использовании метода pack определяются некоторые ограничения, и менеджеру компоновки предлагается расположить виджеты соответствующим образом. При использовании метода grid виджеты располагаются в родительском элементе-контейнере по рядам и колонкам, как если бы он был таблицей.
Расположение по сетке является в библиотеке tkinter совершенно отдельной системой управления компоновкой. На момент написания этой книги методы pack и grid взаимно исключают друг друга; при расположении виджетов в одном и том же родительском элементе - в одном контейнере можно использовать либо метод pack, либо метод grid, но не тот и другой одновременно. Это разумно, если усвоить, что менеджеры компоновки выполняют свою работу в родительских элементах, и виджет может размещаться только одним менеджером компоновки.
В чем преимущества размещения по сетке?
Однако это означает, что, по крайней мере, внутри одного контейнера придется выбирать между методами grid и pack и придерживаться этого метода. Зачем тогда нужна сетка? В целом метод grid удобно использовать, когда необходимо расположить несвязанные между собой виджеты по рядам. Сюда относятся табличные интерфейсы и формы - расположение полей ввода по рядам и колонкам ничуть не сложнее, чем организация структуры интерфейса с помощью вложенных фреймов.
Как уже упоминалось в предыдущей главе, формы ввода выглядят привлекательнее, если виджеты располагаются по сетке или во фреймах-рядах с метками фиксированной длины, когда метки и поля ввода находятся на одной горизонтальной линии (как мы уже знаем, использование фреймов-колонок не обеспечивает необходимой точности расположения). Реализация структур интерфейсов на основе сеток и фреймов-рядов требуют примерно одинаковых усилий, тем не менее сетки удобнее, когда отсутствует возможность определить максимальную длину метки. Кроме того, сетки также могут использоваться для создания таблиц более сложного вида, чем формы.
Однако, как мы увидим, на практике метод grid не позволяет заметно уменьшить объем программного кода или его сложность, в сравнении с эквивалентными решениями на основе метода pack, особенно если в графическом интерфейсе должны решаться задачи изменения размеров. Иными словами, выбор между двумя схемами компоновки является в значительной мере вопросом стиля, а не техники.
Основы работы с сеткой: еще раз о формах ввода
Начнем с базовых понятий. В примере 9.18 создается таблица из меток и полей ввода - уже знакомых нам виджетов Label и Entry. Однако в данном случае они располагаются по сетке.
Пример 9.18. PP4E\Gui\Tour\Grid\grid1.py
from tkinter import *
colors = [‘red’, ‘green’, ‘orange’, ‘white’, ‘yellow’, ‘blue’] r = 0
for c in colors:
Label(text=c, relief=RIDGE, width=25).grid(row=r, column=0)
Entry(bg=c, relief=SUNKEN, width=50).grid(row=r, column=1) r += 1
mainloop()
Расположение по сетке заключается в назначении виджетам номеров рядов и колонок, отсчет которых начинается с 0, - библиотека tkinter использует эти координаты, а также размеры виджетов, чтобы расположить виджеты внутри контейнера. Это напоминает действие метода pack, только в данном случае понятия сторон и порядка прикрепления заменяются рядами и колонками.
Если запустить этот сценарий, то он создаст окно, изображенное на рис. 9.29 с данными, введенными в некоторые поля. И снова эта книга не позволяет увидеть цвета, отображаемые в правой части, поэтому вам придется включить свое воображение (или запустить сценарий на своем компьютере).
Рис. 9.29. Менеджер компоновки grid в псевдоживых цветах
В действительности это та же самая классическая структура формы ввода, которую мы видели в предыдущей главе. Метки в левой части описывают данные, которые должны вводиться в поля справа.
Исключительно в целях демонстрации этот сценарий отображает слева названия цветов, в которые окрашены соответствующие поля ввода справа. Табличный вид достигается с помощью следующих строк:
Label(...).grid(row=r, column=0)
Entry(...).grid(row=r, column=1)
С точки зрения контейнера, метка помещается в колонку 0 строки с текущим номером (отсчет начинается с 0), а поле ввода помещается в колонку 1. В итоге система компоновки по сетке автоматически располагает метки и поля ввода в виде двухмерной таблицы, обеспечивая одинаковую высоту рядов и ширину колонок, достаточные для размещения самого большого элемента в каждой колонке.
То есть благодаря размещению виджетов по рядам и колонкам они должным образом выравниваются по обоим направлениям. Использование метода pack с фреймами-рядами позволяет добиться того же эффекта, если метки будут иметь фиксированную длину (как было показано в главе 8), однако сетки точнее отражают табличную структуру интерфейсов, включая формы ввода, а также большие таблицы в целом. Следующий раздел иллюстрирует эти различия в программном коде.
Сравнение методов grid и pack
Настало время сделать некоторые сравнения и противопоставления: пример 9.19 реализует одинаковые расцвеченные формы ввода с помощью методов g rid и pack, чтобы легче было обнаружить различия между двумя подходами.
Пример 9.19. PP4E\Gui\Tour\Grid\grid2.py
добавляет эквивалентное окно, используя фреймы-ряды и метки фиксированной длины; использование фреймов-колонок не обеспечивает точного взаимного расположения виджетов Label и Entry по горизонтали; программный код в обоих случаях имеет одинаковую длину, хотя применение встроенной функции enumerate позволило бы сэкономить 2 строки в реализации компоновки по сетке;
from tkinter import *
colors = [‘red’, ‘green’, ‘orange’, ‘white’, ‘yellow’, ‘blue’] def gridbox(parent):
"компоновка по номерам рядов/колонок в сетке” row = 0
for color in colors:
lab = Label(parent, text=color, relief=RIDGE, width=25)
ent = Entry(parent, bg=color, relief=SUNKEN, width=50)
lab.grid(row=row, column=0)
ent.grid(row=row, column=1)
ent.insert(0, ‘grid’)
row += 1
def packbox(parent):
"фреймы-ряды и метки фиксированной длины” for color in colors:
row = Frame(parent)
lab = Label(row, text=color, relief=RIDGE, width=25)
ent = Entry(row, bg=color, relief=SUNKEN, width=50)
row.pack(side=TOP)
lab.pack(side=LEFT)
ent.pack(side=RIGHT)
ent.insert(0, ‘pack’)
if __name__ == ‘__main__’: root = Tk() gridbox(Toplevel()) packbox(Toplevel())
Button(root, text=’Quit’, command=root.quit).pack() mainloop()
Версия на основе метода pack в этом примере использует фреймы-ряды и метки фиксированной длины (напомню еще раз, что схема с фреймами-колонками не позволяет добиться требуемой точности). Эти две функции создают виджеты меток и полей ввода одинаковым способом, но размещаются они совершенно разными путями:
• При использовании метода pack метки и поля ввода прикрепляются к левому и правому краям с помощью параметров side, и для каждого ряда создается виджет Frame (который прикрепляется к верхнему краю родителя).
• При использовании метода grid каждому виджету назначается положение с помощью параметров row (ряд) и column (колонка) в предполагаемой табличной сетке родителя.
Как мы уже знаем, при использовании метода pack порядок добавления виджетов имеет большое значение: виджет получает остаток стороны родительского контейнера, к которой он прикрепляется (что в данном случае неактуально), и элементы, прикрепляемые первыми, обрезаются последними (метки и самые верхние строки здесь обрезаются последними). При компоновке с помощью метода g rid тот же эффект обрезания достигается благодаря особенностям поведения сетки. Если запустить этот сценарий, он создаст окна, изображенные на рис. 9.30, - по одному окну для каждой схемы размещения.
При внимательном рассмотрении можно заметить, что разница в объеме программного кода, необходимого для каждой схемы, ничтожна, по крайней мере для случая простой формы. Схема на основе метода pack должна создать отдельный виджет Frame для каждого ряда, а схема на основе метода grid должна отслеживать номер текущего ряда.
Фактически обе схемы требуют для реализации одинаковое количество строк программного кода. Однако справедливости ради следует заметить, что реализации обеих схем можно было бы сократить на одну строку, если добавлять метку немедленно, а реализацию на основе метода grid можно было бы сократить еще на две строки, применив встроенную функцию enumerate, чтобы избавиться от необходимости вести счет рядов вручную. Ниже приводится уменьшенная версия функции
gridbox:
def gridbox(parent):
for (row, color) in enumerate(colors):
Label(parent,text=color,relief=RIDGE,width=25).grid(row=row,column=0) ent = Entry(parent, bg=color, relief=SUNKEN, width=50) ent.grid(row=row, column=1) ent.insert(0, ‘grid’)
Оставим дальнейшее уменьшение размеров реализации для тех, кому не чужд спортивный интерес (мы приводим не самую шокирующую реализацию, однако ваше стремление к краткости программного кода совсем не обязательно покажется достижением вашим коллегам!). Независимо от схемы компоновки сложность обеих реализаций выглядит примерно одинаковой. Однако, как будет показано далее, для реализации компоновки по сетке может потребоваться больше программного кода, когда появляется необходимость изменять размеры виджетов вместе с окном.
Рис. 9.30. Эквивалентные окна для схем размещения на основе grid и pack
Сочетание grid и pack
Обратите внимание, что в примере 9.19 каждой функции-конструктору формы передается совершенно новый виджет Toplevel, благодаря чему версии на основе методов grid и pack создают различные окна верхнего уровня. Так как два менеджера компоновки не могут одновременно использоваться в одном родительском окне, необходимо следить за тем, чтобы по недосмотру не смешать их. Пример 9.20 демонстрирует возможность компоновки виджетов с помощью методов pack и grid в одном и том же окне, но только после заключения их в отдельные контейнерные виджеты Frame.
Пример 9.20. PP4E\Gui\Tour\Grid\grid2-same.py
создает формы с применением методов pack и grid в отдельных фреймах в одном и том же окне; методы grid и pack не могут одновременно использоваться в одном родительском контейнере (например, в корневом окне), но могут использоваться в разных фреймах в одном и том же окне;
from tkinter import *
from grid2 import gridbox, packbox
root = Tk()
Label(root, text=’Grid:’).pack() frm = Frame(root, bd=5, relief=RAISED) frm.pack(padx=5, pady=5)
gridbox(frm)
Label(root, text=’Pack:’).pack() frm = Frame(root, bd=5, relief=RAISED) frm.pack(padx=5, pady=5) packbox(frm)
Button(root, text=’Quit’, command=root.quit).pack() mainloop()
Если запустить этот сценарий, получится составное окно с двумя формами идентичного вида (рис. 9.31), но эти два вложенные фрейма в действительности управляются совершенно разными менеджерами компоновки.
C другой стороны, такой программный код, как приводится в примере 9.21, вызывает грубую ошибку, поскольку пытается вызывать методы pack и grid в одном и том же родителе - только один менеджер компоновки может использоваться в каждом отдельном родительском окне.
Пример 9.21. PP4E\Gui\Tour\Grid\grid2-fails.py
ОШИБКА -- методы pack и grid не могут одновременно использоваться в одном и том же родительском контейнере (здесь, корневое окно)
from tkinter import *
from grid2 import gridbox, packbox
root = Tk()
gridbox(root)
packbox(root)
Рис. 9.31. grid и pack в одном окне
Button(root, text=’Quit’, command=root.quit).pack() mainloop()
Этот сценарий передает каждой из функций одного и того же родителя (окно верхнего уровня), пытаясь вывести обе формы в одном окне. На моей машине он полностью подвешивает процесс Python, не выводя вообще никаких окон (в некоторых версиях Windows мне пришлось прибегнуть к CtrL+ALt+DeLete, чтобы уничтожить процесс, в других версиях достаточно было перезапустить программу Командная строка (Command Prompt)).
Комбинирование менеджеров компоновки может представлять сложность, пока с этим не освоишься. Чтобы сделать этот сценарий работоспособным, например, требуется просто изолировать форму с сеткой в собственном родительском контейнере, чтобы оградить его от влияния метода pack, используемого в корневом окне, - как демонстрирует следующая альтернативная реализация, где изменения выделены полужирным шрифтом:
root = Tk() frm = Frame(root)
frm.pack() # это работает
gridbox(frm) # у gridbox должен быть собственный родитель
packbox(root)
Button(root, text=’Quit’, command=root.quit).pack() mainloop()
Еще раз напомню, что в настоящее время внутри одного родителя допускается использовать либо метод pack, либо метод grid, но не тот и другой одновременно. Возможно, в будущем это давнее ограничение будет снято, что, впрочем, маловероятно с учетом различий в схемах двух менеджеров компоновки, но на всякий случай проверьте свою версию Python.
Реализация возможности растягивания виджетов, размещаемых по сетке
А теперь некоторые практические замечания: сетки, которые мы видели до сих пор, имеют фиксированный размер - они не увеличиваются в размере при увеличении размеров содержащего их окна. Пример 9.22 реализует чрезвычайно патриотическую форму ввода с применением обоих методов, grid и pack, но в нем выполняются дополнительные настройки, необходимые, чтобы обеспечить растягивание всех виджетов в обоих окнах вместе со своими окнами.
Пример 9.22. PP4E\Gui\Tour\Grid\grid3.py
"добавляет метку в верхней части окна и возможность растягивания форм”
from tkinter import *
colors = [‘red’, ‘white’, ‘blue’]
def gridbox(root):
Label(root, text=’Grid’).grid(columnspan=2) row = 1
for color in colors:
lab = Label(root, text=color, relief=RIDGE, width=25) ent = Entry(root, bg=color, relief=SUNKEN, width=50) lab.grid(row=row, column=0, sticky=NSEW) ent.grid(row=row, column=1, sticky=NSEW) root.rowconfigure(row, weight=1) row += 1
root.columnconfigure(0, weight=1) root.columnconfigure(1, weight=1)
def packbox(root):
Label(root, text=’Pack’).pack() for color in colors: row = Frame(root)
lab = Label(row, text=color, relief=RIDGE, width=25) ent = Entry(row, bg=color, relief=SUNKEN, width=50) row.pack(side=TOP, expand=YES, fill=BOTH) lab.pack(side=LEFT, expand=YES, fill=BOTH) ent.pack(side=RIGHT, expand=YES, fill=BOTH)
root = Tk()
gridbox(Toplevel(root))
packbox(Toplevel(root))
Button(root, text=’Quit’, command=root.quit).pack() mainloop()
Если запустить этот сценарий, он создаст картину, изображенную на рис. 9.32. Снова создаются отдельные окна для методов pack и grid с полями ввода в правой части, окрашенными в красный, белый и голубой цвета (или для читателей, которые не работают параллельно на компьютере: серый, белый и несколько более темно-серый).
Рис. 9.32. Окна для схем размещения на основе grid и pack до изменения размеров
Однако на этот раз изменение размеров обоих окон с помощью мыши заставляет все встроенные в них метки и поля ввода растягиваться вместе с окнами, как показано на рис. 9.33 (где в поля ввода был введен текст).
Рис. 9.33. Окна для схем размещения на основе grid и pack после изменения размера
В данной реализации при уменьшении размеров окна со схемой размещения на основе метода pack первыми обрезаются виджеты, которые были добавлены последними. В окне со схемой размещения на основе метода grid обрезаются все метки и поля ввода сразу, в отличие от сценария grid2, где демонстрируется поведение по умолчанию (попробуйте у себя на компьютере).
Изменение размеров в сетках
Теперь, когда я показал, что делают эти окна, нужно объяснить, как они это делают. В главе 7 мы узнали, как заставить графические элементы растягиваться при использовании метода pack: мы использовали параметры expand и fill, чтобы увеличить отводимое им пространство и заставить их растягиваться в пределах этого пространства соответственно. Чтобы обеспечить растягивание виджетов, размещаемых с помощью метода grid, требуется использовать другие протоколы. Ряды и колонки становятся растягиваемыми, когда они помечены с помощью параметра weight (вес), а виджеты растягиваются в отведенных им ячейках сетки, когда помечены с помощью параметра sticky (липкий):
Тяжелые ряды и колонки
При использовании метода pack ряды становятся растягиваемыми, если способность к растягиванию придается соответствующему виджету Frame, в результате задания значений параметров expand=YES и fill=BOTH. Для сетки нужно быть несколько конкретнее: чтобы обеспечить полную способность к растягиванию, требуется вызвать метод rowconfigure контейнера сетки для каждого ряда и метод column-configure для каждой колонки. Обоим методам нужно передать параметр weight веса со значением больше нуля, чтобы ряды и колонки стали растягиваемыми. По умолчанию вес принимается равным нулю (что означает отсутствие поддержки растягивания), а контейнером сетки в данном сценарии служит просто окно верхнего уровня. Использование разных весов для разных рядов и колонок заставляет их растягиваться в различных пропорциях.
Липкие виджеты.
При использовании метода pack виджеты растягиваются по горизонтали или вертикали, заполняя отведенное им пространство, если передать этому методу параметр fill, а для позиционирования виджетов в отведенном им пространстве используется параметр anchor. Параметр sticky метода grid играет роли обоих параметров, fill и anchor, метода pack. Чтобы заставить растягиваться виджеты, размещаемые по сетке, можно прилепить их к одному краю отведенной им ячейки (как с помощью параметра anchor) или более чем к одному краю (как с помощью параметра fill). Приклеивать виджеты можно в четырех направлениях - N (север), S (юг), E (восток) и W (запад), а комбинируя эти четыре буквы, можно обеспечить приклеивание сразу к нескольким сторонам. Например, значение W в параметре sticky обеспечит выравнивание виджета по левому краю отведенного ему пространства (подобно anchor=W в методе pack), а значение NS заставит виджет растягиваться по вертикали в выделенном пространстве (подобно fill=Y в методе pack).
Приклеивание виджетов не использовалось в предыдущих примерах, потому что структуру интерфейса образовывали виджеты с постоянными размерами (виджеты были не меньше пространства, отведенного им в ячейке сетки), а изменение размеров вообще не поддерживалось. В данном случае для параметра sticky определено в значение NSEW, чтобы графические элементы растягивались во всех направлениях вместе с отведенными им ячейками.
Различные сочетания весов рядов и колонок, а также значений параметра sticky создают различные эффекты при изменении размеров. Например, если удалить вызов метода columnconfigure из сценария grid3, это приведет к тому, что интерфейс будет растягиваться только в вертикальном направлении. Попробуйте сами поэкспериментировать с этими настройками и посмотреть, к каким эффектам это приведет.
Объединение колонок или рядов
Есть еще одно важное отличие в том, как сценарий grid3 настраивает свои окна. Оба окна - с методами grid и pack - выводят вверху метку, которая размещается по ширине всего окна. В схеме размещения на основе метода pack метка просто прикрепляется к верхнему краю окна в целом (напомню, что параметр side по умолчанию имеет значение TOP):
Label(root, text=’Pack’).pack()
Так как эта метка прикрепляется к верхней части окна раньше, чем фреймы рядов, она, как и требовалось, охватывает весь верх окна. Однако в строгом мире сеток размещение такой метки потребует приложить дополнительные усилия. В первой строке функции, реализующей схему размещения по сетке, это делается следующим образом:
Label(root, text=’Grid’).grid(columnspan=2)
Чтобы виджет охватывал сразу несколько колонок, методу grid передается параметр columnspan с указанием количества охватываемых колонок. В данном случае он указывает, что метка в верхней части окна должна простираться на все окно, охватывая и колонку с метками, и колонку с полями ввода. Если нужно, чтобы графический элемент охватывал несколько рядов, следует передать параметр rowspan. Правильная структура сеток может быть и преимуществом, и недостатком - в зависимости от того, насколько равномерно должны располагаться виджеты; эти два параметра установки диапазонов позволяют при необходимости организовать исключения из правила.
Так какой же менеджер компоновки оказывается здесь победителем? Если имеет значение изменение размеров, как в этом сценарии, то подход на основе сетки оказывается несколько более сложным (в данном примере для реализации размещения по сетке потребовалось написать три дополнительных строки программного кода). С другой стороны, использование функции enumerate снова может изменить общий счет, метод grid остается удобным для создания простых форм, да и ваши схемы компоновки на основе методов grid и pack могут быть другими.
Дополнительная информация о способах компоновки элементов форм ввода приводится в разделе, где обсуждаются утилиты мастеров форм, которые мы реализуем ближе к концу главы 12 и будем использовать в главе 13, при разработке пользовательского интерфейса программы передачи файлов и клиента FTP. Как будет показано далее, автоматизировав процедуру создания привлекательных форм, мы сможем избавить себя от необходимости вникать в детали позднее. Кроме того, в главе 11 мы реализуем менее обычную компоновку формы в диалоге замены программы PyEdit и при размещении полей заголовков электронного письма в примере PyMailGUI, в главе 14.
Создание крупных таблиц с помощью grid
До сих пор мы строили наборы меток и полей ввода из двух колонок. Это типичный вид форм ввода, но менеджер grid в библиотеке tkinter способен организовывать значительно более крупные матрицы. Так, в примере 9.23 создается массив меток, состоящий из пяти строк и четырех колонок, в котором каждая метка просто выводит номер своей строки и колонки (row.col). Если запустить этот сценарий, он создаст окно, изображенное на рис. 9.34.
Пример 9.23. PP4E\Gui\Tour\Grid\grid4.py
# простая двухмерная таблица, в корневом окне Tk по умолчанию
from tkinter import *
for i in range(5): for j in range(4):
lab = Label(text=’%d.%d’ % (i, j), relief=RIDGE) lab.grid(row=i, column=j, sticky=NSEW)
mainloop()
Если вы предположили, что это выглядит как способ программирования электронных таблиц, то вы, вероятно, на правильном пути. Пример 9.24 дает дальнейшее развитие этой мысли и добавляет кнопку, которая выводит в поток stdout текущие значения полей ввода в таблице (обычно в окно консоли).
Рис. 9.34. Массив 5x4 меток с координатами
Пример 9.24. PP4E\Gui\Tour\Grid\grid5.py
# двухмерная таблица полей ввода, корневое окно Tk по умолчанию
from tkinter import * rows = []
for i in range(5): cols = []
for j in range(4):
ent = Entry(relief=RIDGE) ent.grid(row=i, column=j, sticky=NSEW) ent.insert(END, ‘%d.%d’ % (i, j)) cols.append(ent) rows.append(cols)
def onPress():
for row in rows: for col in row:
print(col.get(), end=’ ‘) print()
Button(text=’Fetch’, command=onPress).grid() mainloop()
Если запустить этот сценарий, он создаст окно, изображенное на рис. 9.35, и сохранит все виджеты полей ввода в сетке в двухмерном списке списков. При нажатии кнопки Fetch сценарий выполнит обход списка списков полей ввода, чтобы получить и отобразить все текущие значения в сетке. Ниже приводится вывод после двух нажатий кнопки Fetch - одного перед изменениями в полях ввода и другого после:
C:\...\PP4E\Gui\Tour\Grid> python grid5.py 0.0 0.1 0.2 0.3
1.0 1.1 1.2 1.3
2.0 2.1 2.2 2.3
3.0 3.1 3.2 3.3
Рис. 9.35. Более крупная сетка полей ввода
Теперь, когда мы знаем, как создавать и выполнять обход массивов полей ввода, добавим еще несколько полезных кнопок. В примере 9.25 добавлен еще один ряд, в котором отображаются суммы по столбцам, и кнопки, которые обнуляют все поля и вычисляют суммы по столбцам.
Пример 9.25. PP4E\Gui\Tour\Grid\grid5b.py
# добавляет суммирование по столбцам и очистку полей ввода
from tkinter import *
numrow, numcol = 5, 4
rows = []
for i in range(numrow): cols = []
for j in range(numcol):
ent = Entry(relief=RIDGE) ent.grid(row=i, column=j, sticky=NSEW) ent.insert(END, ‘%d.%d’ % (i, j)) cols.append(ent) rows.append(cols)
sums = []
for i in range(numcol):
lab = Label(text=’?’, relief=SUNKEN) lab.grid(row=numrow, column=i, sticky=NSEW) sums.append(lab)
def onPrint():
for row in rows:
for col in row:
print(col.get(), end=’ ‘) print() print()
def onSum():
tots = [0] * numcol for i in range(numcol): for j in range(numrow):
tots[i] += eval(rows[j][i].get()) # вычислить сумму for i in range(numcol):
sums[i].config(text=str(tots[i])) # отобразить в интерфейсе
def onClear():
for row in rows: for col in row:
col.delete(‘0’, END) col.insert(END, ‘0.0’) for sum in sums:
sum.config(text=’?’)
import sys
Button(text=’Sum’, command=onSum).grid(row=numrow+1, column=0) Button(text=’Print’, command=onPrint).grid(row=numrow+1, column=1) Button(text=’Clear’, command=onClear).grid(row=numrow+1, column=2) Button(text=’Quit’, command=sys.exit).grid(row=numrow+1, column=3) mainloop()
На рис. 9.36 изображено окно этого сценария после вычисления сумм по четырем столбцам чисел. Чтобы получить таблицу другого размера, измените переменные numrow и numcol в начале сценария.
Рис. 9.36. Добавление суммирования по столбцам
И наконец, пример 9.26, реализующий еще одно, последнее расширение, которое оформлено как класс, что обеспечивает возможность повторного его использования. Кроме того, в нем добавлена кнопка загрузки таблицы из файла с данными. Предполагается, что файл содержит строку для каждого ряда данных, а внутри строки колонки разделяются пробельными символами (пробелами или символами табуляции). При загрузке данных из файла автоматически изменяется размер таблицы, чтобы уместить все колонки.
Пример 9.26. PP4E\Gui\Tour\Grid\grid5c.py
#реализация в виде встраиваемого класса
from tkinter import *
from tkinter.filedialog import askopenfilename
from PP4E.Gui.Tour.quitter import Quitter # повт. использование, pack и grid
class SumGrid(Frame):
def __init__(self, parent=None, numrow=5, numcol=5):
Frame.__init__(self, parent)
self.numrow = numrow # я - контейнерный фрейм
self.numcol = numcol # компоновку выполняет вызвавшая пр.,
self.makeWidgets(numrow, numcol) # иначе можно было бы использовать
# единственным способом
def makeWidgets(self, numrow, numcol): self.rows = [] for i in range(numrow): cols = []
for j in range(numcol):
ent = Entry(self, relief=RIDGE) ent.grid(row=i+1, column=j, sticky=NSEW) ent.insert(END, ‘%d.%d’ % (i, j)) cols.append(ent) self.rows.append(cols) self.sums = [] for i in range(numcol):
lab = Label(self, text=’?’, relief=SUNKEN) lab.grid(row=numrow+1, column=i, sticky=NSEW) self.sums.append(lab)
Button(self, text=’Sum’, command=self.onSum).grid(row=0, column=0) Button(self, text=’Print’, command=self.onPrint).grid(row=0, column=1) Button(self, text=’Clear’, command=self.onClear).grid(row=0, column=2) Button(self, text=’Load’, command=self.onLoad).grid(row=0, column=3) Quitter(self).grid(row=0, column=4) # fails: Quitter(self).pack()
def onPrint(self):
for row in self.rows: for col in row:
print(col.get(), end=’ ‘) print() print()
def onSum(self):
tots = [0] * self.numcol for i in range(self.numcol):
for j in range(self.numrow):
tots[i] += eval(self.rows[j][i].get()) # суммировать данные for i in range(self.numcol):
self.sums[i].config(text=str(tots[i]))
def onClear(self):
for row in self.rows: for col in row:
col.delete(‘0’, END) # удалить содержимое
col.insert(END, ‘0.0’) # зарезерв. значение
for sum in self.sums: sum.config(text=’?’)
def onLoad(self):
file = askopenfilename() if file:
for row in self.rows:
for col in row: col.grid_forget() # очистить интерфейс for sum in self.sums: sum.grid_forget()
filelines = open(file, ‘ r’).readlines() # загрузить данные self.numrow = len(filelines) # изменить размер табл.
self.numcol = len(filelines[0].split()) self.makeWidgets(self.numrow, self.numcol)
for (row, line) in enumerate(filelines): # загрузить в интерфейс fields = line.split() for col in range(self.numcol):
self.rows[row][col].delete(‘0’, END) self.rows[row][col].insert(END, fields[col])
if __name__ == ‘__main__’: import sys root = Tk()
root.title(‘Summer Grid’) if len(sys.argv) != 3:
SumGrid(root).pack() # .grid() здесь тоже работает
else:
rows, cols = eval(sys.argv[1]), eval(sys.argv[2])
SumGrid(root, rows, cols).pack() mainloop()
Обратите внимание, что класс SumGrid из этого модуля не применяет к себе самому ни метод grid, ни метод pack. Чтобы дать возможность прикрепления к контейнерам, где есть другие графические элементы, скомпонованные тем или иным способом, он оставляет управление собственной компоновкой неопределенным и требует, чтобы вызывающая программа сама применяла метод pac k или g rid к его экземплярам. Контейнеры могут выбрать любую схему компоновки для своих дочерних элементов, потому что они независимы в своем выборе, но прикрепляемым классам компонентов, предназначенным для использования с любыми менеджерами компоновки, нельзя поручить управлять собой, так как они не могут заранее знать политику своего родителя.
Это довольно длинный пример, в котором нет почти ничего нового в отношении компоновки по сетке или виджетов в целом, поэтому я оставлю его для самостоятельного изучения и просто покажу, что он делает. На рис. 9.37 изображено начальное окно, созданное этим сценарием, после того как была изменена последняя колонка и произведено суммирование - не забудьте включить корневой каталог PP4E дерева с примерами в путь поиска модулей (например, в переменную окружения PYTHONPATH), чтобы сценарий смог импортировать пакет.
Рис. 9.37. Добавлена загрузка данных из файла
По умолчанию класс создает сетку размером 5 на 5, но существует возможность определять другие размерности, как в конструкторе класса, так и в командной строке сценария. При нажатии кнопки Load выводится стандартный диалог выбора файла, с которым мы встречались ранее (рис. 9.38).
Файл данных grid5-data1.txt содержит семь строк и шесть колонок данных:
C:\...\PP4E\Gui\Tour\Grid>type grid5-data1.txt
1 2 3 4 5 6 1 2 3 4 5 6 1 2 3 4 5 6 1 2 3 4 5 6 1 2 3 4 5 6 1 2 3 4 5 6 1 2 3 4 5 6
При загрузке его в наш графический интерфейс соответствующим образом изменяются размеры сетки - класс просто заново выполняет логику создания виджетов после удаления прежних элементов ввода с помощью метода grid_forget. Метод grid_forget отвязывает виджеты в сетке и в результате удаляет их с экрана. Другие способы удаления и перерисовки компонентов графического интерфейса предоставляют методы
Рис. 9.38. Диалог открытия файла в сценарии SumGrid
Рис. 9.39. Файл с данными загружен, отображен и просуммирован
pack_forget виджетов и withdraw окна, которые используются в обработчике события after примеров «будильников» в следующем разделе.
На рис. 9.39 показано, как выглядит окно после операций удаления и перерисовки виджетов, выполненных в результате щелчков на кнопках Load и Sum.
Файл с данными grid5-data2.txt имеет те же размерности, но в двух колонках он содержит не просто числа, а выражения. Так как этот сценарий преобразует значения полей ввода с помощью встроенной функции eval, в полях этой таблицы допускается использовать любые выражения Python, если они могут быть вычислены в области видимости метода onSum:
C:\...\PP4E\Gui\Tour\Grid> type grid5-data2.txt
1 2 3 2*2 5 6 1 3-1 3 2<<1 5 6 1 5%3 3 pow(2,2) 5 6 1 2 3 2**2 5 6 1 2 3 [4,3][0] 5 6 1 {‘a’:2}[‘a’] 3 len(‘abcd’) 5 6 1 abs(-2) 3 eval(‘2+2’) 5 6
При суммировании этих полей выполняется содержащийся в них программный код на языке Python, что иллюстрирует рис. 9.40. Эта особенность может оказаться достаточно мощной. Представьте себе, например, полноценную сетку электронной таблицы - значения полей могут быть «фрагментами» программного кода на языке Python, которые динамически вычисляют значения, вызывают функции из модулей и даже загружают текущие котировки акций из Интернета с помощью инструментов, с которыми мы познакомимся в следующей части книги.
Однако эта особенность может представлять опасность - в поле может содержаться выражение, удаляющее содержимое вашего жесткого диска!45 Если вы не до конца уверены в том, какими могут быть полученные выражения, не используйте функцию eval (осуществляйте преобразование, применяя более ограниченные функции, такие как int и float) или обеспечьте выполнение процесса Python с ограниченными правами доступа к системным компонентам, которые было бы нежелательно подвергать опасности.
Рис. 9.40. Выражения на языке Python в данных и таблице
Конечно, этому сценарию еще очень далеко до настоящей электронной таблицы. Сценарий подсчитывает суммы по колонкам и способен загружать данные из файлов, но ячейки не могут содержать формулы, ссылающиеся на другие ячейки. Однако из-за недостатка места в книге дальнейшие улучшения для достижения этой цели я оставляю читателям в качестве упражнения.
Я должен также отметить, что о размещении по сетке можно сказать больше, чем позволяет объем книги. Например, путем создания вложенных фреймов с собственными сетками можно строить более сложные структуры в виде иерархий компонентов, во многом подобно тому, как размещает вложенные фреймы менеджер компоновки pack. А теперь перейдем к последней теме обзора виджетов.
Инструменты синхронизации, потоки выполнения и анимация
Последняя остановка в нашей экскурсии по виджетам, вероятно, самая необычная. Библиотека tkinter предоставляет ряд инструментов, которые связаны с моделью программирования, управляемого событиями, а не с отображением графики на экране.
Некоторым приложениям с графическим интерфейсом требуется периодически выполнять действия в фоновом режиме. Например, чтобы придать виджету «мерцающий» вид, можно зарегистрировать обработчик, который будет вызываться через равные промежутки времени. Аналогично при выполнении длительной операции с файлом неверно было бы заблокировать прочие действия в графическом интерфейсе -если бы удалось заставить цикл событий периодически выполнять обновления, графический интерфейс мог бы оставаться активным. В библиотеке tkinter есть средства для планирования таких отложенных действий и принудительного обновления интерфейса:
widget.after(milliseconds, function, *args)
Этот инструмент планирует вызов указанной функции по истечении заданного числа миллисекунд. Данная форма вызова не останавливает программу - функция обратного вызова будет запущена позднее из обычного цикла событий tkinter, а вызывающая программа продолжит свою работу как обычно и графический интерфейс останется активным, пока функция ожидает вызова. Как уже говорилось в главе 5, в отличие от объекта Timer из модуля threading, события widget.after распространяются в главном потоке выполнения графического интерфейса и потому могут выполнять в нем любые изменения.
Аргумент function может быть любым вызываемым объектом Python: функцией, связанным методом, lambda-выражением и так далее. Аргумент milliseconds определяет интервал времени в миллисекундах и является целым числом - если разделить значение этого аргумента на 1000, получится эквивалентное число секунд. Любые значения в кортеже args будут переданы функции function в виде позиционных аргументов.
На практике вместо отдельных аргументов можно использовать lambda-выражения, чтобы сделать связь аргументов с функцией более явной, но это не является обязательным. Когда в качестве функции передается связанный метод, он может получать дополнительную информацию из атрибутов объекта, а не из аргументов. Метод after возвращает идентификатор, который можно передать методу after_cancel, чтобы отменить вызов обработчика. Метод after используется очень часто, поэтому несколько ниже о нем будет рассказываться более подробно и с примерами.
widget.after(milliseconds)
Этот инструмент останавливает выполнение программы на заданное количество миллисекунд. Например, если передать в аргументе число 5000, программа будет приостановлена на 5 секунд. В сущности, это то же самое, что библиотечная функция Python time. sleep(seconds), и обе функции могут применяться для создания задержки при отображении (например, в анимационных программах, таких как PyDraw и более простых примерах ниже).
widget.after_idle(function, *args)
Этот инструмент планирует вызов указанной функции при отсутствии других событий, которые должны обрабатываться. То есть функция function становится обработчиком холостого времени, который вызывается, когда графический интерфейс не занят ничем другим.
widget.after_cancel(id)
Этот инструмент отменяет вызов обработчика, запланированный методом after до того, как он произойдет. Аргумент id - значение, возвращаемое методом after.
widget.update()
Этот инструмент вынуждает библиотеку tkinter обработать все ожидающие события, имеющиеся в очереди событий, в том числе изменение геометрии окна, а также обновление и перерисовку виджетов. Его можно периодически вызывать из долго выполняющегося обработчика, чтобы обновить экран и произвести те изменения, которые уже запросил ваш обработчик. Если этого не делать, произведенные обработчиком изменения появятся на экране только после выхода из него. На время работы обработчика, выполняющегося продолжительное время, интерфейс может вообще зависнуть, если не обновлять его вручную (обработчики не выполняются в отдельных потоках, о чем говорится в следующем разделе); окно даже не будет перерисовывать себя при перекрытии или открытии другими окнами, пока не произойдет возврат из обработчика.
Например, программы, осуществляющие анимацию путем последовательного перемещения объекта и приостановки, должны вызывать этот метод, не дожидаясь конца анимации, иначе на экране можно будет увидеть только конечное положение объекта. Что еще хуже, интерфейс окажется совершенно неактивным, пока не произойдет возврат из обработчика анимации (смотрите простые примеры воспроизведения анимации далее в этой главе и в программе PyDraw в главе 11).
widget.update_idletasks()
Этот инструмент запускает обработку всех событий холостого времени. Иногда он безопаснее, чем метод after, который в некоторых случаях может стать причиной возникновения состояния гонки за ресурсами (race conditions). События холостого времени используются виджетами Tk для отображения самих себя.
_tkinter.createfilehandler(file, mask, function)
Этот инструмент назначает функцию, которая будет вызываться при изменении состояния файла. Функция может быть вызвана, когда в файле появятся данные для чтения, когда он станет доступным для записи или когда будет возбуждено исключение. В аргументе file передается объект Python файла или сокета (формально - любой объект с методом fileno()) или целочисленный дескриптор файла; аргументе mask - значение tkinter. READABLE или tkinter. WRITABLE, определяющее режим; а в аргументе function передается функция обратного вызова, принимающая два аргумента - признак готовности файла к выполнению операции и маску. Обработчики файлов часто используются для обработки каналов и сокетов, так как обычные функции ввода/вывода могут блокировать вызывающую программу.
Этот метод недоступен в Windows и потому не будет рассматриваться в данной книге. Поскольку он доступен только в Unix, для разработки переносимых графических интерфейсов лучше использовать циклы таймера after для проверки готовности к выполнению операции и порождать потоки выполнения, которые будут читать данные и помещать их в очередь при необходимости; более подробно этот прием описывается в главе 10. Потоки выполнения являются более универсальным механизмом выполнения неблокирующих операций передачи данных.
widget.wait_variable(var)
widget.wait_window(win)
widget.wait_visibility(win)
Эти инструменты приостанавливают выполнение вызвавшей программы до момента, когда переменная tkinter изменит свое значение, будет разрушено окно или окно станет видимым. Все они входят в локальный цикл событий, благодаря чему функция mainloop приложения продолжает обработку событий. Обратите внимание, что аргумент var является объектом переменной tkinter (о которых рассказывалось ранее), а не простой переменной Python. Для использования в модальных диалогах сначала следует вызвать widget.focus() (чтобы установить фокус ввода) и widget.grab() (чтобы сделать окно единственным активным).
Некоторые из этих инструментов мы будем использовать в примерах, но не станем вникать во все их особенности здесь. За дополнительной информацией обращайтесь к другой документации по библиотекам Tk и tkinter.
Использование потоков выполнения в графических интерфейсах tkinter
Имейте в виду, что во многих программах поддержка потоков выполнения в Python, с которой мы познакомились в главе 5, способна отчасти решать те же задачи, что и инструменты tkinter, перечисленные в предыдущем разделе, и даже позволяет использовать их. Например, чтобы избежать блокировки интерфейса (и не заставлять пользователей бездействовать) во время продолжительных операций обмена данными через файлы или сокеты, этот обмен можно выполнять в дочерних потоках выполнения, при этом остальная часть программы будет выполняться, как обычно. Аналогично графические интерфейсы, ожидающие появления данных в канале или в сокете, могут использовать для этих целей потоки выполнения, обработчики, устанавливаемые методом after, или их комбинации, и тем самым избежать блокирования графического интерфейса.
Однако при использовании потоков выполнения в программах на основе библиотеки tkinter обращения к графическому интерфейсу должны выполняться только из главного потока (в котором был создан интерфейс и запущена функция mainloop). По крайней мере, потоки не должны пытаться одновременно изменять графический интерфейс. Например, метод update, описанный в предыдущем разделе, исторически является источником проблем в многопоточных графических интерфейсах - если вызывать его (или другой метод, вызывающий update) в порожденных потоках выполнения, он иногда может приводить к неожиданному и даже эффектному краху программы.
Чтобы увидеть простые и яркие примеры, демонстрирующие небезопасность обращения к графическим интерфейсам на базе tkinter из нескольких потоков выполнения, загляните в следующие сценарии, находящиеся в дереве примеров к книге, и попробуйте запустить их:
..\PP4E\Gui\Tour\threads-demoAU-frm.py
..\PP4E\Gui\Tour threads-demoAll-win.py
Эти сценарии являются версиями примеров 8.32 и 8.33 из предыдущей главы, которые конструируют четыре демонстрационных компонента графического интерфейса в параллельно выполняющихся потоках. Оба они зависают в Windows и требуют принудительного завершения. Но, хотя некоторые операции с графическим интерфейсом могут безопасно выполняться параллельно в разных потоках (например, смотрите пример 9.32, где выполняется перемещение элементов на холсте), тем не менее в целом библиотека tkinter не поддерживает многопоточную модель выполнения. (Дополнительные доказательства этого утверждения вы найдете в обсуждении многопоточной реализации циклов обновления в следующей главе, сразу после примера 10.28 - в этом примере поток выполнения пытается вывести новое окно, что вызывает сбой в работе графического интерфейса.)
Такое отношение к потокам выполнения со стороны реализации поддержки графических интерфейсов может измениться со временем, но на сегодняшний день оно налагает некоторые структурные ограничения. Например, порожденные потоки выполнения обычно не могут производить опеарции с графическим интерфейсом, поэтому, в случае необходимости, они должны взаимодействовать с главным потоком программы, используя глобальные переменные или разделяемые объекты, такие как очереди. Например, поток, ожидающий получения данных из сокета, может добавлять их в разделяемые очереди или просто устанавливать глобальные переменные и инициировать изменения в графическом интерфейсе через обработчик, устанавливаемый методом after. А обработчик может обрабатывать результаты, полученные в порождаемых потоках.
Некоторые операции над графическим интерфейсом поддерживают возможность выполнения в многопоточном режиме, тем не менее программы с графическим интерфейсом лучше делить на главный поток, управляющий графическим интерфейсом, и ряд «рабочих» потоков, не связанных с интерфейсом, что поможет избежать потенциальных конфликтов и решить проблему поддержки многопоточности в целом. Программа PyMailGUI, представленная далее в книге, например, вызывает функции-обработчики, сохраняемые потоками выполнения в очереди.
Не забывайте также, что независимо от наличия поддержки многопоточной модели выполнения в графических интерфейсах многопоточные программы с графическим интерфейсом должны следовать тем же правилам, что и любые другие многопоточные программы. Как мы узнали в главе 5, такие программы всегда должны синхронизировать доступ к совместно используемым данным, если есть вероятность, что сразу несколько потоков попытаются изменить их. Модель организации потоков производитель/потребитель, основанная на очередях, способна снять множество проблем, тем не менее в программах, порождающих потоки выполнения, изменяющие информацию, которую использует главный поток управления графическим интерфейсом, по-прежнему может требоваться использовать блокировки, чтобы избежать проблем, связанных с попытками одновременного изменения совместно используемых данных.
Подробнее многопоточные графические интерфейсы мы будем рассматривать в главе 10, а в четвертой части книги познакомимся с более реалистичными примерами многопоточных графических интерфейсов, таких как PyMailGUI в главе 14. В PyMailGUI, например, чтобы избежать блокирования интерфейса, для выполнения продолжительных операций используются потоки, все действия с графическим интерфейсом производятся только в главном потоке, а для предотвращения конфликтов, возможных при изменении совместно используемых данных, применяются блокировки.
Использование метода after
Из всех инструментов, перечисленных выше, наиболее интересным является метод after. Он позволяет сценариям назначить обработчик, который будет вызван в некоторый момент времени в будущем. Несмотря на его простоту, он будет часто использоваться в последующих примерах. В частности, в главе 11 мы познакомимся с программой часов, которая с помощью метода after просыпается 10 раз в секунду и получает текущее время, а также с программой показа слайдов, которая с помощью метода after устанавливает интервал смены фотографий (программы PyClock и PyView). Для иллюстрации основ планирования вызова обработчиков служит пример 9.27.
Пример 9.27. PP4E\Gui\Tour\alarm.py
# мигает и издает сигнал каждую секунду, используя цикл с методом after()
from tkinter import *
class Alarm(Frame):
def __init__(self, msecs=1000): # по умолчанию = 1 секунда
Frame.__init__(self)
self.msecs = msecs self.pack()
stopper = Button(self, text='Stop the beeps!’, command=self.quit) stopper.pack()
stopper.config(bg=’navy’, fg=’white’, bd=8)
self.stopper = stopper
self.repeater()
def repeater(self): # каждые N миллисекунд
self.bell() # подать сигнал
self.stopper.flash() # мигнуть кнопкой
self.after(self.msecs, self.repeater) # запланировать следующий вызов
if __name__ == ‘__main__’: Alarm(msecs=1000).mainloop()
Этот сценарий создает окно, изображенное на рис. 9.41, и периодически вызывает метод flash кнопки, заставляющий кнопку мигнуть (изменяет ее цвет на короткое время), и метод bell, который обращается к функции подачи звукового сигнала. Метод repeater вызывает методы beep и flash и с помощью метода after устанавливает обработчик, который будет выполнен через определенный промежуток времени.
Рис. 9.41. Прекратите пищать!
Метод after не останавливает вызывающий сценарий: обработчик вызывается в фоновом режиме, в то время как программа выполняет другую работу, - технически с того момента, когда цикл событий Tk получит возможность обнаружить изменение времени. Для этого метод repeater каждый раз вызывает after и заново устанавливает обработчик. Отложенные события являются одноразовыми: чтобы повторить событие, его нужно снова запланировать.
В итоге этот сценарий начинает подавать звуковые сигналы и мигать кнопкой, как только будет выведено его окно с одной кнопкой, и продолжает подавать сигналы и мигать снова и снова. Прочие действия и операции с графическим интерфейсом не влияют на это. Даже если свернуть окно, сигналы будут продолжаться, потому что события таймера tkinter генерируются в фоновом режиме. Чтобы прекратить сигналы, нужно закрыть окно или щелкнуть на кнопке. Изменив задержку msecs, можно заставить сигнал звучать так часто или так редко, как позволяет система (максимально допустимая частота может зависеть от платформы). Предупреждаю заранее, что это не лучшая демонстрационная программа для запуска в многолюдном помещении.
Скрытие и перерисовка виджетов и окон
Метод flash кнопки вызывает кратковременное изменение цвета виджета, но с помощью метода config так же просто можно динамически изменять и другие параметры внешнего вида виджетов, таких как кнопки, метки и текст,. Например, эффекта мигания можно добиться путем инвертирования цветов переднего и заднего плана элементов вручную, вызывая метод config в обработчиках, установленных методом after. Ради забавы в примере 9.28 приводится версия сценария, подающего звуковой сигнал, в которой сделан еще один шаг.
Пример 9.28. PP4E\Gui\Tour\alarm-hide.py
# стирает и отображает кнопку в обработчике, устанавливаемом методом after()
from tkinter import * import alarm
class Alarm(alarm.Alarm): # измените обработчик таймера
def __init__(self, msecs=1000): # по умолчанию = 1 секунда
self.shown = False alarm.Alarm.__init__(self, msecs)
def repeater(self): # каждые N миллисекунд
self.bell() # подать сигнал
if self.shown:
self.stopper.pack_forget() # скрыть кнопку
else: # или изменить цвет, мигнуть...
self.stopper.pack()
self.shown = not self.shown # изменить до следующего раза
self.after(self.msecs, self.repeater) # переустановить обработчик
if __name__ == ‘__main__’: Alarm(msecs=500).mainloop()
Если запустить этот сценарий, на экране появится то же самое окно, но теперь при каждом событии от таймера кнопка поочередно будет стираться и отображаться вновь. Метод pack_forget виджета стирает нарисованный элемент, а метод pack отображает его снова - методы grid_ forget и grid аналогичным образом скрывают и отображают виджеты в сетке. Метод pack_forget удобно использовать для динамического изменения графического интерфейса. Например, можно решить, какие компоненты должны отображаться в тот или иной момент времени, создавать виджеты заранее и отображать их только по мере надобности. В данном случае это просто значит, что пользователь должен щелкнуть на кнопке, пока она видна, иначе шум будет продолжаться.
Сценарий в примере 9.29 идет еще дальше. Здесь с помощью нескольких методов реализовано скрытие и появления всего окна:
• Чтобы скрыть и отобразить не какой-то отдельный виджет, а целое окно, можно воспользоваться методами withdraw и deiconify этого окна. Метод withdraw, используемый в примере 9.29, полностью стирает окно и его ярлык (если необходимо, чтобы ярлык окна оставался видимым, используйте метод iconify).
• Метод lift поднимает окно над всеми другими окнами или над определенным окном, переданным методу в виде аргумента. Этот метод также может также вызываться под именем tkraise, но не raise - его именем в Tk, потому что raise в языке Python является зарезервированным словом.
• Метод state возвращает или изменяет текущее состояние окна - он принимает значения normal, iconic, zoomed (на весь экран) и withdrawn.
Поэкспериментируйте с этими методами, чтобы понять, чем они отличаются. Их также можно использовать для динамического вывода предварительно созданных диалогов, однако практическая ценность этого приема невелика.
Пример 9.29. PP4E\Gui\Tour\alarm-withdraw.py
# то же самое, но скрывает и отображает окно целиком
from tkinter import * import alarm
class Alarm(alarm.Alarm):
def repeater(self): # каждые N миллисекунд
self.bell() # подать сигнал
if self.master.state() == ‘normal’: # окно отображается?
self.master.withdraw() # скрыть окно, без ярлыка
else: # iconify свертывает в ярлык
self.master.deiconify() # иначе перерисовать окно
self.master.lift() # и поднять над остальными
self.after(self.msecs, self.repeater) # переустановить обработчик
if __name__ == ‘__main__’: Alarm().mainloop() # master = корневое окно Tk
# по умолчанию
Этот сценарий действует точно так же, за исключением того, что при подаче сигнала появляется или исчезает все окно - закрывать его надо тогда, когда оно видно. Реализацию обработчика, вызываемого по таймеру, можно разнообразить массой других эффектов. Будете ли вы добиваться, чтобы ваши кнопки и окна мигали и исчезали, зависит скорее от мнения пользователей, чем от возможностей библиотеки tkinter.
Простые приемы воспроизведения анимации
Все графические интерфейсы, представленные до сих пор в этой книге, за исключением примера canvasDraw с непосредственным перемещением фигур, были довольно статичными. В данном, последнем разделе будет показано, как можно изменить эту ситуацию, добавив в пример 9.16 несколько простых анимаций перемещения фигуры на холсте.
Здесь также демонстрируется и расширяется понятие тегов холста -операции перемещения в этом примере применяются сразу ко всем объектам на холсте, связанным с тегом. Все овалы перемещаются при нажатии клавиши O, а все прямоугольники - при нажатии клавиши R. Как уже отмечалось ранее, методы холста принимают не только идентификаторы объектов, но и имена тегов.
Но главная задача сейчас состоит в том, чтобы проиллюстрировать простые приемы анимации с помощью инструментов, основанных на измерении интервалов времени и описанных выше в этом разделе. Существует три основных способа перемещения объектов по холсту:
• С помощью циклов, использующих функцию time.sleep для приостановки на доли секунды между последовательными операциями перемещения, наряду с вызовами метода update вручную. Сценарий выполняет перемещение, приостанавливается, передвигает объект еще немного и так далее. Функция time.sleep приостанавливает работу вызывающей программы и не возвращает управление в цикл событий графического интерфейса - обработка операций с интерфейсом, выполняемых во время перемещения, откладывается. Из-за этого после каждого перемещения нужно вызывать метод canvas. update, чтобы перерисовать экран, иначе экран не обновится, пока не закончится весь цикл перемещения в обработчике и не произойдет возврат. Это классический пример обработчика, выполняющегося продолжительное время. Без вызова метода обновления экрана вручную никакие другие события графического интерфейса не будут обработаны до возврата из обработчика (даже перерисовка окна).
• С помощью метода widget.after, планирующего выполнение операций перемещения через каждые несколько миллисекунд. Поскольку этот подход основан на расписании событий, которые библиотека tkinter отправляет обработчикам, он допускает параллельное осуществление нескольких перемещений и не требует вызова метода canvas.update. Для выполнения перемещений используется цикл событий, поэтому приостановка программы не требуется и графический интерфейс не блокируется.
• С помощью потоков выполнения, в которых выполняется несколько экземпляров циклов с приостановкой вызовом метода time.sleep, как в первом подходе. Так как потоки выполняются параллельно, приостановка любого из потоков не блокирует ни графический интерфейс, ни другие потоки, выполняющие перемещения. Как уже описывалось выше, графический нтерфейс вообще не следует обновлять из порожденных потоков, но некоторые методы холста, в частности метод move, в настоящее время допускают возможность вызова из потоков выполнения.
Из этих трех схем первая обеспечивает самое плавное воспроизведение анимации, но она замедляет другие операции во время перемещения. Вторая схема дает более замедленное перемещение, чем остальные, но в целом безопаснее, чем использование потоков выполнения, и обе последние схемы позволяют одновременно передвигать несколько объектов.
Использование циклов time.sleep
В следующих трех разделах поочередно демонстрируется структура программного кода для всех трех подходов, создающая новые подклассы примера canvasDraw, с которым мы познакомились в примере 9.16. Обращайтесь к этому примеру за информацией о привязке других событий и об основах выполнения операций рисования, перемещения и стирания. Здесь объекты, создаваемые на холсте, ассоциируются с тегами, а также добавляются новые операции и выполняется привязка новых событий. Пример 9.30 иллюстрирует первый подход.
Пример 9.30. PP4E\Gui\Tour\canvasDraw_tags.py
перемещение с применением тегов и функции time.sleep (без помощи метода widget. after или потоков выполнения); функция time.sleep не блокирует цикл событий графического интерфейса на время паузы, но интерфейс не обновляется до выхода из обработчика или вызова метода widget.update; текущему вызову обработчика onMove уделяется исключительное внимание, пока он не вернет управление: если в процессе перемещения нажать клавишу ‘R’ или ‘O’;
from tkinter import * import canvasDraw, time
class CanvasEventsDemo(canvasDraw.CanvasEventsDemo):
def __init__(self, parent=None):
canvasDraw.CanvasEventsDemo.__init__(self, parent)
self.canvas.create_text(100, 10, text=’Press o and r to move shapes’) self.canvas.master.bind(‘’, self.onMoveOvals) self.canvas.master.bind(‘’, self.onMoveRectangles) self.kinds = self.create_oval_tagged, self.create_rectangle_tagged
def create_oval_tagged(self, x1, y1, x2, y2):
objectId = self.canvas.create_oval(x1, y1, x2, y2) self.canvas.itemconfig(objectId, tag=’ovals’, fill=’blue’) return objectId
def create_rectangle_tagged(self, x1, y1, x2, y2):
objectId = self.canvas.create_rectangle(x1, y1, x2, y2) self.canvas.itemconfig(objectId, tag=’rectangles’, fill=’red’) return objectId
def onMoveOvals(self, event): print(‘moving ovals’)
self.moveInSquares(tag=’ovals’) # переместить все овалы с данным тегом
def onMoveRectangles(self, event): print(‘moving rectangles’) self.moveInSquares(tag=’rectangles’)
def moveInSquares(self, tag): # 5 повторений по 4 раза в секунду
for i in range(5):
for (diffx, diffy) in [(+20, 0), (0, +20), (*20, 0), (0, *20)]: self.canvas.move(tag, diffx, diffy)
self.canvas.update() # принудительно обновить изображение
time.sleep(0.25) # пауза, не блокирующая интерфейс
if __name__ == ‘__main__’:
CanvasEventsDemo()
mainloop()
Все три сценария в этом разделе при вытягивании новых фигур с помощью левой кнопки мыши создают окно с голубыми овалами и красными прямоугольниками. Сама реализация вытягивания наследуется из суперкласса. Щелчок правой кнопкой мыши немедленно перемещает одну фигуру, а двойной щелчок левой кнопкой по-прежнему очищает холст - эти операции также унаследованы из суперкласса. В действительности в этом новом сценарии лишь изменены методы, создающие объекты, - теперь они ассоциируют создаваемые объекты с тегами и окрашивают их в соответствующие цвета, добавлено текстовое поле в верхней части холста и добавлены обработчики событий, выполняющие перемещение. На рис. 9.42 показано, как выглядит окно этого подкласса после создания нескольких фигур.
Рис. 9.42. Нарисованные объекты готовы к анимации
С помощью клавиш O и R начинается анимация всех нарисованных овалов и прямоугольников соответственно. Например, при нажатии клавиши O начинают синхронно перемещаться все голубые овалы. Объекты, которые подвергаются анимации, помечаются пятью квадратами вокруг своего местоположения, и перемещаются со скоростью четыре шага в секунду. Новые объекты, которые вытягиваются, когда другие находятся в движении, тоже начинают перемещаться, потому что помечены тегами. Вам обязательно следует запустить этот сценарий, чтобы получить представление о простой анимации, которую он реализует (можно, конечно, попробовать подвигать влево-вправо и вверх-вниз книгу, но это все-таки не совсем то, что нужно, да и может глупо выглядеть на людях).
Использование событий widget.after
Главный недостаток первого подхода в том, что одновременно может происходить только одна анимация: если нажать клавишу R или O во время движения, новый запрос приостанавливает предыдущее перемещение до своего окончания, потому что каждый обработчик операции перемещения допускает только один поток управления при своей работе. То есть в каждый конкретный момент времени может выполняться только один цикл, использующий time.sleep, а новый вызов этой функции из метода update фактически является рекурсивным вызовом, который приостанавливает уже выполняющийся цикл.
Обновление экрана во время перемещений тоже происходит несколько замедленно, потому что производится, только когда метод update вызывается вручную (попробуйте вытянуть фигуру или перекрыть окно другим окном во время перемещения и вы в этом убедитесь сами). Фактически если закомментировать вызов метода update в примере 9.30, графический интерфейс вообще перестанет откликаться во время выполнения операций перемещения - он не будет перерисовываться при перекрытии другими окнами, не будет откликаться на действия пользователя и никакого эффекта анимации воспроизводиться не будет (по истечении времени вы просто увидите окно в заключительном состоянии). Это полноценная имитация влияния операций, выполняющихся продолжительное время, на графический интерфейс.
Пример 9.31 переопределяет метод moveInSquares, чтобы снять такие ограничения, - применяя метод after, он обеспечивает перемещение практически без пауз. Кроме того, он демонстрирует наиболее часто используемый (и, вероятно, лучший) способ обработки событий от таймера в графических интерфейсах на основе библиотеки tkinter. Разбиение задания на части вместо того чтобы выполнять его целиком, позволяет выполнить естественное распределение частей по времени и выполнять несколько заданий одновременно.
Пример 9.31. PP4E\Gui\Tour\canvasDraw_tags_after.py
аналогично, но с применением метода widget.after() вместо циклов time.sleep; поскольку это планируемые события, появляется возможность перемещать овалы и прямоугольники _одновременно_ и отпадает необходимость вызывать метод update для обновления графического интерфейса; движение станет беспорядочным, если еще раз нажать ‘o’ или ‘r’ в процессе воспроизведения анимации: одновременно начнут выполняться несколько операций перемещения;
from tkinter import * import canvasDraw_tags
class CanvasEventsDemo(canvasDraw_tags.CanvasEventsDemo): def moveEm(self, tag, moremoves):
(diffx, diffy), moremoves = moremoves[0], moremoves[1:] self.canvas.move(tag, diffx, diffy) if moremoves:
self.canvas.after(250, self.moveEm, tag, moremoves)
def moveInSquares(self, tag):
allmoves = [(+20, 0), (0, +20), (*20, 0), (0, *20)] * 5 self.moveEm(tag, allmoves)
if __name__ == ‘__main__’:
CanvasEventsDemo()
mainloop()
Эта версия наследует все изменения из предыдущей версии и при этом позволяет перемещать овалы и прямоугольники одновременно - нарисуйте несколько овалов и прямоугольников, а затем нажмите клавишу O и затем сразу клавишу R. Попробуйте нажать обе клавиши несколько раз - чем больше нажатий, тем интенсивнее движение, потому что генерируется много событий, перемещающих объекты из того места, в котором они находятся. Если во время перемещения нарисовать новую фигуру, она, как и раньше, начнет перемещаться немедленно.
Использование нескольких потоков выполнения с циклами time.sleep
Иногда того же эффекта можно добиться выполнением анимации в потоках. Как уже говорилось выше, в целом обновлять интерфейс из порожденного потока выполнения опасно, но в данном примере этот прием действует (по крайней мере, на платформах, участвовавших в тестировании). В примере 9.32 каждая задача анимации выполняется как независимый и параллельный поток. Это означает, что при каждом нажатии клавиши O или R для запуска анимации порождается новый поток, который выполняет эту задачу.
Пример 9.32. PP4E\Gui\Tour\canvasDraw_tags_thread.py
аналогично, но анимация воспроизводится с применением циклов time.sleep, выполняемых параллельно в разных потоках, а не с помощью обработчиков событий, устанавливаемых методом after(), или одного активного цикла time. sleep; поскольку потоки выполняются параллельно, эта версия также позволяет перемещать овалы и прямоугольники _одновременно_ и не требует вызывать метод update для обновления графического интерфейса: фактически вызов метода .update() в этой версии приводит к краху, хотя некоторые методы холста можно безопасно использовать в потоках, иначе все это вообще не работало бы;
from tkinter import * import canvasDraw_tags import _thread, time
class CanvasEventsDemo(canvasDraw_tags.CanvasEventsDemo): def moveEm(self, tag): for i in range(5):
for (diffx, diffy) in [(+20, 0), (0, +20), (*20, 0), (0, *20)]: self.canvas.move(tag, diffx, diffy)
time.sleep(0.25) # приостанавливает только этот поток
def moveInSquares(self, tag):
_thread.start_new_thread(self.moveEm, (tag,))
if __name__ == ‘__main__’:
CanvasEventsDemo()
mainloop()
В этой версии возможно одновременное перемещение фигур, как и в примере 9.31, но на этот раз оно выполняется с помощью параллельных потоков. На самом деле используется та же схема, что и в первой версии time.sleep. Однако в данном случае активных потоков управления может быть несколько, поэтому периоды выполнения обработчиков перемещений могут перекрываться во времени - функция time.sleep блокирует только вызвавший ее поток, а не программу в целом.
В настоящее время этот пример прекрасно работает в Windows, но в Linux он однажды потерпел у меня неудачу - интерфейс не обновлялся при изменении его в потоках, и никаких изменений не наблюдалось до появления последующих событий. Правило, которое гласит, что желательно избегать изменения графического интерфейса в порождаемых потоках выполнения, остается верным. Обычно надежнее использовать потоки только для вычислений, а какое-либо обновление экрана производить в главном потоке (создавшем графический интерфейс). Тем не менее даже в этой модели главный поток выполнения может следить за результатами работы других потоков с помощью метода after, как в примере 9.31, не приостанавливаясь в периоды ожидания (подробнее об этом рассказывается в следующем разделе и в следующей главе).
Не исключено, что реализация составных частей, участвующих в создании анимации, изменится со временем, и не исключено, что возможность обновления графического интерфейса из потоков выполнения будет лучше поддерживаться в следующих версиях tkinter, поэтому ищите дополнительные сведения об изменениях в поддержке многопоточной модели в новых выпусках.
Другие темы, связанные с анимацией
Мы снова обратимся к анимации в примере PyDraw в главе 11. В нем будут возрождены все три приема - задержки, таймеры и потоки - для перемещения фигур, текста и фотографий в произвольные точки холста, помечаемые щелчком мыши. И хотя система абсолютных координат холста - главная рабочая лошадка для реализации большинства нетривиальных анимаций, в целом возможности анимации, основанные на библиотеке tkinter, ограничены лишь вашим воображением. В заключение скажу еще несколько слов, чтобы обозначить некоторые из имеющихся возможностей.
Другие анимационные эффекты
Помимо анимационных эффектов, которые создаются с применением холста, различные анимационные эффекты можно также создавать с помощью инструментов настройки виджетов. Как было показано ранее в примерах сценариев alarm (пример 9.28), где использовались эффекты скрытия и мигания виджетов, с помощью метода after можно легко динамически изменять внешний вид и других виджетов. С помощью циклов на основе таймера можно организовать мигание виджетов, динамически стирать и перерисовывать виджеты и окна, инвертировать или изменять цвет виджетов и так далее. Еще один пример из этой категории, где динамически изменяется шрифт и цвет (хотя эргономика этого примера вызывает большое сомнение), приводится во врезке «На досуге...», в главе 1.
Потоки выполнения и анимация
Приемы выполнения продолжительных операций в параллельных потоках приобретают особое значение, когда анимация должна оставаться активной, пока приложение выполняет какую-либо работу. Например, представьте себе программу, которая загружает большой объем данных из сети, производит тяжелые математические вычисления или выполняет другие продолжительные операции. Если графический интерфейс такой программы должен воспроизводить анимацию или как-то иначе отображать ход выполнения операции, периодически изменяя внешний вид виджета или перемещая объекты на холсте, - просто используйте метод after, как было показано выше, для периодического вызова обработчика, который будет изменять графический интерфейс. В обработчике, установленном с помощью метода after, можно, к примеру, обновлять индикатор хода выполнения или счетчик.
Кроме того, саму продолжительную операцию, вероятно, лучше выполнять в параллельном потоке, чтобы графический интерфейс оставался активным, и воспроизводить анимацию, ожидая завершения операции. В противном случае графический интерфейс будет оставаться неактивным, пока операция не завершится и не вернет управление. Внутри обработчика, установленного вызовом метода after, главный поток выполнения, управляющий графическим интерфейсом, мог бы проверять переменные или объекты, изменяемые потоком, выполняющим продолжительную операцию, чтобы определить момент ее завершения.
В частности, когда в приложении одновременно выполняется более одной продолжительной операции, порожденные потоки выполнения могут также взаимодействовать с главным потоком графического интерфейса, сохраняя информацию в объекте Python Queue, которая будет обрабатываться реализацией графического интерфейса внутри обработчика, устанавливаемого методом after. В общем случае в очередь Queue допускается помещать даже объекты функций, которые могут вызываться реализацией графического интерфейса для его обновления.
В главе 10 мы еще раз вернемся к обсуждению приемов реализации многопоточных графических интерфейсов и будем использовать их в примере PyMailGUI, далее в этой книге. А пока имейте в виду, что организация вычислений в отдельных потоках выполнения позволяет графическому интерфейсу оставаться активным и воспроизводить анимацию или реагировать на действия пользователя, ожидая окончания вычислений.
Инструменты отображения графики и реализации игровых программ
Если только вы не прекратили играть в видеоигры сразу после появления игры Pong46, вы наверняка понимаете, что приемы перемещения и воспроизведения анимации, продемонстрированные в этой главе, могут использоваться для реализации игровых программ, но только самых простых. Для реализации игровых программ с более высокими требованиями в Python имеются дополнительные инструменты поддержки графики и игр, которые мы не рассматривали здесь.
Если требуется более сложная трехмерная анимация, следует обратить внимание на поддержку пакетом расширения PIL распространенных форматов файлов анимации и фильмов, таких как FLI и MPEG. Другие сторонние инструменты, такие как OpenGL, Blender, PyGame, Maya и VPython, обеспечивают еще более высокоуровневые средства отображения графики и анимации. Кроме того, система PyOpenGL обеспечивает поддержку Tk для построения графических интерфейсов. Ссылки на эти и другие инструменты ищите на веб-сайтах PyPI или в поисковых системах.
Если вас интересует разработка игровых программ, обратите внимание на PyGame и другие пакеты поддержки разработки игр на языке Python, а также обращайтесь к другим книгам и веб-ресурсам, посвященным этой тематике. Язык Python нечасто используется в качестве единственного языка для реализации игровых программ, интенсивно использующих графику, но его все же можно применять в качестве языка, на котором пишутся прототипы и сценарии для таких продуктов.47 А при интеграции с библиотеками трехмерной графики его роль может быть расширена еще больше. Ссылки на другие имеющиеся расширения для этой области можно найти на сайте http://www.python.org.
Конец экскурсии
На этом мы завершаем наш обзор библиотеки tkinter. Вы познакомились со всеми основными виджетами и инструменты, предварительный обзор которых был сделан в конце главы 7 (вернитесь туда, чтобы просмотреть общее описание области, рассмотренной в этом путешествии). Дополнительные сведения вы получите, когда все представленные здесь инструменты вновь появятся в более крупных примерах в главах 10 и 11 и в оставшейся части книги в целом. В некотором смысле последние несколько глав заложили основу для перехода к более крупным программам, следующим далее.
Другие виджеты и их параметры
Однако следует заметить, что наш тур не был исчерпывающим. Мы познакомились со всеми основными виджетами в арсенале tkinter и попутно овладели основами построения графических интерфейсов, тем не менее мы пропустили ряд более новых и более совершенных виджетов, появившихся в библиотеке tkinter недавно:
Spinbox
Поле ввода Entry для выбора значения из множества или из диапазона
LabelFrame
Фрейм с заголовком и рамкой вокруг группы элементов
PanedWindow
Виджет менеджера компоновки, который может содержать множество виджетов, изменяющих свои размеры при перемещении линий-разделителей мышью
Кроме того, мы даже не упомянули ни об одном из виджетов в популярных расширениях библиотеки tkinter, таких как Pmw, Tix и ttk (описываются в главе 7), и не коснулись ни одного стороннего пакета. Например:
• Расширения Tix и ttk реализуют дополнительные параметры виджетов, обозначенные в главе 7, которые теперь входят в состав стандартной библиотеки Python.
• Перечень сторонних пакетов имеет тенденцию изменяться со временем, тем не менее уже сейчас они предоставляют виджеты деревьев, средства отображения разметки HTML, диалоги выбора шрифта, таблицы и многое другое, а также огромный пакет виджетов Pmw.
• Многие программы с графическим интерфейсом на основе библиотеки tkinter, такие как стандартная среда IDLE, включают диалоги выбора шрифта, виджеты деревьев и многое другое, что с успехом может использоваться вами в ваших приложениях.
Поскольку такие расширения пока еще для нас слишком сложны, чтобы их можно было охватить с пользой для дела, в интересах экономии места в книге мы оставим их освещение за другими ресурсами. В поисках более богатых возможностей для своих графических интерфейсов обязательно ознакомьтесь с описанием дополнительных виджетов в документации по tkinter, Tk, Tix, ttk и Pmw, посетите веб-сайт PyPI по адресу http://python.org/ или поищите сторонние расширения для tkinter в Интернете.
Следует также заметить, что виджеты также обладают дополнительными параметрами настройки, о которых не упоминалось в этом обзоре. Ищите описания этих параметров в ресурсах по библиотекам Tk и tkinter. В библиотеке tkinter имеются и другие инструменты, аналогичные представленным здесь, тем не менее пространство в книге, которое я могу отвести для их освещения, ограничено, во-первых, моим издателем, а во-вторых - небесконечностью древесных ресурсов.
iq
Приемы программирования графических интерфейсов
«Создание улучшенной мышеловки»
В этой главе мы продолжаем изучать создание графических интерфейсов пользователей с помощью Python и стандартной библиотеки tkinter, путем представления коллекции более сложных шаблонов и приемов программирования графических интерфейсов. В трех предшествующих главах мы познакомились с основами использования библиотеки tkinter. Здесь мы применим полученные знания для конструирования структур более высокого уровня, которые пригодятся в создании более крупных программ. То есть здесь мы перейдем к написанию собственного программного кода, реализующего программный слой над и вне базового набора инструментов tkinter, который с пользой будет применен в более практичных примерах далее в книге.
В этой главе мы рассмотрим следующие приемы:
• Реализация типичных операций с графическим интерфейсом в виде подмешиваемых классов
• Конструирование меню и панелей инструментов из шаблонных структур данных
• Добавление графических интерфейсов к инструментам командной строки
• Перенаправление потоков ввода-вывода в виджеты
• Динамическая переустановка обработчиков графического интерфейса
• Обертывание и автоматизация интерфейсов окон верхнего уровня
• Применение потоков выполнения и очередей для устранения блокирования графических интерфейсов
• Создание всплывающих окон в программах, не имеющих графического интерфейса
• Добавление графических интерфейсов в виде отдельных программ, подключаемых через сокеты и каналы
Как и другие главы этой книги, данная глава преследует двойную цель - не только изучение программирования графических интерфейсов, но и изучение более общих понятий программирования на языке Python, таких как объектно-ориентированное программирование (ООП) и повторное использование программного кода. Как мы увидим далее, создавая инструменты для работы с графическими интерфейсами на языке Python, мы упрощаем их применение в самых разных контекстах и программах.
Для связки со следующей главой эта глава завершается знакомством с панелями запуска PyDemos и PyGadgets - графических интерфейсов, используемых для запуска демонстрационных примеров. В книге приводится лишь малая часть этих программ, тем не менее мы рассмотрим их структуру достаточно подробно, чтобы вы могли самостоятельно исследовать их, отыскав в пакете с примерами.
Два предварительных замечания: во-первых, обязательно читайте программный код в листингах, выясняя подробности, отсутствующие в описании. Во-вторых, несмотря на небольшой объем примеров в этой главе, они демонстрируют приемы, которые найдут практическое применение в более реалистичных программах. Мы будем использовать эти приемы в более крупных примерах в следующей главе и на протяжении всей оставшейся части книги. Фактически разработанные здесь модули мы часто будем повторно использовать как инструменты в других программах из этой книги - программное обеспечение многократного использования должно использоваться снова и снова. Но для начала давайте приложим максимум усилий и создадим некоторые инструменты.
GuiMixin: универсальные подмешиваемые классы
Если вы читали предыдущие три главы, то наверняка заметили, что программный код, конструирующий нетривиальный графический интерфейс, может быть очень длинным, если каждый виджет создавать вручную. Приходится не только вручную связывать все виджеты, но нужно помнить десятки параметров, которые должны быть установлены. При такой стратегии программирование графических интерфейсов часто становится упражнением по вводу с клавиатуры и и выполнению операций копирования и вставки в текстовом редакторе.
Функции создания виджетов
Вместо того чтобы выполнять все операции вручную, правильнее было бы создать оболочку или как-то иначе максимально автоматизировать процесс построения графического интерфейса. Одним из решений является создание функций, обеспечивающих создание виджетов с типичными настройками и автоматизирующих процесс конструирования. Например, можно было бы определить функцию создания кнопки, реализующую все тонкости настройки и поддерживающую большинство необходимых нам кнопок. В примере 10.1 демонстрируется группа таких функций, создающих виджеты.
Пример 10.1. PP4E\Gui\Tools\widgets.py
##############################################################################
функции-обертки, упрощающие создание виджетов и опирающиеся на некоторые допущения (например, режим растягивания); используйте словарь **extras именованных аргументов для передачи таких параметров настройки, как ширина, шрифт/цвет и других, и повторно компонуйте возвращаемые виджеты, если компоновка по умолчанию вас не устраивает;
##############################################################################
from tkinter import *
def frame(root, side=TOP, **extras): widget = Frame(root)
widget.pack(side=side, expand=YES, fill=BOTH) if extras: widget.config(**extras) return widget
def label(root, side, text, **extras):
widget = Label(root, text=text, relief=RIDGE) # настройки по умолчанию widget.pack(side=side, expand=YES, fill=BOTH) # компонуется автоматически if extras: widget.config(**extras) # применить все
return widget # дополнительные параметры
def button(root, side, text, command, **extras):
widget = Button(root, text=text, command=command) widget.pack(side=side, expand=YES, fill=BOTH) if extras: widget.config(**extras) return widget
def entry(root, side, linkvar, **extras):
widget = Entry(root, relief=SUNKEN, textvariable=linkvar) widget.pack(side=side, expand=YES, fill=BOTH) if extras: widget.config(**extras) return widget
if__name__== ‘__main__’:
app = Tk()
frm = frame(app, TOP) # программного кода теперь требуется намного меньше! label(frm, LEFT, ‘SPAM’)
button(frm, BOTTOM, ‘Press’, lambda: print(‘Pushed’)) mainloop()
Этот модуль опирается на некоторые допущения, касающиеся его использования клиентами, и обеспечивает автоматизацию типичных последовательностей операций конструирования виджетов, такие как размещение методом pack. В результате применение этого модуля позволяет уменьшить объем программного кода в импортирующих его программах. Если запустить модуль из примера 10.1 как самостоятельный сценарий, он создаст простое окно с меткой в выступающей рамке слева и с кнопкой справа, в случае щелчка на которой в поток stdout выводится сообщение. Оба виджета растягиваются вместе с окном. Запустите этот пример у себя - его окно действительно не содержит ничего нового для нас, а его программный код организован скорее как библиотека, чем сценарий, который позднее будет повторно использоваться в программе PyCalc, в главе 19.
Такое решение, основанное на функциях, может сократить объем необходимого программного кода. Однако функции не обеспечивают возможность специализации, как это позволяют классы при объектноориентированном подходе. Кроме того, они не являются методами и не обладают доступом к информации о состоянии объекта, представляющего элемент графического интерфейса.
Вспомогательные подмешиваемые классы
Другим способом может быть реализация общих методов в классе и наследование их при необходимости. Такие классы обычно называют подмешиваемыми (mixin), потому что их методы «подмешиваются» в другие классы. Подмешиваемые классы служат своего рода пакетами полезных во многих случаях инструментов, оформленных в виде методов. Эта идея близка к импортированию модулей, однако подмешиваемые классы могут обращаться к конкретному экземпляру, self, используя состояние конкретного объекта и унаследованные методы. Сценарий в примере 10.2 демонстрирует, как это делается.
Пример 10.2. PP4E\Gui\Tools\guimixin.py
##############################################################################
класс, "подмешиваемый” во фреймы: реализует общие методы вызова стандартных диалогов, запуска программ, простых инструментов отображения текста и так далее; метод quit требует, чтобы этот класс подмешивался к классу Frame (или его производным)
############################################################################## from tkinter import *
from tkinter.messagebox import *
from tkinter.filedialog import *
from PP4E.Gui.Tour.scrolledtext import ScrolledText # или tkinter.scrolledtext from PP4E.launchmodes import PortableLauncher, System # или используйте модуль
# multiprocessing
class GuiMixin:
def infobox(self, title, text, *args): # используются стандартные диалоги return showinfo(title, text) # *args для обратной совместимости
def errorbox(self, text): showerror(‘Error!’, text)
def question(self, title, text, *args):
return askyesno(title, text) # вернет True или False
def notdone(self):
showerror(‘Not implemented’, ‘Option not available’)
def quit(self):
ans = self.question(‘Verify quit’, ‘Are you sure you want to quit?’) if ans:
Frame.quit(self) # нерекурсивный вызов quit!
def help(self): # переопределите более
self.infobox(‘RTFM’, ‘See figure 1...’) # подходящим
def selectOpenFile(self, file=””, dir=”.”): # испол-ся стандартные диалоги return askopenfilename(initialdir=dir, initialfile=file)
def selectSaveFile(self, file=””, dir=”.”):
return asksaveasfilename(initialfile=file, initialdir=dir)
def clone(self, args=()): # необязательные аргументы конструктора
new = Toplevel() # создать новую версию
myclass = self.__class__ # объект класса экземпляра (самого низшего)
myclass(new, *args) # прикрепить экземпляр к новому окну
def spawn(self, pycmdline, wait=False):
if not wait: # запустить новый процесс
PortableLauncher(pycmdline, pycmdline)() # запустить программу else:
System(pycmdline, pycmdline)() # ждать ее завершения
def browser(self, filename):
new = Toplevel() # создать новое окно
view = ScrolledText(new, file=filename) # Text с полосой прокрутки view.text.config(height=30, width=85) # настроить Text во фрейме view.text.config(font=(‘courier’, 10, ‘normal’)) # моноширинный шрифт
new.title("Text Viewer”) # атрибуты менеджера окон
new.iconname(“browser”) # текст из файла будет
# вставлен автоматически
def browser(self, filename): # на случай, если импортирован new = Toplevel() # модуль tkinter.scrolledtext
text = ScrolledText(new, height=30, width=85) text.config(font=(‘courier’, 10, ‘normal’)) text.pack(expand=YES, fill=BOTH) new.title(“Text Viewer”) new.iconname(“browser”)
text.insert(‘0.0’, open(filename, ‘ r').read() ) if__name__== ‘__main__’:
class TestMixin(GuiMixin, Frame): # автономный тест
def __init__(self, parent=None):
Frame.__init__(self, parent)
self.pack()
Button(self, text=’quit’, command=self.quit).pack(fill=X)
Button(self, text=’help’, command=self.help).pack(fill=X)
Button(self, text=’clone’, command=self.clone).pack(fill=X) Button(self, text=’spawn’, command=self.other).pack(fill=X) def other(self):
self.spawn(‘guimixin.py’) # запустить себя в отдельном процессе
TestMixin().mainloop()
Хотя пример 10.2 и ориентирован на графические интерфейсы, кроме этого он иллюстрирует архитектурные идеи. Класс GuiMixin реализует обычные операции со стандартными интерфейсами, которые не подвержены влиянию возможных изменений в реализации. На деле реализации некоторых методов этого класса все-таки изменились - при переходе от первого ко второму изданию этой книги вызовы функций из устаревшего модуля Dialog были заменены вызовами новых стандартных диалогов Tk; в четвертом издании изменился компонент для просмотра содержимого текстовых файлов и он теперь использует другой класс текстового виджета с прокруткой. Так как интерфейс класса в примере скрывает подобные детали, отпадает необходимость изменять использующие его программы, чтобы сделать доступными в них новые приемы.
В данном виде класс GuiMixin предоставляет методы для вызова стандартных диалогов, клонирования окон, запуска программ, просмотра текстовых файлов и так далее. Позднее, если обнаружится, что одни и те же методы приходится писать снова и снова, их можно будет добавить в такой подмешиваемый класс, и они немедленно станут доступны везде, где импортируется и внедряется этот класс. Более того, методы класса GuiMixin можно наследовать и использовать в существующем
виде либо переопределять в подклассах. Таковы естественные преимущества классов перед функциями.
Здесь есть несколько тонкостей, которые следует отметить особо:
• Метод quit выполняет отчасти ту же задачу, что и кнопка многократного использования Quitter в предыдущих главах. Так как в подмешиваемых классах могут определяться большие библиотеки многократно используемых методов, они обеспечивают более мощный способ упаковки многократно используемых компонентов, чем отдельные классы. При правильном применении подмешиваемый класс может дать значительно больше, чем обработчик единственной кнопки.
• Метод clone создает новый экземпляр самого нижнего в иерархии класса, который подмешивает класс GuiMixin, в новом окне верхнего
уровня (self.__class__- это объект класса, из которого был создан
экземпляр). Предполагается, что конструктор класса не требует никаких других аргументов, кроме ссылки на родительский контейнер. Он открывает новый независимый экземпляр окна (и передает конструктору любые дополнительные аргументы).
• Метод browser открывает в новом окне объект ScrolledText, который мы создали в главе 9, и заполняет его текстом из файла, который нужно просмотреть. Как отмечалось в предыдущей главе, существует также стандартный виджет ScrolledText, находящийся в модуле tkinter.scrolledtext, но он имеет иной интерфейс, не загружает содержимое файла автоматически и, возможно, будет объявлен устаревшим (хотя этого не происходит уже многие годы). Для справки в класс включена реализация метода, использующая этот виджет.
• Метод spawn запускает программу на языке Python в новом процессе и либо ждет его завершения, либо нет (в зависимости от аргумента wait, со значением по умолчанию False - обычно графический интерфейс не должен ждать завершения дочерней программы). Этот метод прост потому, что тонкости запуска скрыты в модуле launchmodes, представленном в конце главы 5. Класс GuiMixin способствует применению и сам применяет на практике приемы повторного использования программного кода.
Назначение класса GuiMixin состоит в том, чтобы служить библиотекой многократно используемых инструментальных методов, и как самостоятельный класс он, в сущности, бесполезен. В действительности для использования его нужно подмешивать в классы, наследующие класс Frame: метод quit предполагает, что он смешивается с классом Frame, а метод clone предполагает, что он смешивается с классом виджета. Чтобы удовлетворить этим ограничениям, находящаяся в конце реализация самотестирования объединяет класс GuiMixin с виджетом Frame.
На рис. 10.1 изображена картина, которая возникает при самотестировании после щелчка на кнопках cLone и spawn, а затем на кнопке heLp в одной из трех копий окна. Поскольку щелчок на кнопке spawn запускает отдельный процесс, окно, созданное таким способом, остается на экране после закрытия всех остальных окон, а его закрытие не оказывает влияния на другие окна. Окно, созданное щелчком на кнопке cLone, напротив, закрывается при закрытии главного окна, однако щелчок на кнопке X в копии окна закрывает только это окно. Не забудьте включить путь к каталогу PP4E в переменную окружения PYTHONPATH, чтобы обеспечить возможность импортирования пакетов в этом и в последующих примерах.
Рис. 10.1. Реализация самотестирования класса GuiMixin в действии
Мы снова встретимся с классом GuiMixin в роли подмешиваемого класса в последующих примерах - в конце концов, в этом весь смысл повторного использования кода. Хотя функции часто бывают полезными, тем не менее поддержка наследования классами, возможность доступа к информации в экземпляре и обеспечение дополнительной организационной структуры оказываются особенно полезными при создании графических интерфейсов. Например, если многие методы класса Gui-Mixin можно было бы заменить простыми функциями, то методы clone и quit - нет. В следующем разделе рассматриваются еще более широкие возможности подмешиваемых классов.
GuiMaker: автоматизация создания меню и панелей инструментов
Подмешиваемый класс из предыдущего раздела упрощает выполнение стандартных задач, но не решает проблем сложности связывания в таких виджетах, как меню и панели инструментов. Конечно, при наличии инструмента структурирования графического интерфейса, который генерировал бы программный код на языке Python, проблем бы не было. Мы бы проектировали виджеты интерактивно, нажимали кнопку и добавляли бы реализацию обработчиков.
Однако при использовании такого относительно простого инструмента, как tkinter, сгодится и подход, основанный на программировании. Хотелось бы иметь возможность, имея в окне шаблон для меню и панелей инструментов, наследовать некоторый класс, который сам выполнял бы всю черновую работу по конструированию. Ниже демонстрируется один из возможных способов, использующий деревья простых объектов. Класс в примере 10.3 интерпретирует структуры данных, содержащих представление меню и панелей инструментов, и автоматически создает необходимые виджеты.
Пример 10.3. PP4E\Gui\Tools\guimaker.py
##############################################################################
Расширенный Frame, автоматически создающий меню и панели инструментов в окне.
GuiMakerFrameMenu предназначен для встраивания компонентов (создает меню на
основе фреймов).
GuiMakerWindowMenu предназначен для окон верхнего уровня (создает меню Tk8.0).
Пример древовидной структуры приводится в реализации самотестирования (и
в PyEdit).
##############################################################################
import sys
from tkinter import * # классы виджетов
from tkinter.messagebox import showinfo
class GuiMaker(Frame):
menuBar = [] # значения по умолчанию
toolBar = [] # изменять при создании подклассов
helpButton = True # устанавливать в start()
def __init__(self, parent=None):
Frame.__init__(self, parent)
self.pack(expand=YES, fill=BOTH) # растягиваемый фрейм self.start() # в подклассе: установить меню/панель инстр.
self.makeMenuBar() # здесь: создать полосу меню
self.makeToolBar() # здесь: создать панель инструментов
self.makeWidgets() # в подклассе: добавить середину
def makeMenuBar(self):
создает полосу меню вверху (реализация меню Tk8.0 приводится ниже) expand=no, fill=x, чтобы ширина оставалась постоянной
menubar = Frame(self, relief=RAISED, bd=2) menubar.pack(side=TOP, fill=X)
for (name, key, items) in self.menuBar:
mbutton = Menubutton(menubar, text=name, underline=key)
mbutton.pack(side=LEFT)
pulldown = Menu(mbutton)
self.addMenuItems(pulldown, items)
mbutton.config(menu=pulldown)
if self.helpButton:
Button(menubar, text = ‘Help’, cursor = ‘gumby’, relief = FLAT,
command = self.help).pack(side=RIGHT)
def addMenuItems(self, menu, items):
for item in items: # сканировать список вложенных элем.
if item == ‘separator’: # строка: добавить разделитель
menu.add_separator({})
elif type(item) == list: # список: неактивных элементов for num in item:
menu.entryconfig(num, state=DISABLED) elif type(item[2]) != list:
menu.add_command(label = item[0], # команда: метка
underline = item[1], # горячая клавиша
command = item[2]) # обр-к: вызыв. объект
else:
pullover = Menu(menu)
self.addMenuItems(pullover, item[2]) # подменю: menu.add_cascade(label = item[0], # создать подменю
underline = item[1], # добавить каскад
menu = pullover)
def makeToolBar(self):
создает панель с кнопками внизу, если необходимо
expand=no, fill=x, чтобы ширина оставалась постоянной
можно добавить поддержку изображений: смотрите главу 9,
для чего придется создать минатюры в формате FIF или использовать
расширение PIL
if self.toolBar:
toolbar = Frame(self, cursor=’hand2’, relief=SUNKEN, bd=2)
toolbar.pack(side=BOTTOM, fill=X)
for (name, action, where) in self.toolBar:
Button(toolbar, text=name, command=action).pack(where)
def makeWidgets(self):
‘средняя’ часть создается последней, поэтому меню/панель инструменто всегда остаются вверху/внизу и обрезаются в последнюю очередь;
переопределите этот метод,
для pack: прикрепляйте середину к любому краю;
для grid: компонуйте середину по сетке во фрейме, который
прикрепляется методом pack
name = Label(self,
width=40, height=10, relief=SUNKEN, bg=’white’,
text = self.__class__.__name__,
cursor = ‘crosshair’)
name.pack(expand=YES, fill=BOTH, side=TOP)
def help(self):
“переопределите в подклассе”
showinfo(‘Help’, ‘Sorry, no help for ‘ + self.__class__.__name__)
def start(self):
“переопределите в подклассе: связать меню/панель инструментов с self” pass
##############################################################################
# Специализированная версия для полосы меню главного окна Tk 8.0 ##############################################################################
GuiMakerFrameMenu = GuiMaker # используется для меню встраиваемых
# компонентов
class GuiMakerWindowMenu(GuiMaker): # используется для меню окна def makeMenuBar(self): # верхнего уровня
menubar = Menu(self.master) self.master.config(menu=menubar)
for (name, key, items) in self.menuBar: pulldown = Menu(menubar) self.addMenuItems(pulldown, items)
menubar.add_cascade(label=name, underline=key, menu=pulldown)
if self.helpButton:
if sys.platform[:3] == ‘win’:
menubar.add_command(label=’Help’, command=self.help) else:
pulldown = Menu(menubar) # В Linux требуется настоящее меню pulldown.add_command(label=’About’, command=self.help) menubar.add_cascade(label=’Help’, menu=pulldown)
##############################################################################
# Реализация самотестирования, которая выполняется, если запустить модуль как
# самостоятельный сценарий: ‘python guimaker.py’ ##############################################################################
if__name__== ‘__main__’:
from guimixin import GuiMixin # встроить метод help
menuBar = [
(‘File’, 0,
[(‘Open’, 0, lambda:0), # lambda:0 - пустая операция (‘Quit’, 0, sys.exit)]), # здесь использовать sys, а не self (‘Edit’, 0,
[(‘Cut’, 0, lambda:0),
(‘Paste’, 0, lambda:0)]) ] toolBar = [(‘Quit’, sys.exit, {‘side’: LEFT})]
class TestAppFrameMenu(GuiMixin, GuiMakerFrameMenu): def start(self):
self.menuBar = menuBar self.toolBar = toolBar
class TestAppWindowMenu(GuiMixin, GuiMakerWindowMenu): def start(self):
self.menuBar = menuBar self.toolBar = toolBar
class TestAppWindowMenuBasic(GuiMakerWindowMenu): def start(self):
self.menuBar = menuBar
self.toolBar = toolBar # help из GuiMaker, а не из GuiMixin root = Tk()
TestAppFrameMenu(Toplevel())
TestAppWindowMenu(Toplevel())
TestAppWindowMenuBasic(root)
root.mainloop()
Чтобы понять принцип действия этого модуля, необходимо знакомство с основами создания меню, изложенными в главе 9. При соблюдении этого условия программный код будет прост и понятен: класс GuiMaker просто выполняет обход структур с описанием меню и панели инструментов и попутно создает соответствующие виджеты. В реализацию самотестирования этого модуля включен простой пример структур данных, использованных для компоновки меню и панели инструментов:
Шаблоны меню
Списки и вложенные подсписки кортежей (метка, горячая_клави-ша, обработчик). Если обработчик является подсписком, а не функцией или методом, предполагается, что это каскадное подменю.
Шаблоны панелей инструментов
Список кортежей (метка, обработчик, параметры_компоновки). Параметры компоновки определяются в виде словаря параметров, передаваемых методу pack виджета, - словарь можно записать в виде литерала {‘k’:v} или использовать вызов функции dict(k=v) с именованными аргументами. Метод pack принимает словари, однако словари можно трансформировать в именованные аргументы, используя синтаксис вызова func(**kargs). В данной реализации метки определяются как текст, но точно так же можно было бы реализовать поддержку изображений (смотрите раздел «BigGui: клиентская демонстрационная программа» ниже)
Для разнообразия предусмотрено изменение внешнего вида указателя мыши в зависимости от его местоположения: при наведении на панель инструментов указатель приобретает вид руки, в средней части - вид перекрестия, а при наведении на кнопку Help в меню, основанном на фрейме, - другой вид (можете настроить по вашему желанию).
Протоколы подклассов
Помимо структур меню и панелей инструментов клиенты этого класса могут вмешиваться и изменять реализованные в нем методы и протоколы компоновки:
Атрибуты, шаблона
Предполагается, что клиенты этого класса установят атрибуты menuBar и toolBar в каком-то месте в цепочке наследования до момента завершения метода start.
Инициализация
Метод start может переопределяться для динамического создания шаблонов меню и панели инструментов, поскольку ему доступна ссылка self. Метод start служит также местом, где осуществляется общая инициализация - конструктор__init__класса GuiMixin дол
жен вызываться, но не переопределяться.
Добавление виджетов
Метод makeWidgets может быть переопределен и создает виджеты в средней части окна - между полосой меню и панелью инструментов. По умолчанию makeWidgets помещает в середине метку с именем ближайшего класса, но по сути это абстрактный метод и предполагается его специализация в подклассах.
Протокол компоновки методом pack
В специализированном методе makeWidgets клиенты могут прикреплять виджеты средней части к любому краю self (Frame), так как полоса меню и панель инструментов уже захватили верх и низ контейнера к моменту выполнения makeWidgets. Если виджеты, составляющие среднюю часть, компонуются с помощью метода pack, она не обязательно должна быть вложенным фреймом. Полоса меню и панель инструментов автоматически компонуются первыми, чтобы при сжатии окна они обрезались в последнюю очередь.
Протокол компоновки методом grid
Размещение виджетов в средней части может осуществляться по сетке, если эта сетка помещена во вложенный фрейм, который добавляется в родительский контейнер self. (Напомню, что на каждом уровне контейнеров можно применять любой из методов, grid или pack, но не оба вместе, а self является фреймом, в котором к моменту вызова makeWidgets меню и панель инструментов уже скомпонованы с применением метода pack.) Так как фрейм GuiMaker сам компонует себя в родительском контейнере с помощью метода pack, по аналогичным причинам его нельзя непосредственно встраивать в контейнер с элементами, располагаемыми по сетке, - для использования его в таком контексте добавьте промежуточный фрейм с сеткой.
Классы GuiMaker
В ответ на выполнение условий по протоколам и шаблонам GuiMaker клиентские подклассы получают фрейм, который умеет автоматически строить свои меню и панели инструментов по структурам данных шаблона. Если вы смотрели примеры создания меню в предыдущих главах, то сможете понять, что это большой шаг вперед, в смысле уменьшения объема программного кода. Класс GuiMaker также достаточно сообразителен и может экспортировать интерфейсы меню обоих стилей, с которыми мы встречались в главе 9:
GuiMakerWindowMenu
Реализует меню окон верхнего уровня в стиле Tk 8.0, которые удобно использовать в самостоятельных программах и всплывающих окнах.
GuiMakerFrameMenu
Реализует альтернативные меню, основанные на виджетах Frame/ Menubutton, которые удобно использовать для создания меню объектов, встраиваемых в виде компонентов в более крупные графические интерфейсы.
Оба класса создают панели инструментов, экспортируют одни и те же протоколы и ожидают получить одни и те же структуры шаблонов - они отличаются только способом обработки шаблонов меню. В действительности один из них является подклассом другого, специализирующим метод создания меню - два стиля отличаются только обработкой меню верхнего уровня (Menu с каскадами Menu, вместо Frame с Menubuttons).
Программный код самотестирования GuiMaker
Как и в случае с классом GuiMixin, если запустить пример 10.3 как самостоятельный сценарий, будет выполнена логика самотестирования, находящаяся в конце файла. На рис. 10.2 изображены получаемые при этом окна. На экране создаются три окна, представляющие классы TestApp. Все три окна имеют меню и панель инструментов, параметры которых определены в структурах данных шаблонов, создаваемых программным кодом самотестирования: раскрывающиеся меню File и Edit,
Рис. 10.2. Программный код самотестирования GuiMaker в действии
а также кнопка панели инструментов Quit и стандартная кнопка меню HeLp. На рисунке меню FiLe одного из окон оторвано, а меню Edit другого окна раскрыто. Нижнее окно растянуто для наглядности.
Класс GuiMaker можно смешивать с другими суперклассами, но в первую очередь он предназначен служить тем же целям расширения и встраивания, что и класс Frame из библиотеки tkinter (особенно если учесть, что в действительности он является специализированным классом Frame, реализующим дополнительные протоколы конструирования). Фактически программный код самотестирования объединяет фрейм GuiMaker с инструментами из класса GuiMixin, представленного в предыдущем разделе.
Связи между суперклассами устанавливаются в программном коде так, что два из трех окон получают обработчик help из класса GuiMix-in, а TestAppWindowMenuBasic получает его из класса GuiMaker. Обратите внимание, что порядок, в котором смешиваются эти два класса, имеет большое значение: так как метод quit определен в обоих классах, Gui-Mixin и Frame, класс, от которого мы хотим его получить, нужно указать первым в строке заголовка смешанного класса, поскольку при множественном наследовании поиск производится слева направо. Чтобы обеспечить преимущество методов класса GuiMixin, его следует указывать перед суперклассом, производным от виджетов.
Более практическое применение класс GuiMaker найдет в таких примерах, как PyEdit в главе 11. В следующем разделе демонстрируется другой способ использования шаблонов класса GuiMaker для построения усложненного интерфейса, который служит еще одной проверкой его функциональных возможностей.
BigGui: клиентская демонстрационная программа
Рассмотрим программу, представляющую лучшее применение тех двух классов автоматизации, которые мы написали. Класс Hello, реализованный в примере 10.4, является наследником обоих классов, GuiMixin и GuiMaker. Класс GuiMaker обеспечивает связь с виджетом Frame и логику создания меню/панели инструментов. Класс GuiMixin обеспечивает дополнительные методы стандартного поведения. В действительности класс Hello служит образцом еще одного способа расширения виджета Frame, поскольку является производным от класса GuiMaker. Чтобы бесплатно получить меню и панель инструментов, он просто следует протоколам, определенным в классе GuiMaker, - устанавливает атрибуты menuBar и toolBar в методе start и переопределяет метод makeWidgets, помещая в середину нестандартную метку.
Пример 10.4. PP4E\Gui\Tools\big_gui.py
реализация графического интерфейса - объединяет GuiMaker, GuiMixin и данный класс
import sys, os
from tkinter import * # классы виджетов
from PP4E.Gui.Tools.guimixin import * # подмешиваемые методы: quit, spawn...
from PP4E.Gui.Tools.guimaker import * # фрейм плюс построение меню/панели
# инструментов
class Hello(GuiMixin, GuiMakerWindowMenu): # или GuiMakerFrameMenu
def start(self): self.hellos = 0
self.master.title("GuiMaker Demo”) self.master.iconname(“GuiMaker”)
def spawnme(): self.spawn(‘big_gui.py’) # отложен. вызов вместо lambda
self.menuBar = [ # дерево: 3 раскр. меню
(‘File’, 0, # (раскр. меню)
[(‘New...’, 0, spawnme),
(‘Open...’, 0, self.fileOpen), # [список элементов меню]
(‘Quit’, 0, self.quit)] # метка,клавиша,обработчик
),
(‘Edit’, 0,
[(‘Cut’, -1, self.notdone), # без клавиши| обработчика
(‘Paste’, -1, self.notdone), # lambda:0 тоже можно
‘separator’, # добавить разделитель
(‘Stuff’, -1,
[(‘Clone’, -1, self.clone),# каскадное подменю (‘More’, -1, self.more)]
),
(‘Delete’, -1, lambda:0),
[5]] # отключить ‘delete’
),
(‘Play’, 0,
[(‘Hello’, 0, self.greeting),
(‘Popup...’, 0, self.dialog),
(‘Demos’, 0,
[(‘Toplevels’, 0,
lambda: self.spawn(r’..\Tour\toplevel2.py’)),
(‘Frames’, 0,
lambda: self.spawn(r’..\Tour\demoAll-frm-ridge.py’)), (‘Images’, 0,
lambda: self.spawn(r’..\Tour\buttonpics.py’)),
(‘Alarm’, 0,
lambda: self.spawn(r’..\Tour\alarm.py’, wait=False)), (‘Other...’, -1, self.pickDemo)]
)]
)]
self.toolBar = [ # добавить 3 кнопки
(‘Quit’, self.quit, dict(side=RIGHT)), # или {‘side’: RIGHT} (‘Hello’, self.greeting, dict(side=LEFT)),
(‘Popup’, self.dialog, dict(side=LEFT, expand=YES)) ]
def makeWidgets(self): # переопределить метод
middle = Label(self, text=’Hello maker world!’, # создания виджетов width=40, height=10, # в середине окна
relief=SUNKEN, cursor=’pencil’, bg=’white’) middle.pack(expand=YES, fill=BOTH)
def greeting(self): self.hellos += 1 if self.hellos % 3: print(“hi”) else:
self.infobox(“Three”, ‘HELLO!’) # каждый третий щелчок
def dialog(self):
button = self.question(‘OOPS!’,
‘You typed “rm*” ... continue?’, # старый стиль ‘questhead’, (‘yes’, ‘no’)) # аргументы
[lambda: None, self.quit][button]() # игнорируются
def fileOpen(self):
pick = self.selectOpenFile(file=’big_gui.py’)
if pick:
self.browser(pick) # просмотр файла модуля или другого файла
def more(self):
new = Toplevel()
Label(new, text=’A new non-modal window’).pack()
Button(new, text=’Quit’, command=self.quit).pack(side=LEFT)
Button(new, text=’More’, command=self.more).pack(side=RIGHT)
def pickDemo(self):
pick = self.selectOpenFile(dir=’..’) if pick:
self.spawn(pick) # запустить любую программу Python
if __name__ == ‘__main__’: Hello().mainloop() # создать, запустить
Этот сценарий создает довольно объемное меню и панель инструментов, а также добавляет собственные методы обратного вызова, которые выводят сообщения в поток stdout, отображают средства просмотра текстовых файлов и новые окна и запускают другие программы. Однако многие из этих методов не делают ничего, кроме запуска метода not-Done, унаследованного от класса GuiMixin. Данный пример предназначен в основном для демонстрации возможностей классов GuiMaker и GuiMixin.
Если запустить big_gui как самостоятельный сценарий, он создаст окно с четырьмя раскрывающимися меню вверху и панелью инструментов с тремя кнопками внизу, как показано на рис. 10.3, где также изображены некоторые всплывающие окна, созданные обработчиками. В меню имеются разделители, неактивные элементы и каскадные подменю в полном соответствии с шаблоном menuBar, который передается классу GuiMaker, и кнопка Quit, унаследованная от класса GuiMixin, щелчок на которой вызывает появление диалога с просьбой подтвердить завершение работы. И это лишь часть инструментов, которые мы бесплатно получаем в свое распоряжение.
На рис. 10.4 снова изображено окно этого сценария после того как через раскрывающееся меню Play были запущены два демонстрационных сценария, которые мы написали в главах 8 и 9, выполняющиеся независимо. Эти демонстрационные сценарии были запущены с помощью переносимых инструментов, которые мы написали в главе 5 и приобрели из класса GuiMixin. Если у вас появится желание запустить какую-либо другую демонстрационную программу, выберите пункт Other в меню PLay, который откроет стандартный диалог открытия файла, и выберите файл требуемой программы. Примечание: изображение ярлыка, используемое демонстрационным сценарием, запуск которого производится из меню Play, я скопировал в каталог с этим сценарием - позднее мы напишем инструменты, которые будут пытаться отыскивать его автоматически.
Наконец, хочу заметить, что класс GuiMaker можно перепроектировать так, чтобы в нем использовались деревья вложенных экземпляров классов, умеющих применять себя к строящемуся дереву виджетов tkinter вместо ветвления по типам элементов в структурах данных шаблона. Однако ввиду недостатка места в данном издании мы отнесем это расширение к числу самостоятельных упражнений.
Рис. 10.3. Сценарий big_gui с несколькими всплывающими окнами
Рис. 10.4. Сценарий big_gui и несколько запущенных им демонстрационных программ
Коль скоро речь зашла о расширениях, - в главе 9 я демонстрировал, как вместо текстовых меток помещать на кнопки в панели инструментов изображения. Создание подкласса, наследующего класс GuiMaker, реализующего такую возмож-
ность за счет переопределения метода создания панели инструментов, стало бы не только отличным упражнением, но и позволило бы получить полезный инструмент. Однако если я буду добавлять реализацию каждой такой особенности, эта книга может разрастись настолько, что превратится в неподъемный груз...
ShellGui: графические интерфейсы к инструментам командной строки
Демонстрационные программы - это здорово, но, чтобы явственнее продемонстрировать практическую пользу таких инструментов, как класс GuiMixin, требуется найти ему более реальное применение. Вот одно из них: допустим, что мы написали комплект сценариев командной строки для решения административных задач, например, таких, как мы написали во второй части книги. Там, если помните, сценарии запускались из командной строки, но требовали от нас запоминать все параметры, которые можно передавать им при запуске, - для меня (и, вероятно, для вас) это означает, что при обращении к сценариям после долгого перерыва потребуется детально изучить их программный код.
Вместо того чтобы требовать от пользователей таких инструментов вводить загадочные команды в оболочке, почему бы для запуска этих программ не создать простой в использовании графический интерфейс на базе tkinter? Такой интерфейс мог бы запрашивать параметры командной строки, не требуя, чтобы пользователь помнил их. И если мы ставим такую задачу, почему бы вообще не обобщить идею запуска инструментов командной строки из графического интерфейса для обеспечения поддержки инструментов, которые появятся в будущем?
Обобщенный графический интерфейс инструментов оболочки
Примеры с 10.5 по 10.11 - два сценария командной строки, один вспомогательный модуль для реализации графического интерфейса, два диалога, главный графический интерфейс и модуль формы ввода параметров - представляют конкретную реализацию этих абстрактных размышлений. Так как я хотел, чтобы это был инструмент общего назначения, способный запустить любую программу командной строки, его конструкция разбита на модули, которые становятся все более специфическими для приложений по мере углубления в иерархию программного обеспечения. А на самом верху все должно быть максимально универсальным, как показано в примере 10.5.
Пример 10.5. PP4E\Gui\ShettGui\shettguipy
#!/usr/local/bin/python
##############################################################################
инструмент запуска; использует шаблоны GuiMaker, стандартный диалог завершения GuiMixin; это просто библиотека классов: чтобы вывести графический интерфейс, запустите сценарий mytools;
##############################################################################
from tkinter import * # импортировать виджеты
from PP4E.Gui.Tools.guimixin import GuiMixin # импортировать quit, а не done
from PP4E.Gui.Tools.guimaker import * # конструктор меню/панели
# инструментов
class ShellGui(GuiMixin, GuiMakerWindowMenu): # фрейм + конструктор +
def start(self): # подмешиваемые методы
self.setMenuBar() # для компонентов использовать
self.setToolBar() # GuiMaker
self.master.title(“Shell Tools Listbox”)
self.master.iconname("Shell Tools”)
def handleList(self, event): # двойной щелчок на списке
label = self.listbox.get(ACTIVE) # получить выбранный текст
self.runCommand(label) # и выполнить операцию
def makeWidgets(self): # добавить список в середину
sbar = Scrollbar(self) # связать sbar со списком
list = Listbox(self, bg=’white’) # или использ. Tour.ScrolledList
sbar.config(command=list.yview) list.config(yscrollcommand=sbar.set)
sbar.pack(side=RIGHT, fill=Y) # первым добавлен = посл. обрезан
list.pack(side=LEFT, expand=YES, fill=BOTH) # список обрез-ся первым for (label, action) in self.fetchCommands(): # добавляется в список, list.insert(END, label) # в меню и на панель инстр.
list.bind(‘’, self.handleList) # установить обработчик self.listbox = list
def forToolBar(self, label): # поместить на панель инстр.?
return True # по умолчанию = все
def setToolBar(self): self.toolBar = []
for (label, action) in self.fetchCommands(): if self.forToolBar(label):
self.toolBar.append((label, action, dict(side=LEFT))) self.toolBar.append((‘Quit’, self.quit, dict(side=RIGHT)))
def setMenuBar(self):
toolEntries = [] self.menuBar = [
(‘File’, 0, [(‘Quit’, -1, self.quit)]), # имя раскрывающегося меню (‘Tools’, 0, toolEntries) # список элементов меню
] # метка,клавиша,обработчик
for (label, action) in self.fetchCommands():
toolEntries.append((label, -1, action)) # добавить приложения
# в меню
##############################################################################
# делегирование операций шаблонным подклассам с разным способом хранения
# перечня утилит, которые в свою очередь делегируют операции
# подклассам, реализующим запуск утилит
##############################################################################
class ListMenuGui(ShellGui):
def fetchCommands(self): # myMenu устанавливается в подклассе
return self.myMenu # список кортежей (метка, обработчик)
def runCommand(self, cmd):
for (label, action) in self.myMenu: if label == cmd: action()
class DictMenuGui(ShellGui): def fetchCommands(self):
return self.myMenu.items() def runCommand(self, cmd): self.myMenu[cmd]()
Класс ShellGui, находящийся в этом модуле, знает, как с помощью интерфейсов GuiMaker и GuiMixin создать окно для выбора, которое выводит имена утилит в меню, в списке с прокруткой и на панели инструментов. Он также предоставляет переопределяемый метод forToolBar, позволяющий подклассам указывать, какие утилиты должны добавляться на панель инструментов, а какие - нет (на панели инструментов может быстро закончиться свободное место). Однако он умышленно оставлен в неведении относительно имен утилит, которые должны быть выведены в указанных местах, и операций, которые должны быть выполнены при выборе имен утилит.
Вместо этого класс ShellGui использует подклассы ListMenuGui и DictMenu-Gui, находящиеся в этом же файле, чтобы получить список имен утилит через их методы fetchCommands и управлять операциями по именам с помощью их методов runCommand. Эти два подкласса в действительности лишь предоставляют интерфейс к наборам утилит, представленным в виде списков и словарей, - они по-прежнему не знают, какие имена утилит будут реально отображены в графическом интерфейсе. Это сделано умышленно: так как отображаемые наборы утилит определяются подклассами более низкого уровня, мы получаем возможность использовать класс ShellGui для отображения различных наборов утилит.
Классы наборов утилит
Чтобы получить фактические наборы утилит, нужно спуститься на один уровень ниже. Модуль в примере 10.6 определяет подклассы двух специфических по типу классов, наследующих класс ShellGui, чтобы предоставить наборы доступных инструментов в виде списка и словаря (обычно достаточно одного из них, но модуль иллюстрирует применение обоих). Кроме того, именно этот модуль запускает графический интерфейс - модуль shellgui является всего лишь библиотекой классов.
Пример 10.6. PP4E\Gui\ShellGui\mytools.py
#!/usr/local/bin/python
############################################################################## реализует два набора инструментов, специфичных для типов ##############################################################################
from shellgui import * # интерфейсы, специфичные для типов
from packdlg import runPackDialog # диалоги для ввода данных
from unpkdlg import runUnpackDialog # оба используют классы приложений
class TextPak1(ListMenuGui): def __init__(self):
self.myMenu = [(‘Pack ‘, runPackDialog), # простые функции
(‘Unpack’, runUnpackDialog), # длина меток одинаковая (‘Mtool ‘, self.notdone)] # метод из GuiMixin
ListMenuGui.__init__(self)
def forToolBar(self, label):
return label in {‘Pack ‘, ‘Unpack’} # синтаксис множеств в 3.x
class TextPak2(DictMenuGui): def __init__(self):
self.myMenu = {‘Pack ‘: runPackDialog, # или использовать input...
‘Unpack’: runUnpackDialog, # вместо диалогов ввода ‘Mtool ‘: self.notdone}
DictMenuGui.__init__(self)
if __name__ == ‘__main__’: # реализация самопроверки...
from sys import argv # ‘menugui.py list|^'
if len(argv) > 1 and argv[1] == ‘list’: print(‘list test’)
TextPak1().mainloop()
else:
print(‘dict test’)
TextPak2().mainloop()
Классы в этом модуле являются конкретными наборами утилит. Чтобы вывести другой набор имен утилит, нужно просто написать и использовать новый подкласс. Разделение логики приложения на такие отдельные подклассы и модули повышает возможность повторного использования программного обеспечения.
На рис. 10.5 изображено главное окно ShellGui, создаваемое при запуске сценария mytools с классом структуры меню на основе списка в Windows 7, а также оторванные меню, демонстрирующие свое содержание. Меню и панель инструментов этого окна построены с помощью класса GuiMaker, а кнопки Quit и HeLp и пункты меню, вызывающие методы quit и help, унаследованы из класса GuiMixin через суперклассы Shell-Gui модуля. Надеюсь, вы начинаете понимать, почему в этой книге столь часто проповедуется повторное использование программного кода?
Рис. 10.5. Элементы mytools в окне ShellGui
Добавление графических интерфейсов к инструментам командной строки
К настоящему моменту мы создали библиотеку универсальных инструментальных классов, а также модуль с комплектом инструментов для запуска конкретных приложений, который определяет имена обработчиков в пунктах меню. Чтобы закончить картину, нам необходимо теперь реализовать эти обработчики, а также сами сценарии, которые они будут запускать.
Сценарии командной строки
Для проверки способности графического интерфейса запускать сценарии командной строки нам, конечно же, необходимо создать несколько таких сценариев. Следующие два сценария, находящиеся в самом низу иерархии, реализуют архивацию текстовых файлов, используя системные инструменты и приемы, описанные во второй части книги. Первый сценарий, представленный в примере 10.7, просто объединяет содержимое нескольких текстовых файлов в один файл, добавляя предопределенные строки-разделители между ними.
Пример 10.7. PP4E\Gui\ShellGui\packer.py
# упаковывает текстовые файлы в единый файл, добавляя строки-разделители
# (простейшая архивация)
import sys, glob
marker = ‘:’ * 20 + ‘textpak=>’ # надеемся, что это уникальная строка
def pack(ofile, ifiles):
output = open(ofile, ‘w’) for name in ifiles:
print(‘packing:’, name)
input = open(name, ‘r’).read() # открыть следующий входной файл
if input[-1] != ‘\n’: input += ‘\n’ # гарантировать наличие \n в конце output.write(marker + name + ‘\n’) # записать строку-разделитель
output.write(input) # и содержимое входного файла
if__name__== ‘__main__’:
ifiles = []
for patt in sys.argv[2:]: # в Windows не выполняется автоматическая
ifiles += glob.glob(patt) # подстановка по шаблону pack(sys.argv[1], ifiles) # упаковать файлы, перечисленные
# в командной строке
Второй сценарий, который приводится в примере 10.8, сканирует файлы архивов, созданные первым сценарием, и восстанавливает оригинальные файлы.
Пример 10.8. PP4E\Gui\ShellGui\unpacker.py
# распаковывает архивы, созданные сценарием packer.py
# (простейшие архивы текстовых файлов)
import sys
from packer import marker # использовать общую строку-разделитель mlen = len(marker) # имена файлов следуют за строкой-разделителем
def unpack(ifile, prefix=’new-’):
for line in open(ifile): # по всем строкам входного файла
if line[:mlen] != marker:
output.write(line) # действительные строки записать
else:
name = prefix + line[mlen:-1] # или создать новый выходной файл print(‘creating:’, name) output = open(name, ‘w’)
if __name__ == ‘__main__’: unpack(sys.argv[1])
Это чрезвычайно простые сценарии, и в этой части книги предполагается, что вы уже прочитали главы, посвященные системным инструментам, поэтому мы не будем вдаваться в подробности их реализации. Варианты этих сценариев появились еще в первом издании этой книги, в 1996 году. Я пользовался ими на заре моей карьеры программиста на языке Python для архивации файлов, еще до того, как на всех моих компьютерах появились такие инструменты, как tar и zip (и еще до того, как в стандартной библиотеке Python появились модули поддержки tar и zip). Принцип действия этих сценариев чрезвычайно прост. Возьмем следующие три текстовых файла:
C:\...\PP4E\Gui\ShellGui> type spam.txt
spam
Spam
SPAM
C:\...\PP4E\Gui\ShellGui> type eggs.txt eggs
C:\...\PP4E\Gui\ShellGui> type ham.txt h
a
m
Если запустить сценарий packer из командной строки, он объединит эти файлы в один общий файл, а сценарий unpacker извлечет их оттуда. Сценарий packer должен предусматривать обработку шаблонов имен файлов, потому что командная оболочка в Windows не выполняет автоматическое расширение шаблонов:
C:\...\PP4E\Gui\ShellGui> packer.py packed.txt *.txt
packing: eggs.txt packing: ham.txt packing: spam.txt
C:\...\PP4E\Gui\ShellGui> unpacker.py packed.txt
creating: new-eggs.txt creating: new-ham.txt creating: new-spam.txt
Файлы, извлекаемые из архива, по умолчанию получают уникальные имена (с дополнительным префиксом, чтобы избежать случайного затирания оригинальных файлов, что особенно важно на этапе тестирования), и вы получаете то, что было упаковано в архив:
C:\...\PP4E\Gui\ShellGui> type new-spam.txt
spam
Spam
SPAM
C:\...\PP4E\Gui\ShellGui> type packed.txt ::::::::::::::::::::textpak=>eggs.txt
eggs
::::::::::::::::::::textpak=>ham.txt
h
a
m
::::::::::::::::::::textpak=>spam.txt
spam
Spam
SPAM
Эти сценарии не предназначены для архивации двоичных файлов, не выполняют сжатие или что-то еще, а служат лишь иллюстрацией сценариев командной строки с обязательными аргументами командной строки. Они могут использоваться самостоятельно, как было показано выше (и запускаться с помощью таких инструментов в языке Python, как os.popen и subprocess), или как модули, которые могут импортироваться и вызываться другими программами. В нашем графическом интерфейсе мы будем использовать второй, более прямой интерфейс вызовов.
Диалоги ввода
Нам осталось реализовать заключительную часть. Сценарии упаковывания и распаковывания прекрасно справляются со своей работой как инструменты командной строки. Однако обработчики, имена которых указаны в сценарии mytools.py из примера 10.6, должны делать нечто, ориентированное на использование графического интерфейса. Поскольку оригинальные сценарии packer и unpacker живут в мире текстовых потоков ввода-вывода и командных оболочек, нам необходимо обернуть их программным кодом, который будет принимать входные параметры из графического интерфейса. В частности, нам необходимы диалоги, запрашивающие обязательные аргументы командной строки.
В первую очередь рассмотрим модуль, представленный в примере 10.9, и клиентский сценарий в примере 10.10, который использует приемы создания модального диалога, рассматривавшиеся в главе 8, чтобы отобразить форму ввода параметров для сценария packer. Программный код в примере 10.9 был выделен в отдельный модуль, потому что он может найти более широкое применение. Фактически мы будем повторно использовать его в реализации диалога для сценария unpacker и еще раз - в приложении PyEdit, в главе 11.
Этот модуль демонстрирует еще один способ автоматизации конструирования графических интерфейсов - его использование для создания рядов формы ввода позволяет заменить 7 или более строк программного кода для каждого ряда (6 - если не использовать связанную переменную или кнопку вызова диалога выбора файла) ровно на 1 строку. В модуле form.py, в главе 12, мы увидим другой, еще более автоматизированный способ конструирования форм. Однако уже такой автоматизации вполне достаточно, чтобы сэкономить десятки строк программного кода при создании нетривиальных форм.
Пример 10.9. PP4E\Gui\ShellGui\formrows.py
создает фрейм-ряд с меткой и полем ввода и дополнительной кнопкой, вызывающей диалог выбора файла; эта реализация была выделена в отдельный модуль, потому что она может с успехом использоваться и в других программах; вызывающая программа (или обработчики событий, как в данном случае) должна сохранять ссылку на связанную переменную на все время использования ряда;
from tkinter import * # виджеты и константы
from tkinter.filedialog import askopenfilename # диалог выбора файла
def makeFormRow(parent, label, width=15, browse=True, extend=False): var = StringVar() row = Frame(parent)
lab = Label(row, text=label + ‘?’, relief=RIDGE, width=width) ent = Entry(row, relief=SUNKEN, textvariable=var) row.pack(fill=X) # используются фреймы-ряды
lab.pack(side=LEFT) # с метками фиксированной длины
ent.pack(side=LEFT, expand=YES, fill=X) # можно использовать
if browse: # grid(row, col)
btn = Button(row, text=’browse...’) btn.pack(side=RIGHT) if not extend:
btn.config(command=
lambda: var.set(askopenfilename() or var.get()) )
else:
btn.config(command=
lambda: var.set(var.get() + ‘ ‘ + askopenfilename()) ) return var
Далее, функция runPackDialog в примере 10.10 является фактическим обработчиком, который вызывается при выборе имени инструмента в главном окне ShellGui. Она использует модуль конструирования рядов формы из примера 10.9 и применяет приемы создания модальных диалогов, которые мы изучали ранее.
Пример 10.10. PP4E\Gui\ShellGui\packdlg.py
# выводит диалог ввода параметров для сценария packer и запускает его
from glob import glob # расширение шаблонов имен файлов
from tkinter import * # виджеты графического интерфейса
from packer import pack # использовать сценарий/модуль packer
from formrows import makeFormRow # использовать инструмент создания форм
def packDialog(): # новое окно верхнего уровня
win = Toplevel() # с 2 фреймами-рядами + кнопка ok win.title(‘Enter Pack Parameters’)
var1 = makeFormRow(win, label=’Output file’)
var2 = makeFormRow(win, label=’Files to pack’, extend=True)
Button(win, text=’OK’, command=win.destroy).pack() win.grab_set()
win.focus_set() # модальный: захватить мышь, фокус ввода,
win.wait_window() # ждать закрытия окна диалога;
# иначе возврат произойдет немедленно return var1.get(), var2.get() # извлечь значения связанных переменных
def runPackDialog():
output, patterns = packDialog() # вывести диалог и ждать щелчка на
if output != “” and patterns != “”: # кнопке ok или закрытия окна
patterns = patterns.split() # выполнить действия не связанные с filenames = [] # графическим интерфейсом
for sublist in map(glob, patterns): # вып. расширение шаблона вручную filenames += sublist # командные оболочки Unix
print(‘Packer:’, output, filenames) # делают это автоматически pack(ofile=output, ifiles=filenames) # вывод также можно показать в
# графическом интерфейсе
if__name__== ‘__main__’:
root = Tk()
Button(root, text=’popup’, command=runPackDialog).pack(fill=X)
Button(root, text=’bye’, command=root.quit).pack(fill=X) root.mainloop()
Если запустить сценарий из примера 10.10 и щелкнуть на кнопке popup, он создаст форму ввода, как показано на рис. 10.6, - это тот же диалог, который будет показан в ответ на выбор инструмента в главном окне сценария mytools.py. Пользователь может ввести имена входных и выходных файлов с клавиатуры или щелкнуть на кнопке browse... чтобы открыть стандартный диалог выбора файла. Допускается вводить шаблоны имен файлов - вызов функции glob в этом сценарии выполнит подстановку шаблона и отфильтрует имена несуществующих файлов. Командные оболочки в Unix осуществляют такую подстановку шаблонов автоматически, если запускать сценарий packer.py из командной строки, в отличие от Windows.
Рис. 10.6. Форма вводаpackdlg
После того как пользователь заполнит форму и щелкнет на кнопке OK, параметры будут переданы главной функции сценария packer, представленного выше, для выполнения операции слияния файлов.
Графический интерфейс диалога ввода параметров для сценария unpacking выглядит проще, потому что в нем присутствует только одно поле ввода - имя файла архива. Здесь мы снова используем модуль конструирования рядов формы ввода, разработанного для диалога к сценарию packer, потому что эти две задачи очень похожи. Сценарий в примере 10.11 (и его главная функция, вызываемая графическим интерфейсом выбора инструмента в сценарии mytools.py) создает форму ввода, изображенную на рис. 10.7.
Рис. 10.7. Форма ввода unpkdlg
Пример 10.11. PP4E\Gui\ShellGui\unpkdlg.py
# выводит диалог ввода параметров для сценария unpacker и запускает его
from tkinter import * # классы виджетов
from unpacker import unpack # использовать сценарий/модуль unpacker
from formrows import makeFormRow # инструмент создания полей формы
def unpackDialog(): win = Toplevel()
win.title(‘Enter Unpack Parameters’) var = makeFormRow(win, label=’Input file’, width=11) win.bind(‘’, lambda event: win.destroy()) win.grab_set()
win.focus_set() # сделать себя модальным
win.wait_window() # ждать возврата из диалога
return var.get() # или закрытия его окна
def runUnpackDialog():
input = unpackDialog() # получить входные параметры из диалога
if input != ‘’: # выполнить действия, не связанные с
print(‘Unpacker:’, input) # графическим интерфейсом, передав имя unpack(ifile=input, prefix=’’) # файла из диалога
if__name__== “__main__”:
Button(None, text=’popup’, command=runUnpackDialog).pack() mainloop()
Кнопка browse... на рис. 10.7 выводит диалог выбора файла так же, как форма packdlg. Вместо кнопки OK этот диалог связывает событие нажатия клавиши Enter с операцией закрытия окна и с завершением ожидания закрытия модального диалога; при этом имя файла архива передается экземпляру класса главной функции сценария unpacker, представленного выше, для выполнения фактической процедуры сканирования файла.
Возможные улучшения
Весь комплекс действует, как и было обещано, - благодаря такой доступности утилит командной строки в графическом виде они становятся значительно более привлекательными для пользователей, привычной средой обитания которых является графический интерфейс. Мы фактически добавили простой графический интерфейс к инструментам командной строки. И все же в данной конструкции есть два аспекта, которые можно было бы усовершенствовать.
Во-первых, оба диалога ввода используют общий программный код конструирования рядов в их формах ввода, который был реализован для данного конкретного случая. Мы могли бы существенно упростить создание диалогов, импортировав более обобщенный модуль создания форм. Мы встречались с обобщенной реализацией конструктора форм в главах 8 и 9 и будем встречаться с ней далее - смотрите также указания по обобщению создания форм в модуле form. py, в главе 12.
Во-вторых, в тот момент, когда пользователь передает данные, введенные в той или иной диалоговой форме, след графического интерфейса теряется - главное окно блокируется, а сообщения поступают в окно консоли. Графический интерфейс блокируется по техническим причинам и не может обновлять себя, пока работают утилиты packer и unpacker. Хотя эти операции и выполняются достаточно быстро с моими файлами, но при обработке очень больших файлов можно было бы запускать их в отдельных потоках выполнения, чтобы сохранить графический интерфейс активным (подробнее о потоках выполнения рассказывается далее в этой главе).
Проблема с консолью является более насущной: сообщения от утилит packer и unpacker все так же выводятся в поток stdout, а не в графический интерфейс (все имена файлов здесь включают полные пути к ним, если выбирать их с помощью стандартного диалога выбора файлов, открываемого щелчком на кнопке browse...):
C:\...\PP4E\Gui\ShellGui\temp> python ..\mytools.py list
PP4E scrolledtext list test
Packer: packed.all [‘spam.txt’, ‘ham.txt’, ‘eggs.txt’]
packing: spam.txt
packing: ham.txt
packing: eggs.txt
Unpacker: packed.all
creating: spam.txt
creating: ham.txt creating: eggs.txt
Это далеко не идеальное решение для пользователей, привыкших работать с графическим интерфейсом, - они могут не ожидать (или даже не в состоянии отыскать) появления полезной информации в окне консоли. Лучшим решением было бы перенаправить поток вывода stdout в объект, который выводит полученный текст в окно графического интерфейса. О том, как это сделать, можно прочесть в следующем разделе.
GuiStreams: перенаправление потоков данных в виджеты
Следующий прием программирования графических интерфейсов. В ответ на проблему, поставленную в конце предыдущего раздела, сценарий в примере 10.12 организует отображение входных и выходных потоков во всплывающие окна приложения, применяя практически тот же способ, который мы использовали со строками в темах, связанных с перенаправлением потоков ввода-вывода в главе 3. Хотя этот модуль служит лишь базовым прототипом и сам нуждается в усовершенствовании (например, для ввода каждой входной строки отображается новый диалог - не самое эргономичное решение), тем не менее он демонстрирует идею в целом.
Объекты этого модуля, GuiOutput и GuiInput, определяют методы, позволяющие им маскироваться под файлы везде, где ожидаются настоящие файлы. Как мы узнали в главе 3, это осуществляется с помощью средств доступа к стандартным потокам ввода-вывода, таких как встроенные функции print и input, и явных вызовов read и write. Типичные случаи использования обслуживаются в этом модуле двумя высокоуровневыми интерфейсами:
• Функция redirectedGuiFunc благодаря такой совместимости с файлами позволяет выполнять любые функции так, что их стандартные потоки ввода и вывода целиком отображаются в окна графического интерфейса, а не в окно консоли (или туда, куда эти потоки отображались бы в обычном случае).
• Функция redirectedGuiShellCmd аналогичным образом направляет в окно графического интерфейса вывод программы, запускаемой из командной строки. Она может использоваться для отображения в графическом интерфейсе вывода любых программ, включая программы на языке Python.
Классы GuiInput и GuiOutput, реализованные в модуле, можно использовать или специализировать непосредственно в клиентах, где требуется обеспечить более непосредственный интерфейс методов файлов или более полное управление процессом.
Пример 10.12. PP4E\Gui\Tools\guiStreams.py
##############################################################################
начальная реализация классов, похожих на файлы, которые можно использовать для перенаправления потоков ввода и вывода в графические интерфейсы; входные данные поступают из стандартного диалога (единый интерфейс вывод+ввод или постоянное поле Entry для ввода были бы удобнее); кроме того, некорректно берутся строки в запросах входных данных, когда количество байтов > ^(строки); в GuiInput
можно было бы добавить методы __iter__/__next__, для поддержки итераций по
строкам, как в файлах, но это способствовало бы порождению большого количества всплывающих окон;
##############################################################################
from tkinter import *
from tkinter.simpledialog import askstring
from tkinter.scrolledtext import ScrolledText # или PP4E.Gui.Tour.scrolledtext class GuiOutput:
font = (‘courier’, 9, ‘normal’) # в классе - для всех, self - для одного
def __init__(self, parent=None):
self.text = None
if parent: self.popupnow(parent) # сейчас или при первой записи
def popupnow(self, parent=None): # сейчас в родителе, Toplevel потом
if self.text: return
self.text = ScrolledText(parent or Toplevel())
self.text.config(font=self.font)
self.text.pack()
def write(self, text): self.popupnow()
self.text.insert(END, str(text)) self.text.see(END)
self.text.update() # обновлять после каждой строки
def writelines(self, lines): # строки уже включают ‘\n’
for line in lines: self.write(line) # или map(self.write, lines)
class GuiInput:
def __init__(self):
self.buff = ‘’
def inputLine(self):
line = askstring(‘GuiInput’, ‘Enter input line + (cancel=eof)’) if line == None:
return ‘’ # диалог для ввода каждой строки
else: # кнопка cancel означает eof
return line + ‘\n’ # иначе добавить символ ‘\n’
def read(self, bytes=None): if not self.buff:
self.buff = self.inputLine()
if bytes: # читать по счетчику байтов,
text = self.buff[:bytes] # чтобы не захватить лишние строки
self.buff = self.buff[bytes:] else:
text = ‘’ # читать до eof
line = self.buff while line:
text = text + line
line = self.inputLine() # до cancel=eof=’’ return text
def readline(self):
text = self.buff or self.inputLine() # имитировать методы чтения файла self.buff = ‘’ return text
def readlines(self):
lines = [] # читать все строки
while True:
next = self.readline() if not next: break lines.append(next) return lines
def redirectedGuiFunc(func, *pargs, **kargs):
import sys # отображает потоки функции
saveStreams = sys.stdin, sys.stdout # во всплывающие окна
sys.stdin = GuiInput() # выводит диалог при необходимости
sys.stdout = GuiOutput() # новое окно для каждого вызова
sys.stderr = sys.stdout
result = func(*pargs, **kargs) # это блокирующий вызов
sys.stdin, sys.stdout = saveStreams return result
def redirectedGuiShellCmd(command): import os
input = os.popen(command, ‘r’) output = GuiOutput()
def reader(input, output): # показать стандартный вывод
while True: # команды оболочки в новом
line = input.readline() # окне с виджетом Text;
if not line: break # вызов readline может
output.write(line) # блокироваться
reader(input, output)
if __name__ == ‘__main__’: # код самотестирования
def makeUpper(): # использовать стандартные потоки
while True: # ввода-вывода
try:
line = input(‘Line? ‘) except: break
print(line.upper()) print(‘end of file’)
def makeLower(input, output): # использовать файлы
while True:
line = input.readline() if not line: break output.write(line.lower()) print(‘end of file’)
root = Tk()
Button(root, text=’test streams’,
command=lambda: redirectedGuiFunc(makeUpper)).pack(fill=X)
Button(root, text=’test files ‘,
command=lambda: makeLower(GuiInput(), GuiOutput()) ).pack(fill=X) Button(root, text=’test popen ‘,
command=lambda: redirectedGuiShellCmd(‘dir *’)).pack(fill=X) root.mainloop()
Класс GuiOutput прикрепляет объект ScrolledText (из стандартной библиотеки Python) либо к указанному родительскому контейнеру, либо выводит новое окно верхнего уровня, которое должно служить контейнером, при первом обращении к методу записи. Класс GuiInput выводит новый стандартный диалог ввода каждый раз, когда метод read запрашивает новую входную строку. Ни одна из этих схем не будет оптимальной для всех ситуаций (ввод лучше было бы отобразить на более долгоживущий виджет), но они доказывают правильность общей идеи.
На рис. 10.8 изображена картина, создаваемая реализацией самотестирования этого сценария, после перехвата вывода команды оболочки dir в Windows (слева) и двух интерактивных проверок цикла (окно с приглашениями «Line?» и прописными буквами представляет работу теста makeUpper перенаправления потоков). Диалог ввода выведен для демонстрации нового теста интерфейса файлов makeLower.
Возможно, эта картина не настолько захватывающая, чтобы на нее можно было смотреть часами, но она отражает автоматическое отображение файловых операций ввода-вывода в виджеты графического интерфейса - как будет показано чуть ниже, это решает большую часть последней проблемы, обозначенной в предыдущем разделе.
Но прежде чем двинуться дальше, необходимо отметить, что реализованный в этом модуле вызов функции, для которой выполняется перенаправление потоков ввода-вывода, а также его цикл чтения вывода по-
Рис. 10.8. Сценарий guiStreams направляет потоки во всплывающие окна
рожденной команды оболочки, могут быть заблокированы - они не возвращают управление циклу событий графического интерфейса, пока не завершится функция или запущенная команда оболочки. И хотя класс GuiOutput предусматривает вызов метода update из библиотеки tkinter после записи каждой строки, тем не менее в целом этот модуль не имеет возможности контролировать продолжительность выполнения функций или команд, которые он запускает.
В функции redirectedGuiShellCmd, например, вызов метода input.read-line будет вызывать задержку, пока от порожденной программы не будет принята полная выходная строка, и графический интерфейс в течение этого времени не будет откликаться на действия пользователя. Поскольку объект вывода output вызывает метод update, изображение на экране будет обновляться в процессе выполнения программы (метод update немедленно вызывает цикл событий Tk), но не чаще, чем будут приниматься строки от порожденной программы. Кроме того, из-за наличия цикла в этой функции графический интерфейс полностью подчиняет себя запущенной им команде, пока она не завершится.
Вызовы функций в redirectedGuiFunc также подвержены подобным блокировкам. Кроме того, на протяжении всего времени работы вызываемой функции графический интерфейс обновляется не чаще, чем функция будет выводить данные. Иными словами, эта упрощенная блокирующая модель может стать источником проблем в крупных графических интерфейсах. Мы еще вернемся к этой теме далее, когда встретимся с потоками выполнения. А пока данная реализация вполне соответствует нашим текущим целям.
Использование перенаправления для сценариев архивирования
Теперь, чтобы использовать эти инструменты перенаправления для отображения вывода сценария командной строки в графический интерфейс, просто выполним вызовы и команды оболочки через две функции этого модуля. Пример 10.13 демонстрирует один из способов обертывания вызова диалога архивирования, реализация которого представлена в примере 10.10, благодаря которому вывод операции оказывается во всплывающем окне вместо консоли.
Пример 10.13. PP4E\Gui\ShellGui\packdlg-redirect.py
# обертывает запуск сценария командной строки инструментом перенаправления его
# вывода в графический интерфейс
from tkinter import *
from packdlg import runPackDialog
from PP4E.Gui.Tools.guiStreams import redirectedGuiFunc
def runPackDialog_Wrapped(): # обработчик для использования в
redirectedGuiFunc(runPackDialog) # модуле mytools.py, обертывает прежний
# обработчик целиком
if__name__== ‘__main__’:
root = Tk()
Button(root, text=’pop’, command=runPackDialog_Wrapped).pack(fill=X) root.mainloop()
Можете проверить работу этого сценария, запустив его непосредственно, без привлечения окна ShellGui. На рис. 10.9 изображено получившееся окно stdout после закрытия диалога ввода параметров для операции архивирования. Окно появляется, как только сценарий создаст вывод, и предоставляет пользователю несколько более дружественный графический интерфейс, чем при отлове сообщений в консоли. Аналогичный
Рис. 10.9. Перенаправление вывода сценария во всплывающие окна с графическим интерфейсом
программный код можно написать и для диалога ввода параметров разархивирования, чтобы направить вывод во всплывающее окно. Просто измените сценарий mytools.py в примере 10.6, зарегистрировав представленную здесь функцию-обертку в качестве обработчика.
Фактически этот прием можно использовать для перенаправления вывода любой функции или команды оболочки во всплывающее окно. Как обычно, идея совместимых интерфейсов объектов в значительной мере обусловливает гибкость Python.
Динамическая перезагрузка обработчиков
Следующий прием программирования, который мы рассмотрим, касается изменения графического интерфейса в процессе его работы. Функция imp. reload в языке Python позволяет динамически изменять и перезагружать модули программы, не останавливая ее. Например, можно вызвать текстовый редактор, изменить отдельные части системы во время ее выполнения и увидеть, как проявляются эти изменения, сразу после перезагрузки измененного модуля.
Это мощная возможность, особенно при разработке программ, перезапуск которых мог бы занять длительное время. Программы, которые подключаются к базам данных или сетевым серверам, инициализируют крупные объекты или проходят длинную последовательность шагов, чтобы снова запустить обработчик, являются первыми кандидатами на использование функции reload. Эта функция может существенно сократить время разработки.
Однако в графическом интерфейсе при регистрации обработчиков сохраняются ссылки на объекты, а не имена модулей и объектов, поэтому перезагрузка функций обработчиков после их регистрации не даст желаемого эффекта. Операция imp.reload действует путем изменения содержимого объекта модуля в памяти. Однако, так как библиотека tkinter запоминает указатель на зарегистрированный объект обработчика, ей неизвестно о перезагрузке модуля, в котором находится обработчик. Это означает, что tkinter по-прежнему будет ссылаться на старые объекты модуля, даже если модуль был изменен и перезагружен.
Это тонкий момент, но в действительности достаточно только запомнить, что для динамической перезагрузки функций обработчиков требуется выполнить особые действия. Необходимо не только явно выполнить перезагрузку измененных модулей, но и предоставить некоторый косвенный слой, маршрутизирующий обратные вызовы от зарегистрированных объектов в модули, чтобы перезагрузка возымела эффект.
Например, сценарий в примере 10.14 выполняет дополнительные действия, перенаправляя обратные вызовы функциям в явно перезагруженном модуле. Обработчики, зарегистрированные в библиотеке tkinter, являются объектами методов, которые всего лишь осуществля-
ют перезагрузку и снова отправляют вызов. Так как доступ к действительным функциям обработчиков происходит через объект модуля, перезагрузка этого модуля приводит к обращению к последним версиям этих функций.
Пример 10.14. PP4E\Gui\Tools\rad.py
# перезагружает обработчики динамически
from tkinter import *
import radactions # получить первоначальные обработчики from imp import reload # в Python 3.X была перемещена в модуль imp
class Hello(Frame):
def __init__(self, master=None):
Frame.__init__(self, master)
self.pack()
self.make_widgets()
def make_widgets(self):
Button(self, text=’message1’, command=self.message1).pack(side=LEFT) Button(self, text=’message2’, command=self.message2).pack(side=RIGHT)
def message1(self):
reload(radactions) # перезагрузить модуль radactions перед вызовом
radactions.message1() # теперь щелчок на кнопке вызовет новую версию
def message2(self):
reload(radactions) # изменения в radactions.py возымеют эффект
# благодаря перезагрузке
radactions.message2(self) # вызовет свежую версию; передать self def method1(self):
print(‘exposed method...’) # вызывается из функции в модуле radactions Hello().mainloop()
Если запустить этот сценарий, он создаст окно с двумя кнопками, вызывающими методы message1 и message2. Пример 10.15 содержит фактическую реализацию обработчика. Его функции получают аргумент self, который обеспечивает доступ к объекту класса Hello, как если бы это были действительные методы. Можно многократно изменять этот файл во время выполнения сценария rad; каждое такое действие изменяет поведение графического интерфейса при нажатии кнопки.
Пример 10.15. PP4E\Gui\Tools\radactions.py
# обработчики: перезагружаются перед каждым вызовом
def message1(): # изменить себя
print(‘spamSpamSPAM’) # можно было бы вывести диалог...
def message2(self):
print(‘Ni! Ni!’) # изменить себя
self.method1() # обращение к экземпляру ‘Hello’...
Попробуйте запустить сценарий rad и изменять сообщения, которые выводит radactions, в другом окне. Вы должны увидеть, как при нажатии кнопок в окно консоли будут выводиться новые сообщения. Данный пример намеренно сделан простым, для иллюстрирации идеи, но на практике перезагружаемые таким способом операции могут выводить диалоги, новые окна верхнего уровня и так далее. Перезагрузка программного кода, создающего такие окна, позволяет динамически изменять их внешний вид.
Существуют и другие способы изменения графического интерфейса во время его выполнения. Например, в главе 9 мы видели, что внешний вид в любой момент можно изменить, вызвав метод config виджета, а сами виджеты можно динамически добавлять и удалять с экрана такими методами, как pack_forget и pack (и родственными им для менеджера компоновки grid). Кроме того, передача нового значения параметра command=action методу config может динамически установить в качестве обработчика обратного вызова новый вызываемый объект - при наличии соответствующей поддержки это может оказаться реальной альтернативой использованной выше обходной схеме повышения эффективности перезагрузки в графических интерфейсах.
Разумеется, далеко не все графические интерфейсы должны быть настолько динамичными. Однако представьте себе игру, которая позволяет модифицировать персонажи, - динамическая перезагрузка в таких системах может оказаться очень полезной. (Я оставляю задачу расширения этого примера на многопользовательские ролевые игры как самостоятельное упражнение.)
Обертывание интерфейсов окон верхнего уровня
Интерфейсы окон верхнего уровня были представлены в главе 8. Данный раздел продолжает обсуждение с того места, где это представление завершилось, и демонстрирует обертывание этих интерфейсов классами, автоматизирующими большую часть операций по созданию окон верхнего уровня, - установку заголовков, поиск и отображение ярлыков окон, выполнение действий по закрытию окна исходя из его назначения, перехват события щелчка мышью на кнопке закрытия окна в его заголовке и так далее.
В примере 10.16 приводятся определения классов-оберток для наиболее часто используемых типов окон - главного окна приложения, временного всплывающего окна и окна встроенного компонента графического интерфейса. Эти типы окон несколько отличаются друг от друга реализациями операции закрытия, но наследуют множество общих черт: ярлыки, заголовки и кнопки закрытия. Используя непосредственно, подмешивая или наследуя класс окна требуемого типа, вы бесплатно получаете в свое распоряжение все логику настройки.
Пример 10.16. PP4E\Gui\Tools\windows.py
##############################################################################
Классы, инкапсулирующие интерфейсы верхнего уровня.
Позволяют создавать главные, всплывающие или присоединяемые окна; эти классы могут наследоваться непосредственно, смешиваться с другими классами или вызываться непосредственно, без создания подклассов; должны подмешиваться после (то есть правее) более конкретных прикладных классов: иначе подклассы будут получать методы (destroy, okayToQuit) из этих, а не из прикладных классов, и лишатся возможности переопределить их. ##############################################################################
import os, glob
from tkinter import Tk, Toplevel, Frame, YES, BOTH, RIDGE from tkinter.messagebox import showinfo, askyesno
class _window:
подмешиваемый класс, используется классами главных и всплывающих окон
foundicon = None # совместно используется всеми экземплярами
iconpatt = ‘*.ico’ # может быть сброшен
iconmine = ‘py.ico’
def configBorders(self, app, kind, iconfile):
if not iconfile: # ярлык не был передан?
iconfile = self.findIcon() # поиск в тек. каталоге и в каталоге
title = app # модуля
if kind: title += ‘ - ‘ + kind self.title(title) # на рамке окна
self.iconname(app) # при свертывании
if iconfile: try:
self.iconbitmap(iconfile) # изображение ярлыка окна except: # проблема с интерпретатором или
pass # платформой
self.protocol(‘WM_DELETE_WINDOW’, self.quit) # не закрывать без
# подтверждения
def findIcon(self):
if _window.foundicon: # ярлык уже найден?
return _window.foundicon
iconfile = None # сначала искать в тек. каталоге
iconshere = glob.glob(self.iconpatt) # допускается только один if iconshere: # удалить ярлык с красными
iconfile = iconshere[0] # буквами Tk
else: # поиск в каталоге модуля
mymod = __import__(__name__) # импортировать, получить каталог
path = __name__.split(’.’) # возможно, путь пакета
for mod in path[1:]: # по всему пути до конца
mymod = getattr(mymod, mod) # только самый первый mydir = os.path.dirname(mymod.__file__)
myicon = os.path.join(mydir, self.iconmine) # исп. myicon, а не tk if os.path.exists(myicon): iconfile = myicon _window.foundicon = iconfile # не выполнять поиск вторично
return iconfile
class MainWindow(Tk, _window):
главное окно верхнего уровня
def __init__(self, app, kind=’’, iconfile=None):
Tk.__init__(self) self.__app = app
self.configBorders(app, kind, iconfile) def quit(self):
if self.okayToQuit(): # потоки запущены?
if askyesno(self.__app, ‘Verify Quit Program?’):
self.destroy() # завершить приложение
else:
showinfo(self.__app, ‘Quit not allowed’) # или в okayToQuit?
def destroy(self): # просто завершить
Tk.quit(self) # переопределить, если необходимо
def okayToQuit(self): # переопределить, если используются
return True # потоки выполнения
class PopupWindow(Toplevel, _window):
вторичное всплывающее окно
def __init__(self, app, kind=’’, iconfile=None):
Toplevel.__init__(self)
self.__app = app
self.configBorders(app, kind, iconfile)
def quit(self): # переопределить, если потребуется изменить
if askyesno(self.__app, ‘Verify Quit Window?’): # или вызвать destroy self.destroy() # чтобы закрыть окно
def destroy(self): # просто закрыть окно
Toplevel.destroy(self) # переопределить, если необходимо
class QuietPopupWindow(PopupWindow):
def quit(self):
self.destroy() # закрывать без предупреждения
class ComponentWindow(Frame):
при присоединении к другим интерфейсам
def __init__(self, parent): # если не фрейм
Frame.__init__(self, parent) # предоставить контейнер self.pack(expand=YES, fill=BOTH)
self.config(relief=RIDGE, border=2) # перенастроить при необходимости def quit(self):
showinfo(‘Quit’, ‘Not supported in attachment mode’)
# destroy из фрейма: просто удалить фрейм # переопределить, если
# необходимо
Почему бы просто не определять ярлык приложения и заголовок окна непосредственно вызовом методов? С одной стороны, особенности такого рода нелегко запомнить (в результате вам придется большую часть времени тратить на копирование и вставку кода). С другой стороны, эти классы добавляют высокоуровневые функциональные возможности, реализацию которых иначе пришлось бы добавлять снова и снова. Кроме всего прочего, эти классы обеспечивают автоматический запрос подтверждения завершения и поиск ярлыка. Например, классы окон всего один раз пытаются отыскать файл ярлыка в текущем рабочем каталоге и в каталоге, где находится данный модуль.
Используя классы, инкапсулирующие - то есть скрывающие - такие подробности, мы получаем всю мощь инструмента, без необходимости задумываться об их реализации в будущем. Кроме того, с помощью этих классов мы можем придавать нашим приложениям стандартизованный внешний вид и поведение. А если в будущем их потребуется изменить, нам достаточно будет изменить программный код только в одном месте, а не во всех реализованных нами окнах.
Для тестирования этого модуля в примере 10.17 приводится сценарий, использующий эти классы в различных режимах - в качестве подмешиваемых классов, в качестве суперклассов и непосредственно - из обычного процедурного программного кода.
Пример 10.17. PP4E\Gui\Tools\windows-test.py
# модуль windows должен импортироваться, иначе атрибут __name__ будет иметь
# значение __main__ в функции findIcon
from tkinter import Button, mainloop
from windows import MainWindow, PopupWindow, ComponentWindow def _selftest():
# использовать, как подмешиваемый класс class content:
"используется так же, как Tk, Toplevel и Frame” def __init__(self):
Button(self, text=’Larch’, command=self.quit).pack()
Button(self, text=’Sing ‘, command=self.destroy).pack()
class contentmix(MainWindow, content): def __init__(self):
MainWindow.__init__(self, ‘mixin’, ‘Main’)
content.__init__(self) contentmix()
class contentmix(PopupWindow, content): def __init__(self):
PopupWindow.__init__(self, ‘mixin’, ‘Popup’)
content.__init__(self) prev = contentmix()
class contentmix(ComponentWindow, content):
def __init__(self): # вложенный фрейм
ComponentWindow.__init__(self, prev) # в предыдущем окне content.__init__(self) # кнопка Sing стирает фрейм
contentmix()
# использовать в подклассах class contentsub(PopupWindow):
def __init__(self):
PopupWindow.__init__(self, ‘popup’, ‘subclass’)
Button(self, text=’Pine’, command=self.quit).pack()
Button(self, text=’Sing’, command=self.destroy).pack() contentsub()
# использование в процедурном программном коде win = PopupWindow(‘popup’, ‘attachment’)
Button(win, text=’Redwood’, command=win.quit).pack()
Button(win, text=’Sing ‘, command=win.destroy).pack() mainloop()
if __name__ == ‘__main__’:
_selftest()
Если запустить этот тест, он создаст четыре окна, как показано на рис. 10.10. Все окна автоматически получат ярлык с голубыми буквами «PY» и будут перехватывать и запрашивать подтверждение при попытке закрыть их щелчком на кнопке X в правом верхнем углу, благодаря логике поиска и настройки, унаследованной из классов окон в модуле. Некоторые кнопки в окнах, воспроизводимых тестовым сценарием, закрывают только вмещающее их окно, некоторые - все приложение, некоторые стирают только присоединенное окно, а некоторые выводят диалог с просьбой подтвердить закрытие окна. Запустите этот сценарий у себя на компьютере, чтобы увидеть, как действуют различные кнопки, и получить возможность сопоставить их поведение с реализацией в сценарии - действия, выполняемые при закрытии окна, зависят от его типа.
Рис. 10.10. Интерфейс сценария windows-test
Мы будем использовать эти классы-обертки в следующей главе, в примере PyClock, и еще раз - в главе 14, где они будут использоваться, чтобы уменьшить сложность программы PyMailGUI. Отчасти преимущество применения приемов ООП в языке Python состоит в том, что благодаря им мы можем позднее не вспоминать детали реализации.
Графические интерфейсы, потоки выполнения и очереди
В главе 5 мы познакомились с потоками выполнения и механизмом очередей, который обычно используется для организации обмена данными между потоками. Там же было дано краткое описание применения этих идей в приложениях с графическим интерфейсом. В главе 9 мы продолжили развитие этих тем применительно к библиотеке tkinter, используемой в этой книге, и расширили модель многопоточных графических интерфейсов в целом, рассмотрев поддержку многопоточной модели выполнения (или ее отсутствие) и назначение очередей и блокировок.
Теперь, когда мы приобрели определенный опыт разработки графических интерфейсов, мы можем, наконец, перейти к воплощению этих идей в программный код. Если в свое время вы пропустили описание этих тем в главе 5 или 9, вам, вероятно, лучше вернуться назад и прочитать их - мы не будем повторно рассматривать здесь основы программирования многопоточных приложений или применения очередей.
Многопоточная модель имеет самое прямое отношение к графическим интерфейсам. Напомню, что продолжительные операции вообще должны выполняться в параллельных потоках, чтобы избежать блокирования графического интерфейса и обеспечить его отзывчивость на действия пользователя. Под продолжительными операциями обычно понимаются вызовы функций, которые выполняются значительное время, операции загрузки данных с серверов, блокирующие операции ввода-вывода и любые другие, которые могут вызвать заметную задержку. В обсуждении нашего примера со сценариями архивирования/ разархивирования, представленного выше в этой главе, например, отмечалось, что функции, выполняющие фактическую обработку файлов, в целом должны выполняться в отдельных потоках, чтобы не блокировать главный поток графического интерфейса до их завершения.
В общем случае, когда графический интерфейс ожидает завершения какой-либо операции, он становится полностью неотзывчивым - окно не сможет изменить размер, свернуться и даже просто перерисовать себя, если он был перекрыт другим окном, которое потом ушло. Чтобы исключить возможность такого блокирования, программы с графическим интерфейсом должны выполнять продолжительные операции параллельно, обычно с применением механизма потоков выполнения, который позволяет совместно использовать данные программы. При таком подходе главный поток выполнения графического интерфейса получает возможность обновлять изображение на экране и откликаться на действия пользователя, в то время как другие потоки заняты решением других задач. Как мы уже видели, в некоторых ситуациях на помощь может прийти метод update, но его можно считать решением проблем, только когда есть возможность вызвать его, - потоки выполнения обеспечивают по-настоящему параллельное выполнение продолжительных операций и предлагают более универсальное решение.
Однако, как мы узнали в главе 9, только главный поток выполнения должен обновлять графический интерфейс - потоки выполнения, выполняющие продолжительные операции, не должны делать этого. Вместо этого они должны помещать данные в очередь (или передавать их через иной механизм), чтобы главный поток мог их извлечь и отобразить. Для этого в главном потоке обычно выполняется цикл опроса через определенные интервалы времени, в котором проверяется поступление новых результатов для отображения. Дочерние потоки производят данные и помещают их в очередь, но они ничего не знают о графическом интерфейсе, - главный поток получает данные и отображает их, но не занимается их генерированием.
Вследствие такого разделения труда мы обычно называем эту модель производитель/потребитель - вычислительные потоки производят данные, которые потребляются главным потоком графического интерфейса. Потоки, выполняющие продолжительные операции, иногда называют рабочими потоками, потому что они выполняют работу по производству результатов, которые затем представляются пользователю с помощью графического интерфейса. В некотором смысле, графический интерфейс является клиентом рабочих потоков-серверов, хотя обычно эта терминология используется в более узком смысле - серверы являются долгоживущими источниками данных, не имеющими тесной связи с клиентами (хотя графический интерфейс также может отображать данные, полученные от независимых серверов). Но, независимо от своего названия, данная модель позволяет исключить блокирование графического интерфейса и параллельно выполнять другие задачи, которые не выполняют непосредственного обновления графического интерфейса.
В качестве конкретного примера представим, что наш графический интерфейс должен отображать данные телеметрии, получаемые со спутника в масштабе реального времени через сокеты (механизм взаимодействий между процессами, представленный в главе 5). Такая программа должна быть достаточно отзывчивой, чтобы не потерять входящие данные, и при этом не должна блокироваться в периоды ожидания или обработки данных. Чтобы достичь обеих целей, можно породить дочерние потоки выполнения, которые будут получать поступающие данные и помещать их в очередь, а главный поток графического интерфейса будет периодически извлекать данные из очереди и отображать их. При таком разделении труда графический интерфейс не блокируется данными со спутника и наоборот - сам графический интерфейс будет выполняться независимо от потоков данных, а поскольку потоки обработки данных могут выполняться на полной скорости, они смогут принимать входные данные с той же скоростью, с какой они будут отправляться. Вообще, циклы событий графических интерфейсов не настолько отзывчивы, чтобы обрабатывать поступающие данные в масштабе реального времени. Без дополнительных потоков выполнения мы могли бы потерять часть телеметрии, а с ними мы сумеем принимать все отправляемые данные и отображать их, как только цикл событий графического интерфейса найдет время, чтобы извлечь их из очереди, - достаточно быстро, чтобы не вызвать ощущения задержки у пользователя. В отсутствие данных только дочерние потоки будут ожидать их появления, но не графический интерфейс.
В других ситуациях дополнительные потоки могут потребоваться, только чтобы графический интерфейс оставался активным в ходе выполнения продолжительных операций. Загружая данные с веб-сервера, например, графический интерфейс должен иметь возможность перерисовывать себя при перекрытии другими окнами или при изменении размеров. По этой причине вызов функции загрузки не может быть простым вызовом функции - функция должна выполняться параллельно остальной программе, обычно в отдельном потоке. По окончании загрузки поток должен известить графический интерфейс, что данные готовы для отображения, поместив их в очередь, - главный поток обнаружит их при следующей же проверке очереди в обработчике, вызываемом по таймеру. Например, мы будем использовать потоки и очереди таким способом в программе PyMailGUI, в главе 14, чтобы обеспечить возможность параллельного выполнения нескольких операций передачи почты без блокирования графического интерфейса.
Помещение данных в очередь
Обменивается ли ваш графический интерфейс данными со спутниками, веб-серверами или с чем-то еще, эта многопоточная модель легко воплощается в программный код. В примере 10.18 приводится графический интерфейс, эквивалентный многопоточной программе с очередями, с которой мы встречались в главе 5 (сравните его с примером 5.14). В данном случае графический интерфейс является потоком-потребителем, а потоки-производители добавляют данные для отображения в общую очередь. Для проверки появления результатов в очереди главный поток вместо явного цикла использует метод after из библиотеки.
Пример 10.18. PP4E\Gui\Tools\queuetest-gui.py
# графический интерфейс, отображающий данные, производимые рабочими потоками
import _thread, queue, time
dataQueue = queue.Queue() # бесконечной длины
def producer(id):
for i in range(5): time.sleep(0.1) print(‘put’)
dataQueue.put(‘[producer id=%d, count=%d]’ % (id, i))
def consumer(root): try:
print(‘get’)
data = dataQueue.get(block=False) except queue.Empty: pass else:
root.insert(‘end’, ‘consumer got => %s\n’ % str(data)) root.see(‘end’)
root.after(250, lambda: consumer(root)) # 4 раза в секунду
def makethreads(): for i in range(4):
_thread.start_new_thread(producer, (i,))
if __name__ == ‘__main__’:
# главный поток: порождает группу рабочих потоков на каждый щелчок мыши from tkinter.scrolledtext import ScrolledText root = ScrolledText() root.pack()
root.bind(‘’, lambda event: makethreads())
consumer(root) # запустить цикл проверки очереди в главном потоке окна
root.mainloop() # вход в цикл событий
Обратите внимание, что здесь при каждом событии от таймера из очереди извлекается только один элемент данных. Это было сделано сознательно. Можно было бы при каждом событии от таймера извлекать все элементы из очереди в цикле. Но в критических случаях, при наличии большого количества данных в очереди, это легко могло бы привести к блокированию графического интерфейса (представьте быстрый интерфейс телеметрии, который внезапно передал в очередь сразу сотни или даже тысячи результатов измерений). Обрабатывая по одному элементу за раз, мы гарантируем, что цикл событий графического интерфейса будет получать управление, обновлять изображение на экране и обрабатывать ввод пользователя. Недостаток такого подхода состоит в том, что при большом количестве элементов данных в очереди их обработка может занять продолжительное время. В подобных ситуациях можно воспользоваться гибридными схемами, например извлекать из очереди до N элементов данных при каждом событии от таймера, - мы увидим пример реализации такой схемы далее в этом разделе (пример 10.20).
Если запустить этот сценарий, главный поток графического интерфейса начнет извлекать данные из очереди и отображать их в окне Scrolled-Text, как показано на рис. 10.11. При каждом щелчке левой кнопкой мыши в окне будет запускаться новая группа из четырех потоков-производителей. Потоки выполнения выводят сообщения «get» и «put» в стандартный поток вывода (в данном примере эта операция не синхронизируется между потоками - на некоторых платформах, включая Windows, выводимые сообщения могут перемешиваться). Для имитации выполнения продолжительных операций, таких как получение почты, извлечение результатов запроса или ожидание поступления данных через сокет (дополнительно о сокетах рассказывается ниже в этой главе), потоки-производители вызывают функцию sleep. Я выполнил несколько щелчков левой кнопкой мыши, чтобы обеспечить перекрытие потоков выполнения, как показано на рис. 10.11.
Реализация с классами и связанными методами
Пример 10.19 представляет дальнейшее развитие этой модели, реализовав ее в виде класса, обеспечив тем самым возможность специализации и повторного использования. По своему действию и внешнему виду окна этот пример ничем не отличается от процедурной версии, но очередь в нем проверяется чаще и ничего не выводится в стандартный поток вывода. Обратите внимание, что в качестве обработчика событий от мыши и функции потока выполнения здесь используются связанные методы - связанные методы хранят в себе ссылку на экземпляр и на сам метод, поэтому при выполнении в потоке он обладает возможно-
Рис. 10.11. Изображение обновляется главным потоком графического интерфейса
стью доступа к информации в объекте, включая очередь. Это позволило перенести очередь и окно из глобальных переменных в атрибуты экземпляра.
Пример 10.19. PP4E\Gui\Tools\queuetest-gui-class.py
# графический интерфейс, отображающий данные, производимые рабочими потоками
# (на основе классов)
import threading, queue, time
from tkinter.scrolledtext import ScrolledText # или PP4E.Gui.Tour.scrolledtext
class ThreadGui(ScrolledText): threadsPerClick = 4
def __init__(self, parent=None):
ScrolledText.__init__(self, parent)
self.pack()
self.dataQueue = queue.Queue() # бесконечной длины
self.bind(‘’, self.makethreads) # по щелчку левой кнопкой self.consumer() # цикл проверки очереди в
# главном потоке выполнения
def producer(self, id): for i in range(5): time.sleep(0.1)
self.dataQueue.put(‘[producer id=%d, count=%d]’ % (id, i))
def consumer(self): try:
data = self.dataQueue.get(block=False) except queue.Empty: pass else:
self.insert(‘end’, ‘consumer got => %s\n’ % str(data)) self.see(‘end’)
self.after(100, self.consumer) # 10 раз в секунду
def makethreads(self, event):
for i in range(self.threadsPerClick):
threading.Thread(target=self.producer, args=(i,)).start()
if __name__ == ‘__main__’:
root = ThreadGui() # в главном потоке: создать GUI, запустить цикл таймера
root.mainloop() # войти в цикл событий tk
Рассмотрите внимательнее организацию потоков, использование общей очереди и извлечение данных в цикле от таймера, так как с этими приемами мы еще встретимся далее в этой главе, а также в главе 11, в примере программы PyEdit. В программе PyEdit мы будем использовать эти приемы для организации поиска внешних файлов в потоках, чтобы избежать блокирования графического интерфейса и обеспечить возможность одновременного поиска сразу нескольких файлов. Кроме того, мы повторно воспользуемся классической многопоточной моделью произ-водитель/потребитель в более реалистичном примере, представленном далее в этой главе. позволяющей избежать блокирования графического интерфейса, который должен читать данные из стандартного потока ввода, связанного с потоком вывода другой программы.
Завершение потоков в графических интерфейсах
Кроме всего прочего, в примере 10.19 вместо модуля _thread используется модуль threading. Это означает, что в отличие от предыдущей версии, программа не завершится, пока выполняются какие-либо потоки-производители, если только они не были запущены как потоки-демоны, установкой их флагов daemon в значение True. Напомню, что при использовании модуля threading программы завершаются, только когда остаются одни потоки-демоны, - потоки-производители наследуют значение False в атрибуте daemon от потока, создавшего их, что препятствует завершению программы, пока они продолжают выполняться.
Однако в данном примере дочерние потоки выполнения завершаются слишком быстро, чтобы можно было заметить задержку при завершении программы. Измените в сценарии вызов функции time.sleep, чтобы он выполнял задержку на 2 секунды, имитируя долгоживущий рабочий поток, и попробуйте запустить пример. Попытка закрыть окно после щелчка левой кнопкой мыши сотрет окно, но сама программа продолжит выполняться еще в течение примерно 10 секунд (это можно наблюдать, например, в виде паузы в окне консоли). Если сделать то же самое в предыдущей версии, использующей модуль _thread, или в этой версии установить флаги daemon потоков в значение True, программа будет завершаться немедленно.
При решении практических задач может потребоваться взвесить различные политики управления завершением в контексте действующих потоков и программировать их соответствующим образом; при необходимости отложить завершение программы можно использовать потоки, запущенные со значением False в атрибуте daemon, или блокировки. Напротив, использование потоков threading может препятствовать желательному завершению программы, если забыть установить флаг daemon в значение True. Дополнительно о завершении программ и о потоках-демонах (и о других пугающих темах!) рассказывается в главе 5.
Помещение обработчиков в очередь
В примерах предыдущего раздела данные, помещаемые в очередь, всегда были строками. Этого вполне достаточно для простых приложений, где могут существовать производители только одного типа. Однако если в программе могут иметься потоки, выполняющие различные функции и производящие данные различных типов, это может осложнить обработку данных. Вероятно, вам придется сопровождать данные некоторой дополнительной информацией, которая поможет главному потоку графического интерфейса определить, как обрабатывать эти данные.
Представьте, например, почтовый клиент, где несколько операций отправки и приема почты могут выполняться одновременно. Если все потоки совместно используют одну и ту же очередь, информация, помещаемая в нее, должна иметь какие-то отличительные признаки, которые позволят определить, какое событие она представляет, - загруженное сообщение для отображения, информацию для индикатора хода выполнения операции, сообщение об успешной отправке или что-то еще. Это надуманный пример: мы столкнемся с этой проблемой в приложении PyMailGUI, представленном в главе 14.
К счастью, очереди поддерживают не только строки - в очередь можно помещать объекты Python любых типов. Наиболее универсальными из них, вероятно, являются вызываемые объекты: помещая в очередь функцию или другой вызываемый объект, поток-производитель может самым непосредственным способом сообщить графическому интерфейсу, как обрабатывать данные. Графическому интерфейсу остается просто извлечь объект из очереди и вызвать его. Поскольку все потоки выполняются в пределах одного и того же процесса, в очередь могут помещаться вызываемые объекты любых типов - простые функции, результаты lambda-выражений и даже связанные методы, объединяющие в себе функции и объекты, обеспечивающие доступ к их данным и методам. Любые изменения в объектах, выполняемые такими функциями обратного вызова, будут доступны всему процессу.
Благодаря возможности в языке Python универсальным способом обрабатывать функции и списки их аргументов, передача их через очередь выглядит гораздо проще, чем могло бы показаться. Так, в примере 10.20 демонстрируется один из способов передачи функций обратного вызова через очередь, который будет использоваться в приложении PyMailGUI в главе 14. Этот модуль содержит также ряд полезных инструментов. Класс ThreadCounter можно использовать как совместно используемый счетчик и логический флаг (например, для управления операциями, перекрывающимися во времени). Однако наиболее важным здесь является реализация интерфейса передачи функций через очередь - в двух словах, данная реализация позволяет клиентам запускать потоки выполнения, которые помещают в очередь свои функции завершения для передачи главному потоку.
До определенной степени этот пример можно считать лишь разновидностью примера из предыдущего раздела - здесь мы по-прежнему выполняем цикл событий от таймера, в котором главный поток извлекает данные из очереди. Для большей эффективности за одно событие от таймера из очереди извлекается уже не один (что может оказаться слишком долгим, при большом количестве элементов данных, или слишком накладным, при коротком интервале срабатывания таймера) и не все (что может привести к блокированию графического интерфейса, если данные поступают слишком быстро), а до N элементов данных. Мы дополним этот прием пакетной обработки данных в PyMailGUI возможностью выполнения множественных изменений в графическом интерфейсе без необходимости выделять ресурсы процессора для обработки коротких событий от таймера, в чем обычно нет необходимости.
Однако здесь главное отличие, на которое следует обратить внимание, заключается в том, что мы вызываем объекты, которые потоки-производители обобщенным способом помещают в очередь для обработки успешного или неудачного выполнения операции в ответ на благополучное завершение или возникшее исключение. Кроме того, функции, выполняемые в потоках-производителях, принимают функцию, определяющую информацию о протекании операции, которая при вызове просто помещает в очередь обработчик индикатора хода выполнения операции, предназначенный для вызова в контексте главного потока выполнения. Эту особенность можно использовать, например, чтобы показать в графическом интерфейсе ход выполнения загрузки данных по сети.
Пример 10.20. PP4E\Gui\Tools\threadtools.py
##############################################################################
Общесистемные утилиты поддержки многопоточной модели выполнения для графических
интерфейсов.
Реализует единую очередь обработчиков и цикл обработки событий от таймера для ее проверки, совместно используемые всеми окнами в программе; рабочие потоки помещают в очередь свои обработчики завершения и протекания операции для вызова в главном потоке; эта модель не блокирует графический интерфейс - он просто выполняет операции в порождаемых дочерних потоках и обрабатывает события завершения и продолжения операций; рабочие потоки могут перекрываться во времени с главным потоком и с другими рабочими потоками.
На практике передача функций-обработчиков с аргументами через очереди намного удобнее, чем передача простых данных, если в программе одновременно могут действовать разнотипные потоки выполнения, - каждый тип может подразумевать выполнение различных действий при завершении.
Библиотеки создания графических интерфейсов не полностью поддерживают многопоточную модель, поэтому, вместо того чтобы напрямую вызывать обработчики, производящие изменение графического интерфейса после выполнения основной операции в потоке, они помещаются в общую очередь и вызываются не в дочерних потоках, а в цикле обработки событий от таймера в главном потоке; это также обеспечивает регулярность и предсказуемость моментов обновления графического интерфейса; требуется, чтобы логика потока разбивалась на основную операцию, завершающие действия и операцию, возвращающую информацию о протекании процесса.
Предполагается, что в случае неудачи функция потока возбуждает исключение и принимает в аргументе ‘progress’ функцию обратного вызова, если поддерживает возможность передачи информации о ходе выполнения операции; предполагается также, что все обработчики выполняются очень быстро, либо производят обновление графического интерфейса в процессе работы, и эта очередь будет содержать функции обратного вызова (или другие вызываемые объекты) для использования в приложениях с графическим интерфейсом, - требуется наличие виджетов, чтобы обеспечить работу цикла на основе метода ‘after’; для использования данной модели в сценариях без графического интерфейса можно было бы использовать простой таймер. ##############################################################################
# запустить, даже если нет потоков # сейчас, если модуль threads
try: # недоступен в стандартной библиотеке,
import _thread as thread # возбуждает исключение ImportError
except ImportError: # и блокирует графический интерфейс
import _dummy_thread as thread # тот же интерфейс без потоков
# общая очередь
# в глобальной области видимости, совместно используется потоками import queue, sys
threadQueue = queue.Queue(maxsize=0) # infinite size
##############################################################################
# ГЛАВНЫЙ ПОТОК - периодически проверяет очередь; выполняет действия,
# помещаемые в очередь, в контексте главного потока; один потребитель (GUI) и
# множество производителей (загрузка, удаление, отправка); простого списка
# было бы вполне достаточно, если бы операции list.append и list.pop были
# атомарными; 4 издание: в процессе обработки каждого события от таймера
# выполняет до N операций: обход в цикле всех обработчиков, помещенных в
# очередь, может заблокировать графический интерфейс, а при выполнении
# единственной операции вызов всех обработчиков может занять продолжительное
# время или привести к неэффективному расходованию ресурсов процессора на
# обработку событий от таймера (например, информирование о ходе выполнения
# операций); предполагается, что обработчики выполняются очень быстро или
# выполняют обновление графического интерфейса в процессе работы (вызывают
# метод update): после вызова обработчика планируется очередное событие от
# таймера и управление возвращается в цикл событий; поскольку этот цикл
# выполняется в главном потоке, он не препятствует завершению программы; ##############################################################################
def threadChecker(widget, delayMsecs=100, perEvent=1): # 10 раз/сек, 1/таймер for i in range(perEvent): # передайте другие значения,
try: # чтобы повысить скорость
(callback, args) = threadQueue.get(block=False) # выполнить до N
except queue.Empty: # обработчиков
break # очередь пуста?
else:
callback(*args) # вызвать обраб.
widget.after(delayMsecs, # переустановить
lambda: threadChecker(widget, delayMsecs, perEvent))# таймер и
# вернуться в цикл
# событий
##############################################################################
# НОВЫЙ ПОТОК - выполняет задание, помещает в очередь обработчик завершения и
# обработчик, возвращающий информацию о протекании процесса; вызывает функцию
# основной операции с аргументами, затем планирует вызов функций on* с
# контекстом; запланированные вызовы добавляются в очередь и выполняются в
# главном потоке, чтобы избежать параллельного обновления графического
# интерфейса; позволяет программировать основные операции вообще без учета
# того, что они будут выполняться в потоках; не вызывайте обработчики в
# потоках: они могут обновлять графический интерфейс в потоке, поскольку
# передаваемая функция будет вызвана в потоке; обработчик ‘progress’ просто
# должен добавлять в очередь функцию обратного вызова с передаваемыми ей
# аргументами; не обновляйте текущие счетчики здесь: обработчик завершения
# будет извлечен из очереди и выполнен функцией threadChecker в главном
# потоке;
##############################################################################
def threaded(action, args, context, onExit, onFail, onProgress): try:
if not onProgress: # ждать завершения этого потока
action(*args) # предполагается, что в случае неудачи будет else: # возбуждено исключение
def progress(*any):
threadQueue.put((onProgress, any + context)) action(progress=progress, *args)
except:
threadQueue.put((onFail, (sys.exc_info(), ) + context)) else:
threadQueue.put((onExit, context))
def startThread(action, args, context, onExit, onFail, onProgress=None): thread.start_new_thread(
threaded, (action, args, context, onExit, onFail, onProgress))
##############################################################################
# счетчик или флаг с поддержкой многопоточной модели выполнения: удобно
# использовать, чтобы избежать выполнения перекрывающихся во времени операций,
# когда потоки изменяют другие общие данные, помимо тех, которые изменяются
# обработчиками, помещаемыми в очередь
##############################################################################
class ThreadCounter: def __init__(self): self.count = 0
self.mutex = thread.allocate_lock() # или Threading.semaphore def incr(self):
self.mutex.acquire() # или с помощью self.mutex:
self.count += 1 self.mutex.release() def decr(self):
self.mutex.acquire() self.count -= 1 self.mutex.release()
def __len__(self): return self.count # True/False, если используется,
# как флаг
##############################################################################
# реализация самотестирования: разбивает поток на основную операцию,
# операцию завершения и операцию информирования о ходе выполнения задания ##############################################################################
if __name__ == ‘__main__’: # самотестирование при запуске в виде сценария
import time # или PP4E.Gui.Tour.scrolledtext
from tkinter.scrolledtext import ScrolledText
def onEvent(i): # реализация порождения потоков
myname = ‘thread-%s’ % i startThread(
action = threadaction,
args = (i, 3),
context = (myname,),
onExit = threadexit,
onFail = threadfail,
onProgress = threadprogress)
# основная операция, выполняемая потоком def threadaction(id, reps, progress): # то, что делает поток for i in range(reps):
time.sleep(1)
if progress: progress(i) # обработчик progress: в очередь
if id % 2 == 1: raise Exception # ошибочный номер: неудача
# обработчики завершения/информирования о ходе выполнения задания:
# передаются главному потоку через очередь
def threadexit(myname):
text.insert(‘end’, ‘%s\texit\n’ % myname) text.see(‘end’)
def threadfail(exc_info, myname):
text.insert(‘end’, ‘%s\tfail\t%s\n’ % (myname, exc_info[0])) text.see(‘end’)
def threadprogress(count, myname):
text.insert(‘end’, ‘%s\tprog\t%s\n’ % (myname, count)) text.see(‘end’)
text.update() # допустимо: выполняется в главном потоке
# создать графический интерфейс и запустить цикл обработки событий от
# таймера в главном потоке
# порождать группу рабочих потоков в ответ на каждый щелчок мышью:
# выполнение их может перекрываться во времени
text = ScrolledText()
text.pack()
threadChecker(text) # запустить цикл обработки потоков
text.bind(‘’, # в 3.x функция list необходима для получения lambda event: list(map(onEvent, range(6))) ) # всех результатов map,
# для range - нет
text.mainloop() # вход в цикл событий
Реализация модуля описывается в комментариях, а программный код самотестирования демонстрирует порядок его использования. Обратите внимание, что реализация потока выполнения разбита на основные операции, операции, выполняемые при выходе, и необязательные операции информирования о ходе выполнения задания, - основные операции выполняются в новом потоке, но другие помещаются в очередь и выполняются в главном потоке. То есть чтобы воспользоваться этим модулем, вам, по сути, необходимо разделить реализацию функции потока на действия, выполняемые в самом потоке, выполняемые после его завершения и необязательные действия информирования о ходе выполнения задания. В целом, продолжительным может быть только этап, выполняемый в пределах потока.
Если пример 10.20 запустить, как самостоятельный сценарий, по каждому щелчку мышью на виджете ScrolledTest он будет запускать шесть новых потоков выполнения, каждый из которых будет выполнять функцию threadaction. Функция, выполняемая в потоке, вызывает передаваемую ей функцию информирования о ходе выполнения задания, помещающую обработчик обратного вызова в очередь, который вызывает функцию threadprogress в главном потоке. Когда функция потока завершается, интерфейсный уровень помещает в очередь обработчик, который вызовет threadfail или threadexit в главном потоке, в зависимости от того, возбудила функция потока исключение или нет. Так как все обработчики, помещаемые в очередь, извлекаются и выполняются в цикле обработки событий от таймера в главном потоке, это означает, что все изменения в графическом интерфейсе будут производиться только в главном потоке выполнения и не будут перекрываться во времени.
На рис. 10.12 приводится фрагмент вывода, сгенерированного щелчком мыши на окне. Все сообщения о завершении, неудаче и информирующие о ходе выполнения задания, создаются обработчиками, добавляемыми в очередь дочерними потоками и вызываемыми в цикле обработки событий от таймера в главном потоке.
Рис. 10.12. Сообщения, создаваемые обработчиками, извлекаемыми из очереди
Внимательно рассмотрите этот пример и попробуйте последить логику работы программного кода самотестирования. Это достаточно сложное задание, и вам, вероятно, придется не один раз пробежать по нему глазами, чтобы понять, как он действует. Однако как только вы уловите суть этой парадигмы, вы поймете общую схему работы с разнородными потоками выполнения обобщенным способом. В PyMailGUI, например, когда требуется запустить прием/передачу почты, выполняются операции, похожие на операции в функции onEvent в реализации самотестирования в данном примере.
Передача связанных методов в очередь
Технически, чтобы обеспечить еще более высокую гибкость этой схемы, в приложении PyMailGUI из главы 14 с помощью этого модуля в очередь будут помещаться связанные методы - вызываемые объекты, которые, как упоминалось, хранят ссылку на функцию метода и на экземпляр объекта, что обеспечивает возможность доступа к данным объекта и другим его методам. При таком подходе программный код управления потоками выполнения в клиентском сценарии выглядит примерно так, как показано в примере 10.21 - версии реализации самотестирования из предыдущего примера, использующей классы и методы.
Пример 10.21. PP4E\Gui\Tools\threadtools-test-classes.py
# тест очереди обработчиков, но для реализации операций используются
# связанные методы
import time
from threadtools import threadChecker, startThread from tkinter.scrolledtext import ScrolledText
class MyGUI:
def __init__(self, reps=3):
self.reps = reps # используется окно Tk по умолчанию
self.text = ScrolledText() # сохранить виджет в атрибуте
self.text.pack()
threadChecker(self.text) # запустить цикл проверки потоков
self.text.bind(‘’, # в 3.x функция list необходима для lambda event: list(map(self.onEvent, range(6))) ) # получения всех
# результатов map, для range - нет
def onEvent(self, i): # метод, запускающий поток
myname = ‘thread-%s' % i startThread(
action = self.threadaction,
args = (i, ),
context = (myname,),
onExit = self.threadexit,
onFail = self.threadfail,
onProgress = self.threadprogress)
# основная операция, выполняемая потоком
def threadaction(self, id, progress): # то, что делает поток
for i in range(self.reps): # доступ к данным в объекте
time.sleep(1)
if progress: progress(i) # обработчик progress: в очередь
if id % 2 == 1: raise Exception # ошибочный номер: неудача
# обработчики: передаются главному потоку через очередь def threadexit(self, myname):
self.text.insert(‘end’, ‘%s\texit\n' % myname) self.text.see(‘end’)
def threadfail(self, exc_info, myname): # имеет доступ к данным объекта self.text.insert(‘end’, ‘%s\tfail\t%s\n’ % (myname, exc_info[0])) self.text.see(‘end’)
def threadprogress(self, count, myname):
self.text.insert(‘end’, ‘%s\tprog\t%s\n’ % (myname, count)) self.text.see(‘end’)
self.text.update() # допустимо: выполняется в главном потоке
if __name__ == ‘__main__’: MyGUI().text.mainloop()
В этой версии в качестве обработчиков завершения и информирования о ходе выполнения задания, помещаемых в очередь, а также основной операции, выполняемой потоком, используются связанные методы. Как мы узнали в главе 5, благодаря тому что все потоки выполняются в пределах одного и того же процесса и в одной и той же области памяти, связанные методы ссылаются на оригинальные экземпляры объектов, а не на их копии. Это позволяет им напрямую обновлять графический интерфейс и другую информацию. Кроме того, связанные методы являются нормальными вызываемыми объектами, которые могут использоваться взамен обычных функций, поэтому нет никаких препятствий к использованию их в очередях и в потоках выполнения. Помимо всего прочего, широкие возможности совместного использования данных являются одним из основных преимуществ потоков выполнения перед процессами.
Приложение PyMailGUI в главе 14 демонстрирует более практичное применение этого модуля, где он служит базовым механизмом обслуживания событий завершения потоков и информирования о ходе выполнения задания. Там основные операции в потоках также выполняются с помощью связанных методов, что позволяет потокам и обработчикам, помещаемым ими в очередь, использовать одни и те же данные. Как мы увидим далее, действия, выполняемые обработчиками из очереди, автоматически становятся безопасными в многопоточном окружении, потому что они выполняются только в контексте главного потока. Однако другие изменения в совместно используемых объектах, производимые дочерними потоками, все еще может потребоваться синхронизировать отдельно, если они выполняются без применения очереди обработчиков и есть вероятность, что они будут перекрываться во времени. Непосредственное обновление кэша электронной почты, например, может заблокировать выполнение других операций до его завершения.
Другие способы добавления GUI к сценариям командной строки
Иногда потребность в графическом интерфейсе возникает совершенно неожиданно. Возможно, вы еще не умеете программировать графические интерфейсы или просто хотите оставаться в старых добрых временах. Но, предположим, вы написали программу, взаимодействующую с пользователем посредством консоли, а потом решили, что взаимодействие через графический интерфейс сделает ее привлекательнее. Что делать в этом случае?
Вероятно, наиболее очевидный ответ состоит в том, чтобы преобразовать программу командной строки, - добавить в программный код инициализацию виджетов при запуске, вызвать функцию mainloop, чтобы запустить цикл обработки событий и отобразить главное окно, и переместить всю логику программы в обработчики, запускаемые в ответ на действия пользователя. Все операции, выполняемые оригинальной программой, превращаются в обработчики событий, а главный поток управления конструирует главное окно, вызывает цикл событий один раз и переходит в состояние ожидания.
Это традиционный способ организации программ с графическим интерфейсом, и он полностью соответствует ожиданиям пользователя - окна появляются по запросу, а не случайным, на первый взгляд, образом. Однако если вы не готовы стиснуть зубы и выполнить такое структурное преобразование, можно пойти другим путем. Например, в разделе, посвященном примеру ShellGui, выше в этой главе, мы видели, как можно добавить к сценариям архивирования файлов окна для ввода входных параметров (пример 10.5 и следующие за ним). Позднее мы также видели, как перенаправлять вывод таких сценариев в графические интерфейсы с помощью класса GuiOutput (пример 10.13). Этот подход можно использовать, когда сценарий командной строки, обертываемый в графический интерфейс, выполняет единственную операцию. Для организации более динамичного взаимодействия с пользователем может потребоваться использовать другие приемы.
Вполне возможно, например, запускать графический интерфейс из сценария командной строки, вызывая функцию mainloop из библиотеки tkinter всякий раз когда требуется отобразить окно. Возможно также использовать более фундаментальный подход и создать отдельную программу, реализующую графический интерфейс для вашего приложения. В заключение нашего обзора методик программирования графических интерфейсов мы по очереди рассмотрим все эти схемы.
Вывод окон графического интерфейса по требованию
Если вам необходимо добавить простой графический интерфейс для взаимодействия с пользователем к существующему сценарию командной строки (например, диалог выбора файла), это можно сделать, настроив виджеты и вызвав функцию mainloop из программы командной строки, когда это будет необходимо. По сути, этот прием добавляет поддержку графического интерфейса в программу, не имеющую постоянного главного окна. Проблема в том, что функция mainloop не возвращает управление, пока главное окно не будет закрыто пользователем (или не будет вызван метод quit). Поэтому вы не сможете получить данные, введенные пользователем, из виджетов, уже уничтоженных к моменту возврата из функции mainloop. Чтобы обойти эту проблему, достаточно просто сохранить ввод пользователя в объекте Python: объект останется существовать после уничтожения графического интерфейса. Пример 10.22 демонстрирует один из способов реализации этой идеи на языке Python.
Пример 10.22. PP4E\Gui\Tools\mainloopdemo.py
демонстрирует запуск двух отдельных циклов mainloop; каждый из них возвращает управление после того как главное окно будет закрыто; ввод пользователя сохраняется в объекте Python перед тем, как графический интерфейс будет закрыт; обычно в программах с графическим интерфейсом настройка виджетов и вызов mainloop выполняется всего один раз, а вся их логика распределена по обработчикам событий; в этом демонстрационном примере вызовы функции mainloop производятся для обеспечения модальных взаимодействий с пользователем из программы командной строки; демонстрирует один из способов добавления графического интерфейса к существующим сценариям командной строки без реорганизации программного кода;
from tkinter import *
from tkinter.filedialog import askopenfilename, asksaveasfilename
class Demo(Frame):
def __init__(self,parent=None):
Frame.__init__(self,parent)
self.pack()
Label(self, text =”Basic demos”).pack()
Button(self, text=’open’, command=self.openfile).pack(fill=BOTH) Button(self, text=’save’, command=self.savefile).pack(fill=BOTH) self.open_name = self.save_name = “”
def openfile(self): # сохранить результаты пользователя
self.open_name = askopenfilename() # указать параметры диалога здесь def savefile(self):
self.save_name = asksaveasfilename(initialdir=’C:\\Python31’)
if__name__== “__main__”:
# вывести окно print(‘popup1...’)
mydialog = Demo() # присоединить фрейм к окну Tk() по умолчанию
mydialog.mainloop() # отобразить; вернуться после закрытия окна
print(mydialog.open_name) # имена сохраняются в объекте, когда окно уже print(mydialog.save_name) # будет закрыто
# Раздел программы без графического интерфейса, использующей mydialog
# отобразить окно еще раз print(‘popup2...’)
mydialog = Demo() # повторно создать виджеты
mydialog.mainloop() # повторно отобразить окно
print(mydialog.open_name) # в объекте будут сохранены новые значения print(mydialog.save_name)
# Раздел программы без графического интерфейса,
# где снова используется mydialog print(‘ending...’)
Эта программа дважды конструирует и отображает простое окно с двумя кнопками, как показано на рис. 10.13, нажатие которых вызывает появление диалогов выбора файла. Вывод программы, который производится при закрытии окна графического интерфейса, выглядит примерно, как показано ниже:
C:\...\PP4E\Gui\Tools> mainloopdemo.py
popup1...
C:/Users/mark/Stuff/Books/4E/PP4E/dev/Examples/PP4E/Gui/Tools/widgets.py
C:/Python31/python.exe
popup2...
C:/Users/mark/Stuff/Books/4E/PP4E/dev/Examples/PP4E/Gui/Tools/guimixin.py
C:/Python31/Lib/tkinter/__init__.py
ending...
Рис. 10.13. Окно, которое выводится программой командной строки
Обратите внимание, что в этой программе функция mainloop вызывается дважды, для организации двух модальных взаимодействий с пользователем из сценария командной строки, не имеющего графического интерфейса. Нет ничего криминального в том, что функция mainloop вызывается более одного раза, но при этом сценарию приходится заново создавать виджеты перед очередным вызовом, потому что они уничтожаются после предыдущего вызова mainloop (виджеты уничтожаются внутри библиотеки Tk, даже если соответствующие им объекты Python продолжают существование). Напомню, что такая реализация графического интерфейса не соответствует ожиданиям пользователей, в сравнении с традиционными графическими интерфейсами, - создается впечатление, что окна появляются из ниоткуда, - но это самый быстрый способ добавить графический интерфейс без глубокой реорганизации программного кода.
Обратите внимание, что данный пример отличается от случая использования вложенных (рекурсивных) вызовов функции mainloop для реализации модальных диалогов, с которым мы столкнулись в главе 8. При таком подходе вложенные вызовы mainloop возвращают управление, когда вызывается метод quit диалога, но при этом продолжается выполнение объемлющего вызова mainloop, и мы остаемся в сфере программирования, управляемого событиями. Сценарий в примере 10.22, напротив, производит два независимых вызова функции mainloop, дважды вступая и выходя из модели, управляемой событиями.
Наконец, обратите внимание, что такая схема подходит только для ситуаций, когда не требуется выполнять какие-либо операции, не связанные с графическим интерфейсом, пока окно остается открытым, потому что на период выполнения mainloop основной поток управления сценария остается неактивным и блокируется. Вы не сможете, например, применить этот подход для добавления графического интерфейса к утилитам, подобным тем, что используются в модуле guiStreams, представленном выше в этой главе, предназначенном для передачи функций взаимодействия с пользователем из сценариев командной строки в графический интерфейс. Классы GuiInput и GuiOutput в том примере предполагают, что где-то уже был произведен вызов mainloop (в конце концов, они опираются на использование графического интерфейса). Но как только будет вызвана функция mainloop, чтобы вывести окна, вы не сможете вернуть управление обычному программному коду сценария командной строки, чтобы взаимодействовать с пользователем или с графическим интерфейсом, пока этот графический интерфейс не будет закрыт и функция mainloop не вернет управление. Таким образом, эти классы могут использоваться только в контексте программ, полностью опирающихся на графический интерфейс.
Но на самом деле это неестественный способ использования библиотеки tkinter. Сценарий в примере 10.22 действует только потому, что графический интерфейс может взаимодействовать с пользователем совершенно независимо, - сценарий может позволить себе отдать управление функции mainloop из библиотеки tkinter и ждать результатов. Эта схема непригодна, когда требуется выполнять программный код, не имеющий отношения к графическому интерфейсу, в то время, когда окно остается открытым. Из-за этих ограничений в большинстве графических интерфейсов вам придется использовать модель главное-окно-плюс-обработчики-событий - обработчики вызываются в ответ на действия пользователя, пока окно графического интерфейса остается открытым. При таком подходе ваш программный код может действовать, пока окно остается открытым. Например, смотрите представленный ранее в этой главе способ запуска сценариев командной строки архивирования и разархивирования из графического интерфейса, с выводом результатов в графическом интерфейсе, - технически эти сценарии запускаются из обработчиков событий графического интерфейса, а их вывод перенаправляется в виджет.
Реализация графического интерфейса в виде отдельной программы: сокеты (вторая встреча)
Как отмечалось ранее, возможно также реализовать графический интерфейс приложения в виде отдельной программы. Это наиболее тернистый путь, но в некоторых ситуациях он может упростить интеграцию слабо связанных компонентов. Этот способ может, например, помочь решить проблемы, свойственные примеру guiStreams из предыдущего раздела, при условии, что входные и выходные данные будут передаваться графическому интерфейсу через механизмы взаимодействий между процессами (Inter-Process Communication, IPC), а для обнаружения выходных данных будет использован метод after виджетов (или подобный ему). В этом случае работа сценария командной строки не блокируется вызовом функции mainloop.
Графический интерфейс может запускаться сценарием командной строки как отдельная программа, и обмениваться результатами взаимодействий с пользователем с основным сценарием посредством каналов, сокетов, файлов или других механизмов IPC, представленным в главе 5. Преимущество такого подхода состоит в том, что он обеспечивает разделение представления и реализации - в сценарий, который иначе может использоваться как обычная утилита командной строки, достаточно будет добавить всего лишь запуск графического интерфейса и организовать прием ввода пользователя. Кроме того, работа сценария командной строки не будет блокироваться на время работы функции mainloop (функция mainloop будет выполняться только в процессе, реализующем графический интерфейс), а сам графический интерфейс может сохраняться на экране и после того, как пользователь введет все необходимые данные, что позволит уменьшить количество всплывающих окон.
Другой вариант - когда графический интерфейс запускает сценарий командной строки и организует прием данных от него с применением механизмов IPC, подключаемых к потоку стандартного вывода сценария. В еще более сложных решениях графический интерфейс и сценарий командной строки могут организовать двусторонний обмен данными.
Примеры 10.23, 10.24 и 10.25 демонстрируют простые варианты реализации этих подходов: вывод сценария командной строки отправляется в графический интерфейс. В них представлены реализации сценариев командной строки и графического интерфейса, которые взаимодействуют друг с другом через сокеты - механизм сетевых взаимодействий, который коротко рассматривался в главе 5 и подробно будет исследоваться в следующей части книги. При изучении этих файлов особое внимание обратите на то, как организована связь между программами: когда сценарий командной строки выводит что-то в стандартный поток вывода, текст отправляется графическому интерфейсу через сетевое соединение. Кроме того, что он импортирует модуль и вызывает функцию перенаправления вывода в сокет, сценарий командной строки ничего не знает ни о графических интерфейсах, ни о сокетах, а графический интерфейс ничего не знает о сценарии, вывод которого он отображает. Так как эта модель не требует полностью переписывать существующие сценарии, чтобы добавить к ним поддержку графического интерфейса, она является идеальной для сценариев, которые живут и действуют в мире командных оболочек и командной строки.
С точки зрения реализации, нам сначала необходимо создать механизм IPC, который свяжет сценарий с графическим интерфейсом. Пример 10.23 содержит реализацию подключения к сокетам на стороне клиента, используемую сценарием командной строки. В данный момент представлена только частичная реализация модуля (обратите внимание на оператор многоточия ... в последних нескольких функциях - своего рода фразу «Подлежит реализации» на языке Python; этот оператор является эквивалентом инструкции pass в данном контексте). Так как подробно сокеты будут рассматриваться только в главе 12, мы отложим реализацию других режимов перенаправления до этого момента; там также будет представлена остальная часть реализации этого модуля. Версия модуля, представленная здесь, реализует перенаправление в сокет только потока стандартного вывода и отлично подходит для графического интерфейса, которому требуется перехватить вывод сценария командной строки.
Пример 10.23. PP4E\Gui\Tools\socket_stream_redirect0.py
[частичная реализация] Инструменты подключения потоков ввода-вывода сценариев командной строки к сокетам, которые могут использоваться графическими интерфейсами (и другими сценариями) для взаимодействий с этими сценариями; более полное обсуждение и реализацию вы найдете в главе 12 и в каталоге PP4E\Sockets\ Internet
import sys
from socket import * port = 50008 host = ‘localhost’
def redirectOut(port=port, host=host):
подключает стандартный поток вывода вызывающего сценария к сокету, для передачи данных графическому интерфейсу, прослушивающему сетевое соединение;
вызывающий сценарий должен запускаться после того как будет запущен сценарий или графический интерфейс, прослушивающий сетевое соединение, иначе connect потерпит неудачу до того, как будет выполнена функция accept
sock = socket(AF_INET, SOCK_STREAM)
sock.connect((host, port))# вызывающий сценарий играет роль клиента file = sock.makefile(‘w’) # интерфейс файлов: текстовый режим, буферизация sys.stdout = file # заставить функцию print выводить текст
# с помощью sock.send
def redirectIn(port=port, host=host): ... # см. главу 12
def redirectBothAsClient(port=port, host=host): ... # см. главу 12 def redirectBothAsServer(port=port, host=host): ... # см. главу 12
Далее, пример 10.24 использует пример 10.23 для перенаправления потока стандартного вывода в сетевое соединение, которое может прослушиваться серверной программой, реализующей графический интерфейс. Для этого требуется добавить в начало сценария всего две строки программного кода, которые выполняются в зависимости от наличия аргумента командной строки (если сценарий запускается без аргументов, он выполняется в обычном режиме):
Пример 10.24. PP4E\Gui\Tools\socket-nongui.py
# сценарий командной строки: подключает поток вывода к сокету
# и действует как обычно
import time, sys
if len(sys.argv) > 1: # подключаться к GUI только при явном требовании
from socket_stream_redirect0 import * # подключить sys.stdout к сокету redirectOut() # GUI должен запускаться первым
# программный код, не связанный с графическим интерфейсом
while True: # выводит данные в stdout:
print(time.asctime()) # передать процессу GUI через сокет
sys.stdout.flush() # требуется для передачи: буферизация!
time.sleep(2.0) # небуферизованный режим отсутствует
# ключ -u не решает проблему
И наконец, в примере 10.25 приводится реализация графического интерфейса, участвующего в обмене данными. Этот сценарий создает графический интерфейс для отображения текста, выводимого программой командной строки, но он ничего не знает о логике работы другой программы. Для отображения получаемого текста графический интерфейс использует объект перенаправления потока вывода в виджет, с которым мы встречались выше в этой главе (пример 10.12), - поскольку данная программа вызывает функцию mainloop, этот объект «просто работает».
Кроме того, для проверки наличия входных данных в сокете здесь используется цикл обработки событий от таймера, вместо того чтобы ждать завершения программы командной строки. Поскольку сокет настраивается на работу в неблокирующем режиме, операция ввода не ждет, пока появятся данные, и не блокирует графический интерфейс.
Пример 10.25. PP4E\Gui\Tools\socket-gui.py
# сервер GUI: читает и отображает текст, полученный
# от сценария командной строки
import sys, os
from socket import * # включая socket.error
from tkinter import Tk
from PP4E.launchmodes import PortableLauncher
from PP4E.Gui.Tools.guiStreams import GuiOutput myport = 50008
sockobj = socket(AF_INET, SOCK_STREAM) # GUI - сервер, сценарий - клиент sockobj.bind((‘’, myport)) # сервер настраивается перед
sockobj.listen(5) # запуском клиента
print(‘starting’)
PortableLauncher(‘nongui’, ‘socket-nongui.py -gui’)() # запустить сценарий print('accepting’)
conn, addr = sockobj.accept() # ждать подключения клиента
conn.setblocking(False) # неблокирующий сокет (False=0)
print('accepted')
def checkdata(): try:
message = conn.recv(1024) # попытка ввода не блокируется #output.write(message + ‘\n’) # можно также сделать sys.stdout=output
print(message, file=output) # если текст получен - вывести в окне except error: # возбудит socket.error, если нет данных
print(‘no data’) # вывести в sys.stdout
root.after(1000, checkdata) # проверять раз в секунду
root = Tk()
output = GuiOutput(root) # текст из сокета отображается здесь
checkdata()
root.mainloop()
Запустите сценарий из примера 10.25, чтобы протестировать весь комплекс. Когда запустятся оба процесса, графический интерфейс и сценарий командной строки, графический интерфейс примерно каждые две секунды будет получать через сокет новые сообщения и отображать их в окне, как показано на рис. 10.14. Цикл обработки событий от таймера в графическом интерфейсе проверяет поступление новых данных примерно раз в секунду, но сценарий командной строки отправляет сообщения только раз в две секунды, из-за задержки, организованной с помощью функции time.sleep. Ниже приводится пример вывода в окно консоли - сообщения «no data» в консоли и новые строки в графическом интерфейсе появляются каждую секунду:
C:\...\PP4E\Gui\Tools> socket-gui.py
starting
nongui
accepting
accepted
no data
no data
no data
no data
...часть строк опущена...
Рис. 10.14. Сообщения от сценария командной строки, выводимые графическим интерфейсом (сокеты)
Обратите внимание на рис. 10.14, что мы отображаем строки типа bytes, - несмотря на то, что сценарий командной строки выводит текст, сценарий графического интерфейса получает строки байтов, потому что читает их, используя низкоуровневый интерфейс сокетов, а сокеты в Python 3.X обрабатывают данные в виде строк двоичных байтов.
Запустите этот сценарий у себя на компьютере, чтобы посмотреть, как он действует. В общих чертах, сценарий графического интерфейса запускает сценарий командной строки и отображает окно, в которое выводит текст, печатаемый сценарием командной строки (дата и время). Сценарий командной строки может по-прежнему выполнять линейный процедурный программный код и воспроизводить данные, потому что только процесс графического интерфейса выполняет цикл событий mainloop.
Кроме того, в отличие от ранее исследованных нами приемов перенаправления, когда мы просто подключали потоки ввода-вывода сценария к объектам графического интерфейса, данный подход деления на два процесса предотвращает блокирование графического интерфейса в ожидании, пока сценарий выведет какие-либо данные. Процесс графического интерфейса остается полностью независимым и активным и просто извлекает новые результаты по мере их поступления (подробнее об этом рассказывается в следующем разделе). Данная модель по духу напоминает предыдущие примеры с потоками выполнения и очередями, только здесь главными действующими лицами являются отдельные программы, связанные с помощью сокета, а не вызовы функций в контексте единого процесса.
Мы не будем подробно рассматривать сокеты в этой главе, чтобы объяснить их применение в этом программном коде, тем не менее следует подчеркнуть несколько наиболее важных моментов:
• Вероятно, этот пример следовало бы дополнить возможностью определения признака конца файла, отправляемого дочерним сценарием, и завершать цикл обработки событий от таймера.
• Сценарий командной строки мог бы сам запускать графический интерфейс, но в мире сокетов серверный конец (графический интерфейс) должен быть настроен на прием входящих соединений раньше, чем клиент (сценарий командной строки) попытается соединиться с ним. Так или иначе, графический интерфейс должен быть запущен еще до того, как сценарий командной строки попытается установить соединение, иначе соединение не будет установлено и сценарий потерпит неудачу.
• Из-за поддержки буферизации в текстовом режиме, свойственной объектам socket.makefile, используемым здесь для перенаправления потока вывода, клиентская программа обязательно должна выталкивать выходной буфер с помощью sys.stdout.flush, чтобы отправить данные графическому интерфейсу, - без вызова этого метода графический интерфейс ничего не будет получать и отображать. Как будет показано в главе 12, этот прием не обязательно применять при использовании каналов, но обязательно - при работе с обертками сокетов, как в данном примере. В Python 3.X эти обертки не поддерживают небуферизованные режимы и не имеют ключа командной строки, такого как -u, для данного контекста (дополнительные сведения о ключе -u и о каналах приводятся в следующем разделе).
Дополнительную информацию к этому примеру и по данной теме вы найдете в главе 12. Модель клиент-сервер на основе сокетов неплохо подходит для соединения графического интерфейса со сценариями командной строки, но существуют и другие альтернативы, которые мы рассмотрим в следующем разделе, прежде чем двинуться дальше.
Реализация графического интерфейса в виде отдельной программы: каналы
Объединение двух программ в предыдущем разделе напоминает программу с графическим интерфейсом, которая читает вывод команды, запущенной с помощью os.popen (или с помощью интерфейса subprocess. Popen, который опирается на эту функцию). Как будет показано далее, сокеты также поддерживают возможность обмена данными с независимыми серверами и могут использоваться для соединения программ, выполняющихся на разных компьютерах в сети, однако эту идею мы будем рассматривать в главе 12.
Пожалуй, еще более тонким и важным для нашего исследования графических интерфейсов является тот факт, что без цикла обработки со-
бытий от таймера на основе метода after и неблокирующей операции чтения данных, подобной той, что использовалась в предыдущем разделе, графический интерфейс может блокироваться в ожидании поступления данных от программы командной строки и оказаться неспособным обрабатывать более одного потока данных.
Предлагаю взглянуть на функцию redirectedGuiShellCmd в примере 10.12, перенаправляющую вывод команды оболочки, запускаемой с помощью os.popen, в окно графического интерфейса. Мы могли бы использовать простейший программный код, как в примере 10.26, чтобы перехватить вывод порожденной программы на языке Python и отобразить его в окне отдельной программы с графическим интерфейсом. Решение получилось таким компактным благодаря тому, что оно опирается на цикл чтения/записи и на класс GuiOutput из примера 10.12 для управления графическим интерфейсом и чтения данных из канала. Это решение, по сути, повторяет один из вариантов реализации самотестирования в том примере, но здесь мы читаем вывод программы на языке Python.
Пример 10.26. PP4E\Gui\Tools\pipe-gui1.py
# графический интерфейс: перенаправляет стандартный вывод порождаемой
# программы в окно GUI
from PP4E.Gui.Tools.guiStreams import redirectedGuiShellCmd # исп-ет GuiOutput
redirectedGuiShellCmd(‘python -u pipe-nongui.py’) # -u: без
# буферизации
Обратите внимание на ключ -u командной строки интерпретатора Python, используемый здесь: он принудительно отключает буферизацию потока стандартного вывода запускаемой программы, поэтому мы получаем печатаемый текст немедленно и нам не приходится ждать завершения дочерней программы.
Мы говорили об этой возможности в главе 5, когда обсуждали каналы и состояния взаимоблокировки. Напомню, что функция print выводит текст в sys.stdout, который обычно предусматривает буферизацию при подключении к каналу таким способом. Если бы мы здесь не использовали ключ -u и порожденная программа не вызывала бы метод sys. stdout.flush, мы ничего не увидели бы в графическом интерфейсе, пока дочерняя программа не завершилась бы или пока не переполнился буфер. Если дочерняя программа выполняет бесконечный цикл, нам может потребоваться ждать очень долго, пока вывод появится в канале и, соответственно, в графическом интерфейсе.
Такой подход значительно упрощает реализацию сценария командной строки, как показано в примере 10.27: он просто выводит текст в стандартный поток вывода и ему не требуется выполнять подключение к сокету. Сравните его с эквивалентной реализацией на основе сокетов, представленной в примере 10.24, - цикл тот же самый, но здесь не требуется предварительно выполнять подключение к сокету (родительская программа читает обычный поток вывода) и нет необходимости вручную выталкивать выходной буфер (ключ -u, указанный при запуске дочерней программы, отключает буферизацию).
Пример 10.27. PP4E\Gui\Tools\pipe-nongui.py
# сценарий командной строки: действует как обычно, не требует выполнения
# дополнительных операций import time
while True: # реализация сценария командной строки
print(time.asctime()) # отправить процессу GUI time.sleep(2.0) # выталкивать буфер здесь не требуется
Запустите сценарий графического интерфейса из примера 10.26: он автоматически запустит сценарий командной строки, подключится к его потоку стандартного вывода и отобразит окно, как показано на рис. 10.15. Своим внешним видом оно напоминает окно сценария, реализованного на основе сокетов, изображенное на рис. 10.14, но в данном случае будут выводиться строки str, которые мы получаем при чтении каналов, а не строки байтов, как при чтении из сокетов.
Рис. 10.15. Сообщения от сценария командной строки, выводимые графическим интерфейсом (каналы)
Сценарии действуют, но реализация графического интерфейса выглядит несколько странно - в ней отсутствует явный вызов функции main-loop, и мы получаем дополнительное пустое окно верхнего уровня по умолчанию. Фактически этот графический интерфейс действует лишь благодаря вызову метода update внутри функции перенаправления, который на мгновение передает управление циклу событий Tk, чтобы обработать ожидающие события. Более удачное решение представлено в примере 10.28. Этот сценарий создает графический интерфейс и запускает цикл событий вручную до того, как будет запущена команда оболочки, - при ее запуске воспроизводится то же самое окно (рис. 10.15).
Пример 10.28. PP4E\Gui\Tools\pipe-gui2.py
# графический интерфейс: действует так же, как pipes-gui1, но явно создает
# главное окно и запускает цикл событий
from tkinter import *
from PP4E.Gui.Tools.guiStreams import redirectedGuiShellCmd def launch():
redirectedGuiShellCmd(‘python -u pipe-nongui.py’) window = Tk()
Button(window, text=’GO!’, command=launch).pack() window.mainloop()
Ключ -u, отключающий буферизацию, здесь также имеет большое значение - без него мы не увидели бы текст в окне вывода. Графический интерфейс оказался бы заблокирован в первой операции чтения из канала, потому что текст, выводимый дочерним сценарием, оставался бы в буфере потока стандартного вывода.
С другой стороны, наличие ключа -u, запрещающего буферизацию, не предотвращает блокирование графического интерфейса из предыдущего раздела, использующего сокеты, потому что в том примере после запуска дочерней программы поток вывода переключается на другой объект. Дополнительные сведения об этом приводятся в главе 12. Запомните также, что аргумент функции os.popen (и subprocess.Popen), определяющий параметры буферизации, управляет буферизацией только на стороне вызывающего процесса, но не в порожденной программе, тогда как ключ -u передается при запуске последней.
Призрак блокирования операций чтения
Однако при любом подходе графические интерфейсы в примерах 10.26 и 10.28 оказываются заблокированными на две секунды каждый раз, когда пытаются прочитать данные из канала с помощью os.popen. На практике интерфейсы становятся очень неповоротливыми - команды переместить окно, изменить его размер, перерисовать, поднять над другими окнами и так далее ожидают до двух секунд, пока сценарий командной строки не отправит данные графическому интерфейсу и тем самым не обеспечит возврат из функции чтения канала. Еще хуже то, что если щелкнуть на кнопке GO! дважды во второй версии графического интерфейса, только одно окно будет обновляться каждые две секунды, потому что графический интерфейс «застрянет» в обработчике события нажатия кнопки - он не сможет выйти из цикла чтения, пока дочерний сценарий командной строки не завершится. Завершение работы программы также выполняется не очень изящно (в окне консоли появится множество сообщений об ошибках).
Из-за этих ограничений - чтобы избежать заблокированных состояний - независимо запускаемый графический интерфейс не должен читать данные непосредственно, если могут возникать задержки в отображении. Например, в сценарии из предыдущего раздела (пример 10.25), использующем сокеты, цикл обработки событий от таймера after позволяет графическому интерфейсу проверять наличие данных вместо того, чтобы ждать их, и отображать по мере появления. Поскольку графический интерфейс не ждет, пока данные появятся, он остается активным между операциями вывода.
Конечно, истинная причина этих проблем заключается в том, что цикл чтения/записи в используемой здесь функции из модуля guiStreams слишком упрощен - ошибочное размещение операции чтения в графическом интерфейсе провоцирует блокировку. Существуют различные решения, позволяющие избежать этого.
Обновление графических интерфейсов
внутри потоков выполнения... и другие «решения»
Чтобы исправить эту проблему, можно было бы попробовать вызывать функцию перенаправления в дочернем потоке выполнения, например, изменив функцию launch в примере 10.28, как показано ниже (этот фрагмент взят из сценария pipe-gui2-thread.py, входящего в состав пакета с примерами для книги):
def launch():
import _thread
_thread.start_new_thread(redirectedGuiShellCmd,
(‘python -u pipe-nongui.py’,))
Но тогда графический интерфейс будет обновляться из дочернего потока выполнения, что, как мы уже знаем, заканчивается плохо. Параллельные попытки обновления графического интерфейса могут нанести ему вред.
Фактически, после внесения предложенных изменений на моем ноутбуке с Windows 7, графический интерфейс зависает сразу же после первого щелчка на кнопке GO!, становясь совершенно неотзывчивым, и его приходится закрывать принудительно. Это происходит до (или, может быть, во время) создания нового окна с текстовым виджетом. Когда этот пример запускался в Windows XP, во время работы над предыдущим изданием книги, он также иногда подвисал при первом щелчке на кнопке GO!, а несколько щелчков на кнопке гарантированно подвешивали его и в этой системе - процесс приходилось останавливать принудительно. Прямое обновление графического интерфейса из дочерних потоков выполнения не является приемлемым решением.
Как вариант, можно было бы попробовать использовать функцию Python select. select (описывается в главе 12) для реализации проверки наличия данных в канале - к сожалению, в настоящее время функция select в Windows работает только с сокетами (в Unix она также работает с каналами и с дескрипторами файлов).
В некоторых контекстах графический интерфейс, запускаемый отдельно, мог бы использовать сигналы для информирования программы командной строки о наступлении момента обмена данными, и наоборот (с помощью модуля signal и функции os.kill, представленных в главе 5). Недостаток такого решения состоит в том, что он требует добавлять обработку сигналов в реализацию программы командной строки.
Альтернативой сокетам в примерах с 10.23 по 10.25 могли бы в определенных ситуациях служить именованные каналы (файлы fifo, представленные в главе 5), но сокеты работают в стандартной версии Python для Windows, а именованные каналы - нет (функция os.mkfifo недоступна в версии Python 3.1 для Windows, хотя она имеется в версии Cygwin Python). Но даже там, где они работают, нам все еще необходимо использовать цикл обработки событий от таймера на основе метода after, чтобы избежать блокирования графического интерфейса.
Также мы могли бы использовать функцию createfilehandler из библиотеки tkinter, чтобы зарегистрировать обработчик, который будет вызываться при появлении данных в канале:
def callback(file, mask):
...чтение данных из файла...
import _tkinter, tkinter
_tkinter.createfilehandler(file, tkinter.READABLE, callback)
Операция регистрации обработчика доступна в виде функции в модуле tkinter и в виде метода экземпляра класса Tk. К сожалению, как уже отмечалось в конце главы 9, эта функция недоступна в Windows и может служить альтернативой только в Unix.
Предотвращение блокирования операций чтения с помощью потоков выполнения
Намного более универсальное решение проблемы блокирования операций чтения заключается в том, чтобы графический интерфейс порождал дочерний поток, который будет читать данные из сокета или канала и помещать их в очередь. Фактически прием, основанный на потоках выполнения, с которым мы встречались выше в этой главе, можно было бы напрямую использовать для решения данной проблемы. При таком подходе, пока поток выполнения ждет поступления данных, графический интерфейс не блокируется, а поток выполнения не пытается обновлять графический интерфейс. Кроме того, одновременно могут выполняться несколько потоков и производить продолжительные операции.
Пример 10.29 демонстрирует реализацию этого решения. Основная хитрость состоит в том, чтобы отделить операции ввода и вывода в оригинальной функции redirectedGuiShellCmd из модуля guiStreams, представленного в примере 10.12. В той версии операция ввода запускается в параллельном потоке выполнения и не блокирует графический интерфейс. Главный поток графического интерфейса использует цикл обработки событий от таймера after как обычно - чтобы проверять наличие данных в общей очереди, добавляемых потоком чтения. Так как главный поток сам не занимается чтением вывода дочерней программы, он не блокируется в ожидании поступления новых данных.
Пример 10.29. PP4E\Gui\Tools\pipe_gui3.py
читает данные из канала в отдельном потоке выполнения и помещает их в очередь, которая проверяется в цикле обработки событий от таймера; позволяет сценарию отображать вывод программы, не вызывая блокирование графического интерфейса между операциями вывода; со стороны дочерних программ не требуется выполнять подключение или выталкивать буферы, но данное решение сложнее, чем подход на основе сокетов
import _thread as thread, queue, os from tkinter import Tk
from PP4E.Gui.Tools.guiStreams import GuiOutput stdoutQueue = queue.Queue() # бесконечной длины
def producer(input): while True:
line = input.readline() # блокирование не страшно: дочерний поток
stdoutQueue.put(line) # пустая строка - конец файла
if not line: break
def consumer(output, root, term=’’): try:
line = stdoutQueue.get(block=False) # главный поток: проверять очередь except queue.Empty: # 4 раза в сек, это нормально,
pass # если очередь пуста
else:
if not line: # остановить цикл по достижении конца файла
output.write(term) # иначе отобразить следующую строку return
output.write(line)
root.after(250, lambda: consumer(output, root, term))
def redirectedGuiShellCmd(command, root):
input = os.popen(command, ‘r’) # запустить программу командной строки output = GuiOutput(root)
thread.start_new_thread(producer, (input,)) # запустить поток чтения consumer(output, root)
if __name__ == ‘__main__’: win = Tk()
redirectedGuiShellCmd(‘python -u pipe-nongui.py’, win) win.mainloop()
Здесь мы используем очередь, чтобы избежать необходимости обновления графического интерфейса в дочерних потоках. Обратите внимание, что в предыдущем разделе, в примере с сокетами, очереди и потоки выполнения не требовались лишь потому, что у нас была возможность проверить сокет на наличие данных без блокирования - цикла обработки событий от таймера after было вполне достаточно. Однако при организации обмена данными через канал потоки выполнения являются самым простым способом избежать блокирования графического интерфейса.
Если запустить этот сценарий, программный код самотестирования создаст окно с виджетом ScrolledText, в котором будут отображаться текущие дата и время, отправляемые сценарием pipes-nongui.py из примера 10.27. Фактически это окно идентично тем, что создают предыдущие версии (рис. 10.15). Каждые две секунды в окне будет появляться новая строка, потому что именно с такой частотой сценарий pipes-nongui выводит сообщения в stdout.
Обратите внимание, что поток-производитель загружает данные по одной строке с помощью метода readline(). Мы не можем использовать функции чтения, которые пытаются загрузить все данные из потока ввода целиком (такие как read(), readlines()), потому что они не возвращают управление, пока программа не завершится и не отправит признак конца файла. Для чтения фрагмента данных можно было бы использовать метод read(N), но в этом случае мы исходим из предположения, что в поток вывода передаются текстовые данные. Обратите также внимание, что здесь снова используется ключ -u, запрещающий буферизацию потоков ввода-вывода, чтобы обеспечить получение данных по мере их вывода. Без этого выводимые данные вообще не попали бы в графический интерфейс, потому что сохранялись бы в выходном буфере дочерней программы (попробуйте сами).
Сокеты и каналы: сходства и различия
Давайте посмотрим, что у нас получилось. Этот сценарий по своему духу напоминает сценарий в примере 10.28. Тем не менее, благодаря реструктуризации программного кода, сценарий в примере 10.29 имеет значительное преимущество: так как на этот раз операция чтения данных выполняется в дочернем потоке, графический интерфейс остается отзывчивым. Операции перемещения окна, изменения его размеров и так далее, выполняются немедленно, потому что графический интерфейс не блокируется в ожидании вывода очередной порции данных программой командной строки. Комбинация канала, потока выполнения и очереди в этом примере творит чудеса - графическому интерфейсу не приходится ждать дочернюю программу, а дочернему потоку не требуется обновлять графический интерфейс.
Несмотря на сложность реализации и необходимость использовать многопоточную модель выполнения, отсутствие блокировок в примере 10.29 делают его функцию redirectedGuiShellCmd намного более полезной, чем в оригинальной версии. Тем не менее, в сравнении с реализацией на основе сокетов из предыдущего раздела, данное решение выглядит как смесь разных приемов:
• Поскольку эта реализация графического интерфейса читает данные из стандартного потока вывода дочерней программы, отпадает необходимость вносить в нее какие-либо изменения. В отличие от примера из предыдущего раздела, основанного на применении сокетов, программе командной строки не требуется знать о существовании графического интерфейса, отображающего ее результаты, - ей не требуется выполнять подключение к сокету и выталкивать свои выходные буферы, как в предыдущем решении с сокетами.
• Несмотря на отсутствие необходимости вносить изменения в программу, вывод которой отображается, сложность реализации графического интерфейса начинает приближаться к сложности реализации варианта на основе сокетов, особенно если отбросить шаблонный программный код, необходимый в любой программе, использующей сокеты.
• Данное решение не поддерживает возможность выполнения графического интерфейса и программы командной строки независимо друг от друга или на разных компьютерах. Как мы увидим в главе 12, сокеты позволяют передавать данные между программами, работающими на одном и том же компьютере, или по сети.
• Сокеты могут применяться не только для отображения стандартного потока вывода программы. Если от графического интерфейса требуется нечто большее, чем отображение вывода другой программы, сокеты могут обеспечить более универсальное решение. Кроме того, как мы увидим далее, сокеты по своей природе являются двунаправленными потоками данных, поэтому они позволяют передавать данные между программами в обоих направлениях более произвольными способами.
Другие примеры использования многопоточных графических интерфейсов и каналов
Несмотря на некоторые незначительные недостатки, реализация графических интерфейсов на основе потоков/очередей/каналов имеет весьма широкую область применения. Для иллюстрации приведем еще один короткий пример использования. Ниже демонстрируется запуск простого сценария в окне консоли, который каждые две секунды выводит все более и более длинную строку:
C:\...\PP4E\Gui\Tools> type spams.py import time
for i in range(1, 10, 2):
time.sleep(2) # выводит текст в стандартный поток вывода
print(‘spam’ * i) # GUI ничего не знает об этом, ведь так?
C:\...\PP4E\Gui\Tools> python spams.py
spam
spamspamspam
spamspamspamspamspam
spamspamspamspamspamspamspam
spamspamspamspamspamspamspamspamspam
Попробуем завернуть этот сценарий в графический интерфейс, введя программный код в интерактивной оболочке, для разнообразия. Следующий фрагмент импортирует новую версию функции перенаправления потока вывода в графический интерфейс как библиотечный компонент и с ее помощью создает окно, в котором отображаются пять строк, выводимые сценарием каждые две секунды - так же, как в окне консоли, - за которыми следует строка , отражающая момент завершения дочерней программы. Получившееся окно изображено на рис. 10.16:
C:\...\PP4E\Gui\Tools> python
>>> from tkinter import Tk
>>> from pipe_gui3 import redirectedGuiShellCmd
>>> root = Tk()
>>> redirectedGuiShellCmd('python -u spams.py', root)
Рис. 10.16. Графический интерфейс, отображающий полученный по каналу вывод другой программы
Когда дочерняя программа завершится, поток-производитель в примере 10.29 определит признак конца файла и поместит в очередь заключительную пустую строку. В ответ на это цикл обработки событий от таймера выведет строку в окно. В данном случае программа завершается обычным образом без вывода каких-либо сообщений, но в других ситуациях нам может потребоваться добавить логику завершения, чтобы подавить вывод сообщений об ошибках. Обратите внимание, что здесь, как и прежде, дочерняя программа имитирует выполнение продолжительных операций с помощью функции sleep, а кроме того, нам необходимо использовать ключ -u, чтобы запретить буферизацию стандартного потока вывода, - без этого в течение восьми секунд в графическом интерфейсе ничего отображаться не будет, пока дочерняя программа не завершит работу. При наличии ключа графический интерфейс будет получать и отображать строки по мере их вывода, каждые две секунды.
Наконец, такой программный код, не использующий сокеты, не требующий вносить изменения в оригинальную программу и не блокирующий графический интерфейс, можно было бы использовать для отображения вывода программ командной строки в графическом интерфейсе. Конечно, во многих случаях может оказаться слишком сложным добавлять графический интерфейс таким способом, и для вас может оказаться проще превратить свой сценарий в традиционную программу с графическим интерфейсом, у которой есть главное окно и цикл событий. Кроме того, графические интерфейсы, которые мы реализовали в этом разделе, мы обязали просто отображать вывод другой программы, тогда как на практике от графического интерфейса может требоваться нечто большее. Однако для многих программ отделение представления от реализации, которое обеспечивает модель графического интерфейса, порождающего дочернюю программу командной строки, имеет свои преимущества - обе части приложения понять будет намного проще, если они не будут смешиваться.
Сокеты мы будем подробно рассматривать в следующей части книги, поэтому данное обсуждение следует рассматривать, как предварительное знакомство. Как мы увидим далее, все станет еще более интересным, как только мы начнем комбинировать графические интерфейсы, потоки выполнения и сокеты.
В следующей главе мы закончим обсуждение тем, касающихся исключительно графического интерфейса, где рассмотрим применение уже знакомых нам виджетов и приемов для реализации более практичных программ. Но перед этим в следующем разделе мы познакомимся с некоторыми крупными примерами графических интерфейсов, рассмотрев сценарии, которые запускают их автоматически и могут служить образцами, демонстрирующими возможности языка Python и библиотеки tkinter.
Запускающие программы PyDemos и PyGadgets
В завершение главы исследуем реализацию двух графических интерфейсов, с помощью которых запускаются основные примеры для этой книги. Следующие два графических интерфейса, PyDemos и PyGadgets, служат для запуска других программ с графическим интерфейсом. На самом деле мы подошли к концу истории о программах, запускающих демонстрационные примеры, - обе программы, представленные здесь, взаимодействуют с модулями, с которыми мы встречались ранее, во второй части книги:
launchmodes.py
Запускает независимые программы Python переносимым образом. Launcher.py
Отыскивает программы и в конечном итоге запускает обе программы, PyDemos и PyGadgets, при использовании самонастраивающихся сценариев верхнего уровня.
LaunchBrowser.py
Запускает веб-броузеры переносимым способом, открывая в них локальные или удаленные страницы.
Реализацию этих модулей вы найдете во второй части книги (особенно в главах 5 и 6). Представленные здесь программы добавляют компоненты графического интерфейса в систему запуска программ - они создают простые в использовании кнопки, нажатием которых можно запустить большинство крупных примеров, содержащихся в книге.
Кроме того, оба эти сценария предполагают, что при запуске текущим рабочим каталогом будет каталог, где они находятся (в них жестко определены пути к другим программам относительно этого каталога). Щелкните на их именах в проводнике по файловой системе или запустите из командной строки, выполнив команду cd для перехода в корневой каталог примеров PP4E. В этих сценариях можно было бы реализовать поддержку запуска и из других каталогов, путем использования значений переменных окружения для получения путей к сценариям, но в действительности они предназначены только для запуска из корневого каталога PP4E.
Поскольку эти сценарии запуска демонстрационных примеров являются достаточно длинными программами, в интересах экономии места на страницах книги будут приводиться только наиболее интересные их фрагменты. Полный программный код вы найдете в пакете с примерами.
Панель запуска PyDemos
Сценарий PyDemos создает панель с кнопками, которые запускают программы в демонстрационном режиме - не для повседневного применения. Я использую PyDemos, когда мне необходимо показать программы Python, - гораздо проще нажимать на кнопки, чем набирать командные строки или искать сценарии с помощью проводника по файловой системе.
Вы можете использовать PyDemos (и PyGadgets) для запуска и опробования примеров, представленных в этой книге, - все кнопки в этом графическом интерфейсе представляют примеры, с которыми мы познакомимся в последующих главах. Однако если вы соберетесь использовать сценарии Launch_PyDemos и Launch_PyGadgets_bar, находящиеся в корневом каталоге с примерами, не забудьте включить в переменную окружения PYTHONPATH путь к каталогу PP4E - они не предусматривают автоматическую настройку вашей системы или путей поиска модулей.
Чтобы пользоваться этой панелью запуска было еще легче, перетащите ее на рабочий стол Windows, создав ярлык, на котором можно щелкнуть мышью (нечто подобное можно проделать и на других системах). Так как в этом сценарии жестко определены команды для запуска программ, находящихся в других подкаталогах в дереве примеров, он также полезен как предметный указатель к главным примерам из книги. На рис. 10.17 показано, как выглядит интерфейс сценария PyDemos при выполнении в Windows, наряду с несколькими демонстрационными программами, которые он запускает; PyDemos - это вертикальная панель с кнопками. В Linux он выглядит несколько иначе, но действует так же.
Рис. 10.17. PyDemos c несколькими демонстрационными программами
Исходный программный код, с помощью которого создается такая картина, приводится в примере 10.30 (его начало может несколько отличаться от того, что изображено на рис. 10.17, из-за мелких изменений, которые разработчики так любят вносить в последний момент). Сценарий PyDemos не содержит ничего особенного с точки зрения программирования графических интерфейсов, поэтому большая его часть не вошла в листинг - полную реализацию вы найдете в пакете с примерами.
В двух словах, функция demoButton в нем просто прикрепляет к главному окну новую кнопку, готовую при нажатии запустить программу на языке Python. Для запуска программ сценарий PyDemos вызывает экземпляр объекта launchmodes.PortableLauncher, с которым мы познакомились в конце главы 5, - поскольку здесь он выступает в роли обработчика tkinter, для запуска программы используется операция вызова функции.
Как показано на рис. 10.17, сценарий PyDemos создает также два всплывающих окна, когда нажимаются кнопки в нижней части главного окна, - окно Info содержит краткое описание последней запущенной демонстрационной программы, а окно Links содержит переключатели, нажатие которых открывает связанные с книгой сайты в локальном веб-броузере:
• Всплывающее окно Info отображает простую строку сообщения и раз в секунду изменяет ее шрифт, чтобы привлечь к себе внимание. Поскольку это может раздражать, всплывающее окно сначала появляется в свернутом виде (щелкните на кнопке Info, чтобы увидеть его или спрятать).
• Переключатели всплывающего окна Links своим поведением напоминают гиперссылки на веб-странице, но этот графический интерфейс на является броузером: при щелчке на них, с помощью сценария LaunchBrowser, упоминавшегося во второй части книги, отыскивается и запускается веб-броузер, подключающийся к соответствующему сайту при наличии соединения с Интернетом. Этот модуль в свою очередь использует современный модуль webbrowser из стандартной библиотеки Python.
• Чтобы ко всем окнам этого сценария привязать ярлык с синими буквами «PY» вместо стандартных красных букв «Tk», используется модуль windows, написанный нами ранее в этой главе.
В графическом интерфейсе сценария PyDemos также присутствуют кнопки code, расположенные правее кнопок с именами демонстрационных программ. Щелчок на этих кнопках открывает файлы с исходными текстами соответствующих примеров. Файлы открываются в текстовом редакторе PyEdit, с которым мы встретимся в главе 11. На рис. 10.18 изображены некоторые из окон с исходными текстами с несколько измененными размерами.
Для примеров, демонстрирующих работу с Интернетом, которые запускаются последними двумя кнопками на панели, выполняется попытка запустить локальный веб-сервер, обеспечивающий работу демонстрационных программ, не показанных здесь (мы встретимся с сервером в главе 15). В этом издании веб-серверы запускаются, только когда впервые выполняется щелчок на кнопке того или иного примера, демонстрирующего работу с Интернетом (а не при запуске PyDemos). При запуске веб-сервера в Windows открывается окно консоли, в которое выводятся сообщения о состоянии сервера.
PyDemos работает в Windows, Mac и в Linux в основном благодаря присущей переносимости Python и tkinter. Дополнительные подробности можно найти в исходных текстах, частично представленных в примере 10.30.
Рис. 10.18. Сценарий PyDemos с окнами «code» для отображения исходных текстов
Пример 10.30. PP4E\PyDemos.pyw (external)
##############################################################################
PyDemos.pyw
Программирование на Python, 2, 3 и 4 издания (PP4E), 2001--2006--2010
Версия 2.1 (4E), апрель, 2010: добавлена возможность выполнения под управлением Python 3.X и запуск локальных веб-серверов при первой попытке запустить пример, демонстрирующий работу с Интернетом.
Версия 2.0 (3E), март, 2006: добавлены кнопки просмотра исходных текстов примеров; добавлены новые демонстрационные программы (PyPhoto, PyMailGUI); предусмотрен запуск локальных веб-серверов для демонстрационных примеров, использующих веб-броузер; добавлены ярлыки окон; и, наверное, еще что-то, о чем я забыл.
Запускает основные примеры графических интерфейсов Python+Tk из книги независимым от платформы способом. Этот файл может также служить предметным указателем к основным примерам программ, хотя многие примеры в книге не имеют графического интерфейса и потому здесь не перечислены. Смотрите также:
- PyGadgets.py, более простой сценарий запуска программ в недемонстрационном режиме, который можно использовать для повседневной работы
- PyGadgets_bar.pyw, создает панель с кнопками для запуска всех программ PyGadgets по отдельности, а не всех сразу
- Launcher.py позволяет запускать программы без настройки окружения -отыскивает Python, устанавливает PYTHONPATH и так далее.
- Launch_*.pyw, запускает PyDemos и PyGadgets с помощью Launcher.py -попробуйте запустить их для беглого знакомства
- LaunchBrowser.pyw, открывает веб-страницы примеров в веб-броузере, обнаруживаемом автоматически
- README-PP4E.txt, общая информация о примерах
ВНИМАНИЕ: эта программа пытается автоматически запускать локальный веб-сервер и веб-броузер для демонстрационных примеров работы с Интернетом, но не завершает работу сервера.
##############################################################################
...часть программного кода опущена: смотрите файлы в дереве примеров...
##############################################################################
# начало создания главных окон графического интерфейса ##############################################################################
from PP4E.Gui.Tools.windows import MainWindow # Tk с ярлыком, заголовком,
# кнопкой закрытия
from PP4E.Gui.Tools.windows import PopupWindow # То же, но Toplevel,
# отличается действием
# кнопки закрытия
Root = MainWindow(‘PP4E Demos 2.1’)
# создать окно сообщений
Stat = PopupWindow(‘PP4E demo info’)
Stat.protocol(‘WM_DELETE_WINDOW’, lambda:0) # игнорировать событие
Info = Label(Stat, text = ‘Select demo’,
font=(‘courier’, 20, ‘italic’), padx=12, pady=12, bg=’lightblue’) Info.pack(expand=YES, fill=BOTH)
##############################################################################
# добавить кнопки запуска с объектами обработчиков ##############################################################################
from PP4E.Gui.TextEditor.textEditor import TextEditorMainPopup
# класс механизма запуска демонстрационных программ
class Launcher(launchmodes.PortableLauncher): # использовать имеющийся класс
def announce(self, text): # настроить метку в интерфейсе
Info.config(text=text)
def viewer(sources):
for filename in sources:
TextEditorMainPopup(Root, filename, # как всплывающее окно
loadEncode=’utf-8’) # иначе PyEdit может выводить # запросы для каждого!
def demoButton(name, what, doit, code):
добавляет кнопки, которые выполняют команды doit и открывают все
файлы в списке code; кнопка doit сохраняет информацию в объекте, а кнопка
code - в объемлющей области видимости;
rowfrm = Frame(Root)
rowfrm.pack(side=TOP, expand=YES, fill=BOTH)
b = Button(rowfrm, bg=’navy’, fg=’white’, relief=RIDGE, border=4) b.config(text=name, width=20, command=Launcher(what, doit)) b.pack(side=LEFT, expand=YES, fill=BOTH)
b = Button(rowfrm, bg=’beige’, fg=’navy’) b.config(text=’code’, command=(lambda: viewer(code))) b.pack(side=LEFT, fill=BOTH)
##############################################################################
# демонстрационные программы с графическим интерфейсом tkinter - некоторые
# используют сетевые соединения
##############################################################################
demoButton(name=’PyEdit’,
what=’Text file editor’, # редактировать
doit=’Gui/TextEditor/textEditor.py PyDemos.pyw’, # предполагается code=[‘launchmodes.py’, # в тек. раб. кат.
‘Tools/find.py’,
‘Gui/Tour/scrolledlist.py’, # вывести в PyEdit ‘Gui/ShellGui/formrows.py’, # последний = верхний в стопке ‘Gui/Tools/guimaker.py’,
‘Gui/TextEditor/textConfig.py’,
‘Gui/TextEditor/textEditor.py’])
demoButton(name=’PyView’,
what=’Image slideshow, plus note editor’, doit=’Gui/SlideShow/slideShowPlus.py Gui/gifs’, code=[‘Gui/Texteditor/textEditor.py’,
‘Gui/SlideShow/slideShow.py’,
‘Gui/SlideShow/slideShowPlus.py’])
...часть программного кода опущена: смотрите файлы в дереве примеров...
##############################################################################
# переключение шрифта в окне Info раз в секунду ##############################################################################
def refreshMe(info, ncall):
slant = [‘normal’, ‘italic’, ‘bold’, ‘bold italic’][ncall % 4] info.config(font=(‘courier’, 20, slant))
Root.after(1000, (lambda: refreshMe(info, ncall+1)) )
##############################################################################
# показать/спрятать окно Info в случае щелчка на кнопке Info ##############################################################################
Stat.iconify() def onInfo():
if Stat.state() == ‘iconic’:
Stat.deiconify()
else:
Stat.iconify() # было ‘normal’
##############################################################################
# конец создания графического интерфейса, запуск цикла события ##############################################################################
def onLinks():
...часть программного кода опущена: смотрите файлы в дереве примеров...
Button(Root, text=’Info’, command=onInfo).pack(side=TOP, fill=X)
Button(Root, text=’Links’, command=onLinks).pack(side=TOP, fill=X)
Button(Root, text=’Quit’, command=Root.quit).pack(side=BOTTOM, fill=X) refreshMe(Info, 0) # запустить переключение шрифтов в окне Info Root.mainloop()
Панель запуска PyGadgets
Сценарий PyGadgets запускает часть тех же программ, что и PyDemos, но для практического использования, а не как кратковременные демонстрации. Оба сценария отображают панель с кнопками и запускают программы с помощью модуля launchmodes, но сценарий PyGadgets немного проще, потому что его задача более узкая. Кроме того, сценарий PyGadgets поддерживает два режима запуска - он может сразу запустить одновременно все программы из списка или вывести графический интерфейс для запуска каждой программы отдельно. На рис. 10.19 изображен графический интерфейс в виде панели с кнопками для запуска программ по отдельности. Сценарии PyGadgets и PyDemos могут выполняться одновременно, и оба позволяют изменять размеры окна (попробуйте сами, чтобы увидеть, как это делается).
Рис. 10.19. Панель запуска PyGadgets
Из-за этих различий построение графического интерфейса в сценарии PyGadgets в большей мере основывается на данных: он сохраняет имена программ в списке и просматривает его при необходимости, а не проходит по последовательности заранее запрограммированных вызовов функции demoButton. Например, набор кнопок в панели запуска на рис. 10.19 целиком зависит от содержимого списка программ.
Программный код этого графического интерфейса приводится в примере 10.31. Его объем невелик, потому что опирается на использование других модулей, которые мы написали ранее, и осуществляющих большую часть его действий: launchmodes - для запуска программ, LaunchBrowser - для запуска веб-броузера, windows - для переопределения ярлыков и реализации операции завершения. На рабочем столе моего компьютера я создал ярлык для PyGadgets, и его окно практически всегда открыто у меня. С его помощью я легко получаю доступ к повседневно используемым инструментам - текстовым редакторам, калькуляторам, электронной почте, средствам обработки изображений и так далее, которые все встретятся нам в будущих главах.
Для настройки PyGadgets под собственные нужды просто импортируйте и вызывайте его функции через свои списки команд, запускающих программы, или измените список mytools вызываемых программ, который находится ближе к концу файла. В конце концов, это Python.
Пример 10.31. PP4E\PyGadgets.py
##############################################################################
Запускает различные примеры; запускайте сценарий при загрузке системы, чтобы сделать их постоянно доступными.
Этот файл предназначен для запуска программ, действительно необходимых в работе; для запуска демонстрационных программ Python/Tk и получения дополнительных сведений о параметрах запуска программ обращайтесь к сценарию PyDemos. Замечание о работе в Windows: это файл с расширением ‘.py’, поэтому при его запуске щелчком мыши выводится окно консоли, которое используется для вывода начального сообщения (включая 10-секундную паузу, чтобы обеспечить его видимость, пока запускаются приложения). Чтобы избежать вывода окна консоли, запускайте сценарий с помощью программы ‘pythonw’ (а не ‘python’), используйте расширение ‘.pyw’, в свойствах ярлыка в Windows выберите значение ‘Свернутое в значок’ (‘run minimized’) в поле ‘Окно’ (‘Window’) или запускайте файл из другой программы (см. PyDemos). ##############################################################################
import sys, time, os, time from tkinter import *
from launchmodes import PortableLauncher # повторное использ. класса запуска from Gui.Tools.windows import MainWindow # повторное использ. оконных
# инструментов: ярлык, обработчик
# закрытия окна
def runImmediate(mytools):
немедленный запуск программ
print(‘Starting Python/Tk gadgets...’) # вывод в stdout (временный)
for (name, commandLine) in mytools:
PortableLauncher(name, commandLine)() # сразу вызвать для запуска print(‘One moment please...’)
if sys.platform[:3] == ‘win’: # windows: закрыть консоль через
for i in range(10): # 10 секунд
time.sleep(1); print(‘.’ * 5 * (i+1))
def runLauncher(mytools):
создать простую панель запуска для использования в дальнейшем
root = MainWindow(‘PyGadgets PP4E’) # или root = Tk()
for (name, commandLine) in mytools:
b = Button(root, text=name, fg=’black’, bg=’beige’, border=2, command=PortableLauncher(name, commandLine)) b.pack(side=LEFT, expand=YES, fill=BOTH) root.mainloop()
mytools = [
(‘PyEdit’, ‘Gui/TextEditor/textEditor.py’),
(‘PyCalc’, ‘Lang/Calculator/calculator.py’),
(‘PyPhoto’, ‘Gui/PIL/pyphoto1.py Gui/PIL/images’),
(‘PyMail’, ‘Internet/Email/PyMailGui/PyMailGui.py’),
(‘PyClock’, ‘Gui/Clock/clock.py -size 175 -bg white’
‘ -picture Gui/gifs/pythonPowered.gif’),
(‘PyToe’, ‘Ai/TicTacToe/tictactoe.py’
‘ -mode Minimax -fg white -bg navy’),
(‘PyWeb’, ‘LaunchBrowser.pyw’
‘ -live index.html learning-python.com’)]
#’ -live PyInternetDemos.html localhost:80’)]
#’ -file’)] # PyInternetDemos предполагает, что # локальный веб-сервер уже запущен
if__name__== ‘__main__’:
prestart, toolbar = True, False if prestart:
runImmediate(mytools)
if toolbar:
runLauncher(mytools)
По умолчанию сценарий PyGadgets сразу запускает все программы из списка. Чтобы запустить PyGadgets в режиме панели, в примере 10.32 импортируется и вызывается соответствующая функция с импортированным списком программ. Так как этот файл имеет расширение .pyw, на экране появится только графический интерфейс панели запуска -окно консоли открываться не будет. Это отлично подходит для повседневного использования, но не годится для случаев, когда желательно просматривать сообщения об ошибках (используйте расширение .py).
Пример 10.32. PP4E\PyGadgets_bar.pyw
запускает только панель инструментов PyGadgets - ни одна другая программа при этом не запускается; расширение файла предотвращает появление окна консоли в Windows: используйте расширение ‘.py’, чтобы видеть сообщения, выводимые в консоль;
import PyGadgets
PyGadgets.runLauncher(PyGadgets.mytools)
Этот сценарий - тот самый файл, на который ссылается ярлык на моем рабочем столе: я предпочитаю запускать приложения по мере необходимости. Создать ярлык и тем самым упростить возможность запуска можно на многих платформах. Такой сценарий можно выполнять и при загрузке системы, чтобы сделать его постоянно доступным (и сэкономить на щелчке мышью). Например, в Windows такой сценарий автоматически запускается при добавлении его в папку Автозагрузка (Statrup), а в Unix и в Unix-подобных системах можно автоматически запускать этот сценарий из командной строки в сценариях запуска, после запуска XWindow.
Каким бы способом ни был запущен сценарий PyGadgets - щелчком на ярлыке или на имени файла в проводнике по файловой системе, с помощью командной строки или иным образом, - появляется панель запуска, показанная в центре рис. 10.20.
Конечно, основное назначение сценария PyGadgets состоит в том, чтобы запускать другие программы. При нажатии на кнопки запускаются программы, показанные на рис. 10.20, и если вы хотите узнать о них больше, переверните страницу и перейдите к следующей главе.
Рис. 10.20. Панель запуска PyGadgets с несколькими запущенными приложениями
Примеры законченных программ с графическим интерфейсом
«Python, открытое программное обеспечение и Camaro 48 »
Эта глава завершает тему создания графических интерфейсов с помощью языка Python и его стандартной библиотеки tkinter, представляя ряд практических программ с графическим интерфейсом. В четырех предшествующих главах мы освоили основы программирования с использованием библиотеки tkinter. Познакомились с базовым набором виджетов - классов Python, которые генерируют графические элементы управления на экране компьютера и могут реагировать на события, вызываемые пользователем. Кроме того, мы также изучили множество дополнительных приемов программирования графических интерфейсов, включая анимацию, перенаправление потоков ввода-вывода с применением сокетов и каналов и поддержку многопоточной модели выполнения. В данной главе мы сконцентрируемся на объединении этих виджетов и приемов для создания более полезных графических интерфейсов. Нами будут изучены:
PyEdit
Программа текстового редактора PyPhoto
Программа просмотра миниатюр графических изображений
PyView
Программа просмотра графических изображений в режиме слайд-шоу
PyDraw
Графический редактор PyClock
Графические часы PyToe
Простая игра «крестики-нолики» в качестве развлечения49
Как и в главе 6, я выбрал примеры для этой главы из собственной библиотеки программ на языке Python, которыми я действительно пользуюсь. Например, текстовый редактор и часы, с которыми мы здесь познакомимся, служат рабочими лошадками, изо дня в день используемыми мной на моих машинах. Так как они написаны на Python и tkinter, то без изменений работают в Windows и Linux и должны работать так же в Mac OS.
Так как эти сценарии написаны исключительно на языке Python, их дальнейшее развитие целиком зависит от пользователей - освоившись с интерфейсами tkinter, не составит труда изменить или улучшить поведение таких программ редактированием их программного кода. Некоторые из этих примеров аналогичны коммерческим программам (например, PyEdit напоминает Блокнот в Windows), однако переносимость сценариев Python и почти полное отсутствие препятствий к их дальнейшему улучшению дают им явное преимущество.
Примеры в других главах
Далее в этой книге мы встретим другие программы с графическим интерфейсом на базе tkinter, представляющие удобные инструменты для конкретных прикладных областей. В частности, в последующих главах появятся такие крупные примеры, как:
PyMailGUI
Клиент электронной почты (глава 14)
PyForm
(Внешний пример) Средство просмотра таблиц хранимых объектов (глава 17)
PyTree
(Внешний пример) Средство просмотра древовидных структур данных (главы 18 и 19)
PyCalc
Настраиваемый виджет калькулятора (глава 19)
Менее крупные примеры, включая клиента FTP и инструменты передачи файлов, будут также представлены в части главы, посвященной созданию сценариев для Интернета. Большей частью этих программ я постоянно пользуюсь. Так как библиотеки разработки графического интерфейса являются инструментами общего назначения, найдется совсем немного областей, которые не выиграли бы от простого в использовании, простого в программировании и хорошо переносимого интерфейса, реализованного на языке Python с применением tkinter.
Помимо примеров, представленных в этой книге, для Python существует множество высокоуровневых инструментальных средств создания графических интерфейсов, таких как Pmw, Tix и ttk, упомянутые в главе 7. Некоторые из этих систем опираются на библиотеку tkinter и предоставляют составные компоненты, такие как виджеты с закладками, деревья и всплывающие подсказки.
В следующей части книги мы также исследуем программы, которые строят интерфейсы пользователя в веб-броузерах, без использования tkinter, - совершенно иной подход к созданию пользовательских интерфейсов. Несмотря на то, что исторически веб-интерфейсы имеют более ограниченные возможности и в их работе часто наблюдаются задержки, связанные с передачей данных по сети, тем не менее при объединении с инструментами разработки полнофункциональных интернетприложений (Rich Internet Application, RIA), упоминавшихся в начале главы 7, современные веб-интерфейсы по своим возможностям приближаются к традиционным графическим интерфейсам, хотя и за счет существенной сложности программного обеспечения.
Тем не менее для создания высокоинтерактивных и нетривиальных интерфейсов автономные, настольные графические интерфейсы, предлагаемые библиотекой tkinter, окажутся незаменимым инструментом практически для всех приложений на языке Python. Программы, демонстрируемые в этой главе, позволяют увидеть, каких высот можно достичь с помощью Python и tkinter.
Стратегия данной главы
Как и все главы этой книги, посвященные исследованию конкретных случаев, данная глава в значительной мере является «обучением на примере» - текст большинства программ приведен с минимумом подробностей. По ходу дела я буду отмечать важные точки и новые возможности tkinter, представляемые каждым примером, но помимо этого я полагаюсь на то, что вы самостоятельно изучите детали по приведенным листингам и комментариям. Легкость чтения Python становится существенным достоинством для программистов (и авторов книг), особенно когда сложность программ достигает такого уровня, как в этой главе.
Исходные тексты всех примеров графических интерфейсов, упоминаемых в этой книге, доступны в пакете с примерами, как описывалось в предисловии. Поскольку ранее я уже описывал функции и методы, используемые этими сценариями, в этом разделе будут приводиться в основном снимки с экрана и листинги программ, сопровождаемые кратким описанием некоторых из наиболее важных аспектов этих программ. Иными словами, этот раздел предназначен для самостоятельного изучения: читайте исходные тексты, запускайте примеры на своем компьютере и обращайтесь к предыдущим главам за дополнительными подробностями. Некоторые из этих программ могут также сопровождать альтернативные или экспериментальные реализации в пакете с примерами, не перечисленные здесь, - ищите дополнительные примеры в дереве каталогов с примерами.
Наконец, я хочу напомнить, что все перечисленные выше крупные программы можно запускать из панелей запуска PyDemos и PyGadgets, с которыми мы встретились в конце главы 10. Я попытаюсь передать их поведение на снимках экранов, которые будут приведены здесь, но графические интерфейсы по своей природе являются системами, управляемыми событиями, и чтобы опробовать характер их взаимодействия с пользователем, лучше реального запуска примера ничего не придумаешь. Поэтому панели запуска фактически являются дополнением к материалу данной главы. Они могут выполняться на большинстве платформ и обеспечивают легкость запуска (ищите подсказки в файле README-PP4E.txt). Запускайте их и сразу начинайте щелкать мышью, если еще не сделали этого.
Открытое программное обеспечение и Camaro
Некоторые из программ с графическим интерфейсом, представленные в этой главе и в оставшейся части книги, являются аналогами утилит, которые можно найти в наиболее распространенных операционных системах, таких как Windows. Например, мы рассмотрим калькуляторы, текстовые редакторы, средства просмотра графических изображений, часы, клиенты электронной почты и другие.
Но, в отличие от большинства утилит, эти программы являются переносимыми - благодаря тому, что они написаны на языке Python с применением библиотеки tkinter, эти программы способны работать на всех основных платформах (Windows, Unix/Linux и Mac). Но самое важное, пожалуй, - они могут настраиваться под личные предпочтения, благодаря доступности исходных текстов, - вы можете изменять их внешний вид или функциональные возможности, просто дописав или изменив программный код на языке Python.
Приведу аналогию, чтобы подчеркнуть важность возможности что-то настраивать и переделывать под себя. Среди нас еще есть люди, которые помнят времена, когда считалось нормальным, если владелец автомобиля сам ухаживал за ним и ремонтировал его. Я с нежностью вспоминаю, как в годы моей юности мы с друзьями увлеченно копались под капотом Chevrolet Camaro 1970, ремонтируя и отлаживая его двигатель. Приложив совсем немного усилий, мы смогли увеличить его скорость, приемистость и придать его работе звучание, услаждавшее наш слух. Кроме того, поломка какого-то из наших старых автомобилей не была для нас концом света. Всегда оставался шанс самостоятельно починить его.
Сейчас все изменилось. С появлением электронных средств управления и дьявольски тесных моторных отсеков владельцы автомобилей стали предпочитать пользоваться услугами специалистов в любых, даже в самых простых случаях. В целом, автомобили перестали быть продуктом, доступным для самостоятельного ремонта. И если в моем новеньком, сверкающем экипаже случится поломка, я наверняка застряну на дороге, пока подготовленный специалист не найдет время, чтобы отбуксировать его и отремонтировать.
Я люблю сравнивать закрытую и открытую модели разработки программного обеспечения, оперируя теми же понятиями. Когда я использую программы корпорации Microsoft, такие как Notepad и Outlook, я ограничен возможностями, предусмотренными компанией-производителем, а также вынужден мириться со всеми ошибками, которые могут скрываться в этих программах. А в случае с такими программными инструментами, как PyEdit и PyMailGUI, у меня сохраняется возможность «залезть под капот». Я могу добавлять новые особенности, настраивать систему и исправлять любые ошибки, какие будут обнаружены. И могу сделать это намного быстрее, чем Microsoft выпустит очередной набор исправлений или новую версию своего продукта. Я не завишу от компании, действующей в общем-то в своих интересах, если мне требуется поддержка или даже продолжение разработки инструментов, которыми я пользуюсь.
Конечно, я по-прежнему завишу от языка Python и от тех изменений, которые могут в него вноситься с течением времени (после обновления двух книг, по тысяче страниц с лишним в каждой, под Python 3.X, я с определенной уверенностью могу сказать, что эта зависимость не всегда является тривиальной). Однако наличие исходных текстов для всех программных инструментов, на которые вы полагаетесь, все равно можно считать мощной поддержкой и крупным преимуществом. А кроме того, открытая модель способствует повышению надежности, предоставляя возможность сообществам людей тестировать и развивать систему.
В конечном счете, открытое программное обеспечение и Python чаще всего ассоциируются со свободой, тогда как закрытое - с ценой. Последнее слово здесь остается за пользователями, а не за какой-то далекой компанией. Конечно, не каждый захочет возиться со своим автомобилем. Но, с другой стороны, программное обеспечение имеет свойство терпеть неудачу намного чаще, чем автомобили - ломаться, да и программирование на языке Python является менее грязной работой, чем работа автомеханика.
PyEdit: программа/объект текстового редактора
За последние десятилетия мне пришлось набирать текст во многих программах. Большинство из них были закрытыми системами (мне приходилось довольствоваться теми решениями, которые были воплощены их разработчиками), и многие работали только на одной платформе. Представленная в этом разделе программа PyEdit более удачна в обоих отношениях: она реализует полноценный текстовый редактор с графическим интерфейсом в 1133 строках переносимого программного кода на языке Python, включая пробельные символы и комментарии, из которых 1088 строк содержатся в главном файле и 45 строк - в модуле с настройками (к моменту выхода этого издания книги; в будущем его размер может измениться). Несмотря на свой относительно скромный размер, редактор PyEdit оказался достаточно мощным и надежным, чтобы послужить основным инструментом для разработки большинства примеров, приведенных в этой книге.
PyEdit поддерживает все обычные операции редактирования текста с помощью мыши и клавиатуры: удаление и вставка, поиск и замена, открытие и сохранение, отмена и возврат ввода и так далее. Но в действительности PyEdit представляет собой нечто большее, чем просто текстовый редактор, - его можно использовать как программу и как библиотечный компонент, и он может использоваться в разных режимах:
Автономный режим
В качестве автономной программы текстового редактора, с возможностью передачи имени редактируемого файла в командной строке. В этом режиме PyEdit напоминает другие утилиты редактирования текста (например, Notepad в Windows), но, кроме того, предоставляет дополнительные возможности, такие как запуск редактируемой программы на языке Python, изменение шрифта и цвета, поиск во внешних файлах, многооконный интерфейс и так далее. Но особенно важно, что текстовый редактор PyEdit легко можно модифицировать и использовать в Windows, X Window и Macintosh, потому что он написан на языке Python.
Всплывающий режим
Внутри нового всплывающего окна, позволяя программе одновременно выводить произвольное количество экземпляров. Поскольку информация о состоянии хранится в атрибутах экземпляра класса, каждый созданный объект PyEdit действует независимо от других. В этом и в следующем режимах PyEdit служит библиотечным объектом, используемым другими сценариями, а не готовым приложением. Например, приложение PyMailGUI, представленное в главе 14, использует PyEdit во всплывающем режиме для отображения вложений в электронные письма и простого текста, и оба приложения, PyMailGUI и PyDemos из предыдущей главы, отображают исходный программный код таким способом.
Встроенный режим
В качестве прикрепляемого компонента - виджета редактирования текста для других графических интерфейсов. Будучи прикрепленным, PyEdit использует меню, основанное на фрейме, и может отключать некоторые его пункты, не имеющие смысла во встроенном режиме. Например, программа PyView (рассматривается далее в этой главе) использует PyEdit во встроенном режиме в качестве редактора подписей к фотографиям, а PyMailGUI (в главе 14) прикрепляет его и бесплатно получает редактор текста электронных писем.
Может показаться, что такое поведение с разными режимами трудно реализовать, но на самом деле режимы PyEdit по большей части являются естественным побочным продуктом разработки графического интерфейса с использованием подхода, основанного на применении классов, рассматривавшегося на протяжении последних четырех глав.
Запуск PyEdit
Редактор PyEdit обладает массой возможностей, и лучший способ понять, как он действует, - поработать с ним самостоятельно. Его можно открыть, запустив главный файл textEditor.py или файлы textEditor-
NoConsole.pyw и pyedit.pyw, если желательно подавить появление окна консоли в Windows, или воспользовавшись панелями запуска демонстрационных программ PyDemos и PyGadgets, которые были описаны в конце главы 10 (сами запускающие программы находятся на верхнем уровне дерева каталогов примеров книги). Чтобы вы могли получить представление об интерфейсах PyEdit, на рис. 11.1 изображено главное окно программы - как оно выглядит по умолчанию в Windows 7 после открытия файла с исходными текстами PyEdit.
Рис. 11.1. Главное окно редактора PyEdit с программным кодом самого редактора
Главную часть этого окна составляет виджет Text, и если вы прочли его описание в главе 9, вам должны быть знакомы операции редактирования текста, выполняемые PyEdit. В нем используются метки, теги и индексы, и реализованы операции удаления и вставки через системный буфер обмена, который позволяет вставлять скопированные данные, даже после того как приложение-источник было закрыто. Для поддержки произвольного перемещения по содержимому файлов с виджетом Text взаимно связаны вертикальная и горизонтальная полосы прокрутки.
Меню и панели инструментов
Меню и панели инструментов редактора PyEdit должны показаться вам знакомыми - он строит главное окно, используя минимальный объем программного кода, и обеспечивает действие соответствующих правил обрезания и растягивания путем внедрения класса GuiMaker, с которым мы познакомились в предыдущей главе (пример 10.3). Панель инструментов внизу окна содержит кнопки для быстрого доступа к операциям, которыми я пользуюсь чаще всего; если ваши вкусы не совпадают с моими, просто измените список кнопок панели инструментов в исходном программном коде, чтобы в нем оказались кнопки, которые вам нужны (в конце концов, это Python).
Как обычно, в меню tkinter для быстрого вызова элементов меню можно использовать горячие клавиши - следует нажать ALt и все подчеркнутые клавиши на пути к нужному действию. Меню могут также отрываться по пунктирной линии и тем самым обеспечить быстрый доступ к пунктам меню в новом окне верхнего уровня (удобно, когда отсутствует панель инструментов с кнопками).
Диалоги
PyEdit выводит различные модальные и немодальные диалоги, стандартные и собственные. На рис. 11.2 изображены нестандартные, немодальные диалоги поиска с заменой, выбора шрифта и поиска во внешних файлах, а также стандартный диалог для вывода информации о файле (окончательные значения счетчиков в последних строках могут измениться, потому что я имею обыкновение изменять программный код и добавлять комментарии вплоть до окончания проекта).
Рис. 11.2. PyEdit с измененными цветами, шрифтом и некоторыми диалогами
В главном окне на рис. 11.2 установлены новые цвета переднего плана и фона (с помощью стандартного диалога выбора цвета) и новый шрифт, который можно установить либо с помощью диалога выбора шрифта, либо из имеющегося в сценарии готового списка, который пользователи могут изменять в соответствии со своими предпочтениями (в конце концов, это Python). Другие операции, выполняемые с помощью панели инструментов и меню, обычно используют стандартные диалоги с некоторыми дополнениями. Например, при работе со стандартными диалогами открытия и сохранения файлов в PyEdit используются интерфейсы на основе объектов, которые запоминают каталог, выбиравшийся последним, и устраняют необходимость каждый раз заново переходить к нему.
Запуск программного кода
Одной из уникальных особенностей PyEdit является возможность запуска редактируемого в нем программного кода на языке Python. Это не так сложно, как может показаться. В Python имеются встроенные функции компиляции и выполнения строк программного кода, а также запуска программ, поэтому редактору PyEdit остается лишь выполнить вызовы нужных функций. В частности, на языке Python легко можно написать простенький интерпретатор Python, как показано ниже (если вы захотите поэкспериментировать с ним, найдите файл simpleShell.py в каталоге с реализацией PyEdit), хотя осуществить обработку многострочных инструкций и отображение результатов выражений несколько сложнее.
# читает и выполняет строки с инструкциями на языке Python: подобно тому,
# как действует пункт ‘Run Code’ в меню PyEdit
namespace = {}
while True: try:
line = input(‘>>> ‘) # только однострочные инструкции
except EOFError: break else:
exec(line, namespace) # или eval() и вывод результата
В зависимости от предпочтений пользователя редактор PyEdit или делает что-то подобное этому, чтобы выполнять программный код, выбираемый из текстового виджета, или использует модуль launchmodes, который мы написали в конце главы 5, чтобы запустить файл с кодом как независимую программу. В обеих схемах могут быть использованы различные варианты, которые можно настроить по своему вкусу (в конце концов, это Python). Детали реализации смотрите в методе onRunCode или просто отредактируйте и выполните свой собственный программный код на языке Python. Когда выполняется только выбранная строка программного кода, вы сможете наблюдать результаты в окне консоли редактора PyEdit. Как уже говорилось в примечании о функциях eval и exec в главе 9, этим функциям следует передавать программный код только из проверенных источников - он получает доступ ко всему, что доступно процессу интерпретатора Python.
Несколько окон
Редактор PyEdit способен выводить не только множество окон специального назначения, он также позволяет одновременно открывать несколько окон редактирования - в пределах одного процесса или за счет запуска независимых экземпляров программы. Для иллюстрации на рис. 11.3 показаны три независимо выполняющиеся экземпляра PyEdit с различными размерами, цветовыми схемами и шрифтами. Поскольку все они были запущены как независимые программы, закрытие одной из них не оказывает влияния на другие. На этом рисунке внизу видны также оторванные меню PyEdit и всплывающее окно диалога справки справа. Фоном окон редактирования служат оттенки зеленого, красного и голубого цветов - для установки желаемого цвета выберите в меню Tools элемент Pick.
Рис. 11.3. Несколько окон PyEdit, открытых одновременно
Так как во всех этих трех сеансах PyEdit редактируется программный код на языке Python, их содержимое можно выполнить, выбрав пункт Run Code раскрывающегося меню Tools. Программный код из файлов выполняется независимо - стандартные потоки ввода-вывода программного кода, выполняемого не из файла (например, полученные из самого
текстового виджета), отображаются в окно консоли сеанса PyEdit. Это никоим образом нельзя рассматривать, как IDE (интегрированную среду разработки), - я добавил эту возможность только потому, что она показалась мне полезной. Очень удобно иметь возможность запускать редактируемый программный код, не разыскивая его в дереве каталогов.
Чтобы открыть несколько окон редактирования в пределах одного процесса, используйте пункт CLone в меню TooLs, при выборе которого открывается новое пустое окно без уничтожения содержимого в другом окне. На рис. 11.4 показана ситуация, когда в одном процессе открыты два окна, наряду со всплывающими окнами, имеющими отношение к пункту Grep меню Search, о котором рассказывается в следующем разделе, -который позволяет произвести обход дерева каталогов в параллельных потоках выполнения, отобрать файлы с именами, соответствующими шаблону и содержащими искомую строку, и открыть их. На рис. 11.4 видно, что выбор пункта Grep меню выводит диалог ввода, список файлов, удовлетворяющих критериям поиска и новое окно PyEdit, открытое и позиционированное после двойного щелчка на файле в списке.
Рис. 11.4. Множество окон PyEdit в рамках единственного процесса
В процессе выполнения операций, предусмотренных пунктом Grep меню, на экране появляется еще одно окно, но при этом графический интерфейс остается полностью активным. Фактически вы можете снова выбрать пункт Grep и выполнить еще один поиск, пока другой еще не закончился. Обратите внимание, что диалог Grep также позволяет указывать кодировку символов, которая будет использоваться для декодирования содержимого всех текстовых файлов, просматриваемых в процессе поиска. Подробнее о том, как это действует, я расскажу в следующем ниже разделе с описанием изменений, однако в большинстве случаев можно просто использовать системную кодировку по умолчанию.
Ради интереса попробуйте вызвать диалог Grep и выполнить в каталоге C:\Python31 поиск всех файлов *.py, содержащих строку %, чтобы получить представление о том, как часто используется это распространенное выражение форматирования строк в стандартной библиотеке Python 3.1. Разумеется, не все вхождения % будут иметь отношение к форматированию строк, но большинство из них - точно. Согласно сообщениям, выводимым в стандартный поток вывода перед завершением поиска, строка %’ (которая также соответствует целям для подстановки) встречается 6050 раз, а строка ‘ % ‘ (с пробелами вокруг знака процента, чтобы ограничить круг совпадений только оператором форматирования) встречается 3741 раз, включая 130 совпадений, обнаруженных в установленном расширении PIL, - не самый редко используемый инструмент языка! Ниже приводятся сообщения, которые были выведены в стандартный поток вывода в процессе поиска, - совпадения выводятся также в окно списка:
...ошибки могут отличаться от типа кодировки...
Unicode error in: C:\Python31\Lib\lib2to3\tests\data\different_encoding.py
Unicode error in: C:\Python31\Lib\test\test_doctest2.py
Unicode error in: C:\Python31\Lib\test\test_tokenize.py
Matches for % : 3741
Редактор PyEdit выводит дополнительные всплывающие окна - включая кратковременные диалоги Goto и Find, диалоги выбора цвета, диалоги ввода аргументов и выбора режимов для пункта Run Code меню, и диалоги, запрашивающие имена кодировок символов в файлах при выборе в меню пунктов Open и Save, если редактор настроен так, что он должен запрашивать эти данные (подробнее об этом рассказывается ниже). В интересах экономии места я оставляю исследование большинства других подобных черт поведения за вами.
Существенно обновленный в этом издании и поддерживающий настройки в соответствии с пользовательскими предпочтениями, редактор PyEdit может запрашивать имя кодировки символов при открытии файла, сохранять совершенно новый файл или выполнять операцию Save As. Например, на рис. 11.5 изображен момент, когда я открыл файл, содержащий символы китайского алфавита, и затем снова выбрал в меню пункт Open, чтобы открыть новый файл с текстом на русском языке. Диалог выбора имени кодировки, изображенный на рисунке, появляется сразу же после закрытия стандартного диалога выбора файла, а поле ввода в нем предварительно заполнено именем кодировки по умолчанию (которое определяется явно или берется из настроек платформы). В большинстве случаев можно использовать имя, предлагаемое по умолчанию, если только заранее не известно точно, что символы в файле представлены в другой кодировке.
Вообще говоря, редактор PyEdit поддерживает любые кодировки, которые поддерживаются языком Python и библиотекой tkinter. Текст, который можно видеть на рис. 11.5, например, содержал символы китайского алфавита в специфической кодировке (в кодировке «gb2321», в файле email-part--gb2312). В том же каталоге присутствует тот же текст в альтернативной кодировке UTF-8 (файл email-part--gb2312--utf8), который можно открывать в PyEdit и Notepad, используя кодировку по умолчанию, используемую в Windows. Но, чтобы открыть файл в специфической китайской кодировке и получить корректное отображение символов в PyEdit, требуется явно указать имя кодировки (содержимое этого файла абсолютно неправильно отображается в Notepad).
Рис. 11.5. PyEdit отображает китайский текст и запрашивает имя кодировки при открытии файла
После того как я ввел имя кодировки для выбранного файла в диалоге на рис. 11.5 («koi8-r» - для файла, выбранного в диалоге открытия), редактор PyEdit декодировал и отобразил его содержимое. На рис. 11.6 изображен момент, после того как файл был открыт и я выбрал в меню пункт Save As, - сразу после того как был закрыт диалог выбора файла, редактор вывел новый диалог ввода имени кодировки для нового файла, поле ввода в котором было предварительно заполнено именем кодировки, известным по последним операциям Open или Save. В соответствии с настройками операция Save повторно использует известную кодировку, но операция Save As всегда запрашивает кодировку, чтобы дать возможность указать ее явно для нового файла, прежде чем пытаться использовать умолчания. Подробнее об алгоритмах применения кодировок и интернационализации в PyEdit я буду рассказывать в следующем разделе, при обсуждении изменений в версии 2.1, а пока отмечу, что из-за того, что предпочтения пользователя не могут быть предугаданы, выбор среди алгоритмов поддерживается настройками.
Наконец, когда приходит время завершать работу, редактор PyEdit делает все возможное, чтобы не потерять несохраненные изменения. Когда в любом окне редактирования запрашивается выполнение операции завершения, PyEdit проверяет наличие несохраненных изменений и запрашивает подтверждение. Поскольку в одном и том же процессе может быть открыто несколько окон редактирования, когда операция завершения запрашивается в главном окне, PyEdit проверяет наличие изменений во всех остальных открытых окнах и запрашивает подтверждение, если хотя бы в одном из них будут обнаружены несохраненные изменения. В противном случае операция завершения будет выполнена без дополнительных вопросов. Попытка выполнить операцию завершения во всплывающем окне редактирования закроет только это окно, то есть никаких проверок между процессами выполняться не будет. При отсутствии изменений операция завершения просто закроет окна графического интерфейса и завершит программу. Другие операции проверяют наличие изменений похожим способом.
Рис. 11.6. PyEdit отображает текст на русском языке и запрашивает кодировку для операции Save As
Другие примеры и рисунки с изображением PyEdit в этой книге
Дополнительные рисунки с изображением PyEdit можно найти в описаниях следующих программ-клиентов:
• PyDemos в главе 10 использует PyEdit во всплывающем режиме для отображения файлов с исходными текстами.
• PyView далее в этой главе использует PyEdit во встроенном режиме для отображения примечаний к файлам изображений.
• PyMailGUI в главе 14 использует PyEdit для отображения сообщений электронной почты, текстовых вложений и исходных текстов.
Последнее приложение особенно интенсивно использует функциональные возможности PyEdit, а в главе с его описанием имеются рисунки, демонстрирующие возможности PyEdit по отображению текста Юникода с национальными наборами символов. При таком использовании текст либо извлекается из сообщений, либо загружается из временных файлов, кодировка которых определяется из заголовков сообщений электронной почты.
Изменения в версии PyEdit 2.0 (третье издание)
Я изменял этот пример в обоих, в третьем и четвертом, изданиях этой книги. Поскольку эта глава призвана отражать практические приемы программирования, а также потому, что этот пример демонстрирует процесс развития программного обеспечения с течением времени, этот и следующий разделы дают краткое описание основных изменений, выполненных за это время, чтобы помочь вам в изучении программного кода.
Поскольку текущая версия наследует все улучшения от предшествующих ей, начнем с дополнений, появившихся в предыдущей версии. В третьем издании редактор PyEdit был дополнен следующими возможностями:
• Простой диалог выбора шрифта
• Поддержка неограниченного количества отмен и возвратов операций редактирования
• Проверка наличия изменений в файле, когда его содержимое могло быть удалено или изменено
• Модуль для хранения настроек пользователя
Далее приводятся некоторые краткие примечания, касающиеся этих дополнений.
Диалог выбора шрифта
В третьем издании в редактор PyEdit был добавлен диалог выбора шрифта - простой немодальный диалог с тремя полями, куда можно ввести название семейства шрифта, размер и стиль, вместо того чтобы выбирать из предопределенного списка возможных вариантов. Хотя вы можете найти более сложные диалоги выбора шрифта на основе библиотеки tkinter, используемые в общедоступных приложениях и в реализации стандартной среды разработки IDLE на языке Python (как уже упоминалось ранее, среда IDLE сама по себе является программой, написанной на языке Python и использующей библиотеку tkinter).
Отмена, возврат и проверка наличия изменений
Еще одной новинкой в версии PyEdit для третьего издания стала поддержка неограниченного количества отмен и возвратов (undo/redo) операций редактирования, проверка наличия изменений перед завершением редактора, а также перед выполнением операций открытия, запуска и создания нового файла, чтобы при необходимости запросить сохранение этих изменений. Теперь запрос подтверждения на выход или перезапись файла выводится уже не каждый раз, а только если текст в окне редактора действительно изменился. Библиотека Tk версии 8.4 (или выше) предоставляет прикладной интерфейс, который упрощает реализацию обеих этих возможностей, - Tk сохраняет стеки отмены и возврата операций редактирования автоматически. Они включаются с помощью параметра undo настройки виджета Text и доступны с помощью методов edit_undo и edit_redo. Аналогично метод edit_reset очищает стеки (например, после открытия нового файла), а метод edit_modified проверяет или устанавливает признак наличия изменений в тексте.
Отмену вырезания и вставки текста из буфера обмена сразу после их выполнения реализовать совсем несложно (простой вставкой текста из буфера обмена или вырезанием вставленного и выделенного текста), но усовершенствованная поддержка операций отмены/возврата более полная и проще в использовании. Во втором издании книги реализация отмены была предложена в качестве самостоятельного упражнения, но она стала практически тривиальной благодаря новому прикладному интерфейсу библиотеки Tk.
Модуль с настройками
Для большего удобства версия PyEdit в третьем издании была дополнена возможностью определять начальные параметры настройки за счет присваивания значений переменным в модуле textConfig.py. Если поместить этот файл в путь поиска модулей, при импортировании или запуске редактор PyEdit будет импортировать начальные значения, определяющие шрифт, цвета, размеры текстового окна и необходимость учета регистра символов в операциях поиска. Настройки шрифта и цветов могут изменяться интерактивно с помощью меню, а окна позволяют свободно изменять их размер, поэтому данные настройки предусмотрены в значительной степени для удобства. Обратите также внимание, что этот модуль с настройками будет подключаться всеми экземплярами PyEdit, если он окажется доступным для импортирования клиентским программам, - даже при использовании редактора во всплывающих окнах или при встраивании в другие графические интерфейсы. Однако при необходимости клиентские приложения могут определять собственные версии этого файла с настройками или изменять существующий в пути поиска.
Изменения в версии PyEdit 2.1 (четвертое издание)
Помимо изменений, описанных в предыдущем разделе, при подготовке текущего четвертого издания в PyEdit были внесены следующие дополнительные улучшения:
• Редактор PyEdit был перенесен на новую версию Python 3.1 и его библиотеку tkinter.
• Были исправлены немодальные диалоги поиска с заменой и выбора шрифта - была обеспечена корректная их работа при наличии нескольких окон редактирования, за счет сохранения информации о каждом диалоге отдельно.
• При выполнении операции завершения, вызванной из главного окна, теперь проверяется наличие изменений в других окнах редактирования, открытых в пределах этого же процесса.
• Появился новый пункт Grep меню и диалог поиска во внешних файлах - поиск поддерживает текст Юникода и производится в отдельном потоке выполнения, чтобы избежать блокирования графического интерфейса и позволить одновременно выполнять несколько операций поиска.
• Было внесено небольшое исправление в начальное позиционирование, когда текст изначально вставляется во вновь созданное окно редактора, вызванное изменением в базовых библиотеках.
• Пункт Run Code меню для запуска файлов теперь использует не полное имя файла, содержащее полный путь к нему, а только базовую его часть, чтобы обеспечить поддержку относительных путей; позволяет определять аргументы командной строки для запускаемых файлов; и наследует исправление, выполненное в главе 5 в модуле launchmodes, которое преобразует / в \ в строках путей в файловой системе. Кроме того, этот пункт теперь всегда вызывает метод update между диалогами, чтобы гарантировать корректное отображение.
• Но самое заметное, пожалуй, изменение заключается в том, что теперь PyEdit позволяет отображать и редактировать содержимое файлов в любых кодировках, до той степени, до которой это позволяет библиотека Tk. В частности, имена кодировок учитываются при открытии и сохранении файлов, при отображении текста в графическом интерфейсе и когда выполняется поиск по файлам в каталогах.
В следующих разделах приводятся дополнительные примечания к перечисленным изменениям.
Исправление проблемы состояния модальных диалогов
Диалог поиска с заменой в предыдущей версии сохранял свои поля ввода в объекте текстового редактора, а это означает, что для всех открытых диалогов поиска с заменой использовались самые последние созданные экземпляры полей ввода. Это могло приводить к аварийному завершению программы при попытке выполнить поиск с помощью диалога, открытого ранее, если к этому моменту был закрыт диалог, открытый позднее, так как при закрытии виджеты уничтожаются, - неожиданное поведение диалога, которое существовало, по крайней мере, со второго издания и которое я склонен был отнести к категории ошибок в операторах, но оказалось, что все дело в сохранении состояния! Тот же эффект наблюдался в диалоге выбора шрифта - самый последний экземпляр диалога затирал данные экземпляров, открытых перед ним, однако его обработчик исключений предотвращал аварийное завершение программы (он выводил окно с сообщением об ошибке). Чтобы исправить ошибки в диалогах поиска с заменой и выбора шрифта, теперь поля ввода в каждом диалоге передаются их обработчикам в виде аргументов. Вместо этого можно было бы разрешить создавать только по одному экземпляру этих диалогов, но это решение менее функционально.
Проверка наличия изменений в других окнах того же процесса при завершении
Кроме того, редактор PyEdit имел обыкновение игнорировать наличие изменений в других окнах редактирования при закрытии главного окна. В соответствии с реализацией, щелчок на кнопке Quit во всплывающем окне приводит к закрытию только этого окна, но операция закрытия главного окна вызывает метод quit из библиотеки tkinter, который завершает всю программу. В предыдущей версии при закрытии любого окна выполнялась проверка наличия изменений только в этом окне, а остальные окна игнорировались - закрытие главного окна могло привести к потере изменений в других окнах, закрываемых автоматически при завершении программы.
Чтобы исправить этот недостаток, текущая версия сохраняет список всех открытых в процессе окон редактирования - при закрытии главного окна теперь выполняется проверка наличия изменений во всех окнах и при необходимости предлагается подтвердить завершение программы. Это решение не устраняет все возможные проблемы (оно не устраняет проблему потери изменений, когда завершение приложения производится с помощью виджетов, находящихся за пределами PyEdit), но это существенное улучшение. Более полное решение может заключаться в переопределении или перехвате вызова метода quit библиотеки tkinter. Однако, чтобы не углубляться в детали, я отложу эту тему до более позднего обсуждения в этом же разделе (смотрите обсуждение реализации обработки события ниже); кроме того, смотрите соответствующие комментарии в конце файла с исходным программным кодом PyEdit, где даются примечания к реализации.
Новый диалог Grep: поиск в дереве файлов с поддержкой Юникода и многопоточной модели выполнения
Кроме всего прочего, в меню Search появился новый пункт Grep, реализующий поиск по внешним файлам. Этот инструмент выполняет сканирование целого дерева каталогов в поисках файлов с именами, соответствующими шаблону и содержащими указанную строку. Результаты поиска отображаются в новом немодальном окне с прокручиваемым списком, где выводятся имена файлов, номера и содержимое строк с найденными совпадениями. Щелчок на элементе списка открывает соответствующий файл в новом немодальном окне редактирования PyEdit, при этом автоматически выполняется переход к строке с совпадением и ее выделение. В этой реализации повторно используется программный код, написанный нами ранее:
• Утилита find, написанная нами в главе 6, выполняющая обход дерева каталогов
• Реализация списка с прокруткой из главы 9 для отображения результатов поиска
• Конструктор рядов с полями для форм ввода, созданный в главе 10, для создания немодального диалога ввода
• Существующая реализация всплывающего режима использования PyEdit для отображения содержимого файлов по запросу
• Существующий обработчик события перехода в PyEdit для перемещения к строке с найденным совпадением
Поддержка многопоточной модели выполнения в операции поиска.
Чтобы избежать блокирования графического интерфейса в процессе поиска, поиск производится в параллельных потоках выполнения. Это позволяет запускать сразу несколько операций поиска и выполнять их параллельно (что особенно полезно, когда поиск выполняется в больших деревьях каталогов, таких как стандартная библиотека Python или полное дерево его исходных текстов). При этом применяются такие приемы и механизмы, как стандартные потоки выполнения, очереди и цикл обработки событий от таймера after, с которыми мы познакомились в главе 10, - потоки-производители, не имеющие отношения к графическому интерфейсу, отыскивают совпадения и помещают их в очередь, которая проверяется главным потоком, управляющим графическим интерфейсом, в цикле обработки событий от таймера.
В данной реализации цикл обработки событий от таймера запускается только при выполнении операции поиска, и для каждого поиска используются отдельный поток, отдельный цикл обработки событий от таймера и отдельная очередь. В одном процессе одновременно может выполняться множество потоков и циклов обработки событий от таймера, связанных с поиском, а также могут существовать другие независимые потоки, очереди и циклы обработки событий от таймера. Например, прикрепляемый компонент PyEdit в программе PyMailGUI, представленной в главе 14, может выполнять собственные операции поиска, в то время как программа PyMailGUI выполняет собственные потоки и очереди, используемые для отправки или приема электронной почты. Каждый цикл обработки событий от таймера управляется независимо от процессора событий tkinter. Из-за упрощенной архитектуры в этом примере не используется универсальная реализация threadtools очереди обработчиков из главы 10. Дополнительные примечания о реализации потоков выполнения в операции поиска ищите в исходных текстах, что приводятся далее, и сравните их с файлом _unthreadedtextEditor.py в дереве примеров, где содержится версия PyEdit без поддержки многопоточной модели выполнения.
Поддержка Юникода. Если внимательно изучить реализацию поиска по внешним файлам, можно заметить, что она позволяет определять кодировку для всего дерева и обрабатывает любые исключения, связанные с ошибками декодирования символов, возникающими как при обработке содержимого файлов, так и при обработке имен файлов во время обхода дерева. Как мы узнали в главах 4 и 6, при открытии текстовых файлов в Python 3.X должны декодироваться с применением кодировки, указанной явно или используемой на текущей платформе по умолчанию. Это представляет определенную проблему для операции поиска по файлам, так как деревья каталогов могут содержать файлы с символами в различных кодировках.
Фактически в Windows в одном дереве каталогов часто можно встретить файлы с содержимым в кодировках ASCII, UTF-8 и UTF-16 (варианты ANSI, Utf-8 и Unicode выбора кодировки в Notepad) и даже в других кодировках, особенно в каталогах, где сохраняются файлы, загруженные из Интернета или полученные по электронной почте. Операция открытия таких файлов с применением кодировки UTF-8 в Python 3.X будет приводить к исключениям, а при открытии их в двоичном режиме программа будет получать закодированный текст, в котором едва ли возможно будет отыскать совпадение с искомой строкой. Технически, чтобы выполнить сравнение, необходимо выполнить декодирование байтов, прочитанных из файла, или закодировать искомую строку в байты. При этом совпадение может быть обнаружено только при использовании согласованных кодировок.
Чтобы обеспечить возможность поиска в деревьях каталогов со смешанными кодировками, диалог Grep открывает файлы в текстовом режиме и позволяет вводить имя кодировки, которая будет использоваться для декодирования содержимого всех файлов в просматриваемом дереве каталогов. Для удобства поле ввода с именем кодировки предварительно заполняется значением по умолчанию для текущей платформы, так как этого часто бывает вполне достаточно. Чтобы выполнить поиск в дереве каталогов с файлами разных типов, пользователи могут выполнить несколько операций поиска, указывая различные имена кодировок. При поиске могут также возникать ошибки декодирования имен файлов, но они практически никак не обрабатываются в текущей версии: предполагается, что имена файлов удовлетворяют соглашениям, принятым в файловой системе на данной платформе, в противном случае это приводит к завершению поиска (дополнительные сведения об утилите find обхода дерева каталогов, повторно используемой здесь, а также о проблемах, связанных с кодированием имен файлов в Python, вы найдете в главах 4 и 6).
Кроме того, реализация операции Grep должна предусматривать обработку исключений, связанных с ошибками декодирования файлов, имена которых соответствуют шаблону, но содержимое не может быть декодировано с применением указанной кодировки, и фактически вообще может не быть текстом. Например, операция поиска в стандартной библиотеке Python 3.1 (как в примере поиска строки %, описанном выше) сталкивается с несколькими файлами, которые не смогли быть корректно декодированы в Windows на моем компьютере и могли бы вызвать крах PyEdit. Двоичные файлы, имена которых по случайности соответствуют шаблону, являются еще более худшим вариантом.
В целом программы могут избежать ошибок, вызванных применением неправильных кодировок, либо обрабатывая исключения, либо открывая файлы в двоичном режиме. Так как операция поиска может оказаться не в состоянии интерпретировать содержимое некоторых файлов как текст вообще, при ее реализации был выбран первый подход. В действительности, открытие даже текстовых файлов в двоичном режиме и чтение из них строк двоичных байтов в версии 3.X имитирует поведение текстовых файлов в версии 2.X и позволяет понять, почему принудительный переход на использование Юникода иногда является благом, - двоичный режим позволяет избежать появления исключений, связанных с декодированием, но сам текст по-прежнему остается закодированным и не может использоваться в привычных операциях. В этом случае операция сравнения может давать неверные результаты.
Дополнительные детали, касающиеся поддержки Юникода в реализации диалога Grep, а также описание проблем, связанных с этой поддержкой, и способов их решения, вы найдете в исходном программном коде, который приводится ниже. Дополнительные предложения по улучшению можно найти в главе 19, в описании модуля re - инструмента, который можно использовать для организации поиска по шаблону, а не только по определенной строке.
Исправление проблемы начального позиционирования
В этой версии текстовый редактор также обновляет свой графический интерфейс перед вставкой текста в текстовый виджет на этапе конструирования, когда ему передается имя файла в аргументе loadFirst. Спустя некоторое время, после выхода третьего издания и версии Python 2.5, в Tk или tkinter были внесены какие-то изменения, в результате такая операция вставки текста перед вызовом метода update стала приводить к прокручиванию виджета на одну строку - текст вставлялся, начиная со второй строки, а не с первой. Эта же проблема наблюдалась в версии для третьего издания, при использовании Python 2.6, но не 2.5. Добавление вызова метода update обеспечило корректное позиционирование текстового виджета. Это неприятно, но такое вполне может происходить в мире, зависящем от внешних библиотек!50
Клиенты, использующие классы редактора, также должны вызывать метод update перед вставкой текста вручную во вновь созданный (или скомпонованный) объект текстового редактора, чтобы обеспечить более точное позиционирование, - программа PyView, рассматриваемая далее в этой главе, и PyMailGUI в главе 14 учитывают эту особенность. Редактор PyEdit не может обновлять себя при каждом создании, потому что он может создаваться или даже скрываться вмещающими его графическими интерфейсами (например, это могло бы привести к отображению неполного окна в PyView). Кроме того, PyEdit мог бы автоматически обновлять себя в начале метода setAllText, чтобы исключить необходимость выполнять этот шаг клиентами, но принудительный вызов update требуется выполнить только один раз после компоновки (а не перед каждой вставкой текста), а кроме того, в некоторых случаях это могло бы приводить к нежелательным эффектам. Как правило, добавление лишних операций в методы, как в данном случае, обычно ограничивает область применения компонентов.
Улучшения в операции запуска программного кода
В реализацию операции Run Code из меню TooLs было внесено три исправления, которые сделали еще более удобным запуск редактируемого программного кода из внешнего файла:
1. После перехода в каталог, где хранится файл, для обеспечения правильности всех относительных путей к файлам в его программном коде редактор PyEdit теперь отбрасывает путь из имени файла, прежде чем запустить его, потому что оригинальный путь к файлу может оказаться ошибочным, если он был относительным, а не абсолютным. Например, пути к файлам, открываемым вручную, являются абсолютными, но пути к файлам в программном коде PyDemos, вызывающем редактор, являются относительными - они откладываются относительно корневого каталога с примерами и после выполнения команды chdir могут оказаться недействительными.
2. Теперь в режиме запуска файла с программным кодом PyEdit использует инструменты запуска, поддерживающие возможность передачи аргументов командной строки в Windows.
3. Редактор PyEdit унаследовал исправление, выполненное в модуле launchmodes, которое преобразует символы прямого слеша в обратные в строках путей в файловой системе (хотя позднее, из-за удаления префиксов относительных путей, полезность этого исправления стала вызывать сомнения). Необходимость преобразования прямых символов слеша в PyEdit обусловлена тем, что несмотря на допустимость их использования при вызове функции open в Windows, они не могут использоваться с некоторыми инструментами запуска в этой операционной системе.
Кроме того, в реализацию запуска программного кода как из внешних файлов, так и из строк в памяти, в этой версии был добавлен вызов метода update между вызовами диалогов, чтобы гарантировать, что последний диалог будет появляться на экране в любом случае (ранее в некоторых редких случаях второй диалог не отображался на экране). Даже с этими исправлениями операция Run Code по-прежнему не отличается надежностью. Например, при запуске программного кода из строки, а не из внешнего файла он выполняется внутри процесса, а не в отдельном потоке выполнения, и поэтому может заблокировать графический интерфейс. Кроме того, не совсем понятно, как лучше всего обрабатывать пути импортирования и каталоги для файлов при выполнении программного кода в виде строк, и стоит ли вообще сохранять этот режим. Измените эту особенность в соответствии со своими пожеланиями.
Поддержка текста Юникода (интернационализированного)
Наконец, из-за того, что теперь Python 3.X полностью поддерживает текст Юникода, редактор PyEdit также обеспечивает эту поддержку -он позволяет открывать, сохранять, просматривать, редактировать и отыскивать в дереве каталогов любой текст, в любой кодировке и с любыми наборами символов. Эта поддержка находит множество отражений в пользовательском интерфейсе PyMailGUI:
• При открытии файла у пользователя запрашивается имя кодировки (при этом предлагается системная кодировка по умолчанию), если она не была указана в настройках или при вызове редактора клиентским приложением*
• При сохранении нового файла запрашивается имя кодировки, если она не указана в настройках*
• При отображении и редактировании используется поддержка Юникода, реализованная в инструментах создания графических интерфейсов*
• Операция поиска в дереве каталогов позволяет явно указывать кодировку, которая будет применяться ко всем файлам в дереве, и пропускает файлы, декодировать которые не удалось, как было описано выше*
Благодаря этому обеспечивается поддержка интернационализированного текста, кодировка которого может отличаться от кодировки по умолчанию, используемой на текущей платформе. Это, в частности, удобно для просмотра текстовых файлов, полученных из Интернета, по электронной почте или через FTP. Приложение PyMailGUI из главы 14, например, использует встроенный объект PyEdit для отображения текста вложений различного происхождения и в различных кодировках. Поддержка Юникода в операции поиска по файлам была описана выше - остальные аспекты этой модели, по сути, сводятся к операциям открытия и сохранения файлов, как описывается в следующем разделе.
Файлы с текстом Юникода и модель отображения их содержимого.
Поскольку строки в Python 3.X всегда интерпретируются как последовательности кодовых пунктов Юникода, поддержка Юникода в действительности означает поддержку различных кодировок при чтении и записи в текстовые файлы. Напомню, что текст может сохраняться в файлах в различных кодировках, - данные декодируются при чтении и кодируются при записи с применением этих кодировок. Если текст не всегда сохраняется в файлах с использованием кодировки по умолчанию для данной платформы, то для таких случаев нам необходимо знать, какую кодировку использовать при чтении и записи.
Чтобы обеспечить такую поддержку, редактор PyEdit использует подходы, подробно описанные в главе 9. Мы не будем повторно обсуждать их здесь, тем не менее в двух словах отмечу, что виджет Text принимает содержимое в виде строки типа str или bytes и всегда возвращает его как строку str. Редактор PyEdit отображает этот интерфейс на интерфейс объектов файлов языка Python следующим образом:
Входные файлы (открытие)
Чтобы декодировать байты из файла в строки, в общем случае требуется знать название кодировки, совместимой с данными в файле. Если кодировка окажется несовместимой, операция декодирования потерпит неудачу (например, при попытке декодировать 8-битовые данные с использованием кодировки ASCII). В некоторых случаях кодировка открываемого текстового файла может оказаться неизвестной.
Чтобы при загрузке содержимого входных файлов прочитать данные в виде строк str, редактор PyEdit сначала пытается открывать их в текстовом режиме, применяя кодировки, полученные из разных источников: из аргумента метода, когда кодировка известна заранее (например, из заголовков вложений в сообщениях электронной почты или из исходных файлов, открываемых демонстрационными примерами), из диалога, запрашивающего кодировку у пользователя, из модуля с настройками и из параметров по умолчанию текущей платформы. При выводе диалога, запрашивающего кодировку при открытии файла, поле ввода предварительно заполняется вариантом из файла с настройками, который считается значением по умолчанию.
Если с помощью всех этих кодировок не удается декодировать файл, он открывается в двоичном режиме и текст из него читается как строка bytes, без декодирования, что фактически перемещает задачу декодирования в библиотеку Tk. В этом случае в Windows все последовательности \r\n вручную преобразуются в символы \n, чтобы обеспечить корректное отображение текста и последующее сохранение его в файл. Двоичный режим используется только в самом крайнем случае, чтобы лишний раз не полагаться на логику декодирования и ограниченную поддержку кодировок в библиотеке Tk.
Обработка текста
При обращении к виджету Text он возвращает свое содержимое в виде строки str, независимо от того, в каком виде, str или bytes, был вставлен текст. Вследствие этого вся обработка текстового содержимого производится с применением методов строк str Юникода.
Выходные файлы (сохранение)
Операция кодирования строк в байты при записи в файлы обычно отличается большей гибкостью, чем операция декодирования. При этом не требуется использовать ту же самую кодировку, которая применялась для декодирования данных в строку, но и эта операция может потерпеть неудачу, если выбранная схема кодирования окажется слишком узкой для содержимого строки (например, попытка кодировать 8-битовый текст с применением кодировки ASCII).
Для сохранения текста в файл редактор PyEdit открывает выходной файл в текстовом режиме, чтобы обеспечить отображение символов конца строки и кодирование содержимого строки str Юникода. Имя кодировки извлекается из одного из источников - это может быть кодировка, использовавшаяся при открытии или первоначальном сохранении файла (если была указана), или кодировка, полученная из диалога с пользователем, из модуля с настройками или из параметров по умолчанию текущей платформы. В отличие от операции открытия, когда операция сохранения выводит диалог запроса имени кодировки, поле ввода заполняется именем известной кодировки, если она была определена прежде, в противном случае берется вариант из файла с настройками, как и в случае с операцией открытия.
Диалоги ввода кодировки, вызываемые операциями открытия и сохранения файлов, - это лишь одно из воплощений описанных правил в графическом интерфейсе; другие варианты определяются в модуле с настройками. Поскольку заранее невозможно предугадать все возможные случаи использования, в редакторе PyEdit применяется либеральный подход: он поддерживает все мыслимые режимы и обеспечивает пользователям возможность влиять на определение кодировок с помощью определения настроек в их собственном модуле textConfig. Он пытается применить одну кодировку за другой из разных источников, если это разрешено в модуле textConfig, пока не будет найдена кодировка, дающая положительные результаты. Тем самым достигается максимальная маневренность перед лицом переменчивого мира Юникода.
Например, согласно параметрам в файле с настройками операция сохранения повторно использует кодировку, которая применялась при открытии файла или при первой операции сохранения, если она известна. Для новых файлов (созданных выбором пункта New в меню или вставкой текста вручную) и для файлов, открытых в двоичном режиме, кодировка остается неизвестной до момента сохранения, но для файлов, которые удалось открыть в текстовом режиме, она известна. Кроме того, с помощью параметров в файле с настройками мы можем определить необходимость запрашивать кодировку у пользователя при выполнении операции Save As (и, возможно, Save), потому что у него могут быть свои предпочтения при создании новых файлов. Мы также можем запрашивать кодировку при открытии существующих файлов, потому что для этого необходимо знать его текущую кодировку. В некоторых случаях (например, для файлов, полученных из Интернета) пользователь может не знать ее, но в других случаях он может предпочесть указать кодировку явно. Вместо того чтобы выбирать тот или иной порядок действий в таких ситуациях, мы просто опираемся на пользовательские настройки.
На практике все это относится только к клиентам PyEdit, которые запрашивают начальную загрузку файлов или позволяют открывать и сохранять файлы с помощью графического интерфейса. Поскольку содержимое может вставляться как строка типа str или bytes, клиенты всегда имеют возможность читать входные файлы самостоятельно, до создания объекта текстового редактора, и вставлять в него текст вручную. Кроме того, клиенты могут получать содержимое вручную и сохранять его любым предпочитаемым способом. Такое выполнение операций вручную может оказаться полезным, если в каком-то контексте методика, реализованная в редакторе PyEdit, окажется нежелательной. Поскольку виджет Text всегда возвращает содержимое в виде строки str, остальной части этой программы безразлично, строка какого типа была в него вставлена.
Имейте в виду, что описанная методика по-прежнему зависит от поддержки Юникода и от ограничений, заложенных в библиотеке Tk, а также от интерфейса tkinter к ней. Редактор PyEdit позволяет загружать и сохранять текст в любой кодировке, но он не может гарантировать, что библиотека графического интерфейса сможет отобразить такой текст. То есть даже если мы совершенно корректно обрабатываем текст Юникода на стороне Python, мы все равно остаемся во власти других слоев программного обеспечения, обсуждение которых выходит далеко за рамки этой книги. Библиотека Tk достаточно надежно работает с самыми разными наборами символов, если ей передавать уже декодированные строки str Юникода (смотрите, например, описание поддержки интернационализации в PyMailGUI в главе 14), но ситуации в конкретных случаях могут сильно различаться.
Порядок выбора кодировки и возможные варианты. Имейте также в виду, что политика редактора PyEdit в отношении Юникода отражает предпочтения единственного текущего пользователя и не проверялась на универсальность и эргономику - будучи книжным примером, редактор не использует встроенную среду тестирования, как это свойственно проектам с открытыми исходными текстами. Неплохие результаты можно было бы получать, используя другие схемы и порядки следования источников, и совершенно невозможно предугадать предпочтения каждого пользователя в каждом конкретном случае. Например:
• Непонятно, следует ли сначала запрашивать кодировку у пользователя, а потом пытаться использовать кодировку, указанную в файле с настройками, или наоборот.
• Возможно также, что мы всегда должны спрашивать кодировку у пользователя, полагаясь в основном на это, независимо от параметров настройки.
• При сохранении мы могли бы также попробовать самостоятельно определить кодировку для применения к строке str (например, попробовать применить UTF-8, Latin-1 или другую распространенную кодировку), но наши предположения могут не совпадать с тем, что имел в виду пользователь.
• Весьма вероятно, что пользователь пожелает сохранить файл в той же кодировке, которая применялась при открытии файла или при сохранении в первый раз. Редактор PyEdit предоставляет поддержку этого варианта, в противном случае графический интерфейс запрашивал бы кодировку для данного файла более чем один раз. Однако, поскольку некоторым пользователям может потребоваться повторно использовать операцию Save, чтобы сохранить тот же файл в другой кодировке, то предусмотрена возможность отключения этого варианта в модуле с настройками. На первый взгляд, для этой цели было бы лучше использовать операцию Save As, однако следующий пункт объясняет, почему это не всегда так.
• Точно так же неочевидно, должна ли операция Save As повторно использовать кодировку, которая применялась при открытии или при сохранении файла в первый раз, или она должна запрашивать новую кодировку - действительно ли при этом сохраняется совершенно новый файл или только копия предыдущего содержимого с установленной кодировкой, но под новым именем? Из-за такой неоднозначности мы даем возможность запретить использование установленной кодировки в операции Save As или в обеих операциях, Save и Save As, в модуле с настройками. По умолчанию использование известной кодировки разрешено только для операции Save и запрещено для Save As. В любом случае, операции сохранения выводят диалоги, запрашивающие имя кодировки, в которых поле ввода заполнено известной кодировкой.
• Порядок выбора вариантов вообще выглядит весьма спорным. Например, возможно, операция Save As должна использовать известную кодировку, если настройки запрещают запрашивать ее у пользователя, - в данной реализации, если настройки запрещают использовать известную кодировку и запрашивать ее у пользователя, эта операция будет определять кодировку из файла с настройками или использовать системную кодировку по умолчанию (например, UTF-8), что может оказаться не самым лучшим решением при сохранении составных частей сообщений электронной почты, кодировка которых уже известна.
И так далее. Поскольку такой пользовательский интерфейс обеспечивает широчайший выбор вариантов, в целях иллюстрации в этой книге реализованы общий и частично эвристический алгоритмы поддержки каждого из возможных вариантов, и в качестве опоры при выборе используются настройки пользователя. Однако на практике такая гибкость может оказаться совершенно излишней - большинству пользователей наверняка будет достаточно поддержки какого-то одного алгоритма из числа поддерживаемых здесь.
Кроме того, вероятно, было бы удобнее, если бы алгоритмом выбора кодировки можно было управлять непосредственно в графическом интерфейсе, вместо того чтобы вручную определять его в модуле с настройками. Например, возможно, каждая операция - Open, Save и Save As - должна позволять выбирать кодировку и по умолчанию использовать последнюю известную кодировку, если таковая определена. Реализация этой возможности в виде раскрывающихся списков с именами кодировок или полей ввода в диалогах Save и Open позволила бы отказаться от лишних диалогов и достичь практически той же гибкости.
В текущей реализации редактора PyEdit имеется возможность определить в файле с настройками необходимость запрашивать кодировку у пользователя для обеих операций, открытия и сохранения, что дает практически тот же эффект, по крайней мере в тех ситуациях, с которыми я сталкивался до настоящего момента, и, возможно, является лучшим решением для большинства контекстов.
Таким образом, по умолчанию:
• Операция Open использует переданную ей кодировку, если она была указана, или запрашивает имя кодировки у пользователя
• Операция Save повторно использует известную кодировку, если она была определена ранее, а при сохранении новых файлов запрашивает ее у пользователя
• Операция Save As всегда запрашивает имя кодировки у пользователя, как при сохранении нового файла
• Операция Grep позволяет вводить кодировку в диалоге определения параметров поиска и применяет ее при поиске во всех файлах, имеющихся в дереве каталогов
С другой стороны, поскольку умолчаний, определяемых платформой, будет вполне достаточно для работы без лишних сложностей взаимодействия с графическим интерфейсом, по крайней мере, для подавляющего числа пользователей, с помощью параметров в модуле textConfig можно предотвратить вывод диалога запроса кодировки и вернуться к использованию кодировки, указанной явно или определяемой платформой по умолчанию. В конечном счете, определение наиболее удачного алгоритма выбора кодировки требует анализа предпочтений широкого круга пользователей, а не предположений единственного разработчика. Как всегда, вы свободно можете адаптировать этот алгоритм под свои потребности.
В подкаталоге test в дереве примеров вы найдете несколько текстовых файлов в различных кодировках, с которыми вы можете экспериментировать при изменении алгоритмов выбора кодировки в модуле textConfig для операций открытия и сохранения файлов. Этот каталог содержит файлы, изображенные на рис. 11.5 и 11.6, в которых используются национальные наборы символов и сохраненные в различных кодировках. Например, файл email-part--koi8-r содержит текст на русском языке, сохраненный в кодировке koi8-r, а файл email-part--koi8-r--utf8 содержит тот же текст, сохраненный в кодировке UTF-8, - последний можно открыть в программе Блокнот (Notepad) в Windows, но первый будет корректно отображен только при передаче PyEdit явно указанной кодировки.
Еще лучше, сохраните сами один и тот же файл в нескольких кодировках, жестко определяя кодировку в модуле textConfig или указывая разные кодировки при сохранении, - благодаря широкомасштабной поддержке Юникода в Python 3.X, редактор PyEdit позволяет сохранять и загружать файлы практически в любой кодировке.
Еще о проверке наличия изменений при завершении: событие
Необходимо сказать несколько слов о еще одном изменении в версии 2.1, прежде чем перейти к программному коду, поскольку он иллюстрирует основы закрытия окон tkinter в действующей программе. В главе 8 мы узнали, что библиотека tkinter позволяет выполнять с помощью метода bind привязку обработчика к событию , которое возбуждается при закрытии окна или уничтожении виджета. Мы могли бы привязать обработчики этого события к окнам PyEdit или к их текстовым виджетам, чтобы перехватить момент завершения программы, но это не принесло бы нам никакой выгоды в данной ситуации. В обработчике этого события сценарии вообще не могут выполнять какие-либо операции с графическим интерфейсом, потому что к моменту его вызова графический интерфейс уже разрушен. В частности, попытка проверить наличие изменений в текстовом виджете или извлечь его содержимое в обработчике события может привести к исключению. Вывод диалога с сообщением о необходимости сохранения также может действовать несколько странно: он появится только после того, как некоторые виджеты окна уже будут стерты (включая текстовый виджет, содержимое которого пользователь должен был бы проверить и сохранить!), а иногда даже вообще может не появится.
Кроме того, как уже упоминалось в главе 8, вызов метода quit не возбуждает события , но вызывает фатальную ошибку Python при выходе. Чтобы вообще иметь возможность использовать события , при выполнении операции Quit редактор PyEdit должен был бы закрывать окна только вызовом метода destroy и полагаться на протокол закрытия корневого окна Tk - непосредственное завершение приложения оказалось бы невозможным или потребовало бы использования таких инструментов, как sys.exit. Поскольку в обработчике события любые операции с графическим интерфейсом оказываются недопустимыми, использование этого приема ничем не оправдано. Программный код, выполняемый после вызова функции mainloop, также не способен помочь решить эту проблему, потому что функция mainloop вызывается за пределами PyEdit и после выхода из нее оказывается слишком поздно проверять наличие изменений и выполнять сохранения.
Иными словами, событие не решает проблему проверки необходимости сохранения перед закрытием окна, и оно никак не помогает в случае вызова методов quit и destroy виджетов из-за пределов классов окон PyEdit. Из-за этих сложностей PyEdit полагается на проверку изменений перед закрытием в каждом отдельном окне и проверяет наличие изменений в окнах, находящихся в списке, прежде чем закрыть любое из главных окон. Приложения, следующие данной модели окон, будут выполнять проверку автоматически. Приложения, использующие PyEdit как компонент более крупного графического интерфейса или использующие его иными способами, управляя редактором PyEdit извне, сами должны проверять наличие несохраненных изменений при закрытии, еще до того, как объект PyEdit или его виджеты будут разрушены.
Чтобы поэкспериментировать с событием , отыщите в дереве примеров файл destroyer.py - он имитирует действия, которые должен был бы выполнить редактор PyEdit при получении события . Ниже приводится наиболее важный фрагмент из этого сценария с комментариями, поясняющими его поведение:
def onDeleteRequest():
print(‘Got wm delete’) # щелчок на кнопке X в окне: можно отменить
root.destroy() # возбудит событие
def doRootDestroy(event):
print(‘Got event ’) # для каждого виджета в корневом окне if event.widget == text: print(‘for text’)
print(text.edit_modified()) # <= ошибка Tcl: неверный виджет
ans = askyesno(‘Save stuff?’, ‘Save?’) # <= некорректное поведение
if ans: print(text.get(‘1.0’, END+’-1c’)) # <= ошибка Tcl: неверный
# виджет
root = Tk()
text = Text(root, undo=1, autoseparators=1) text.pack()
root.bind(‘’, doRootDestroy) # для корневого и дочерних
root.protocol(‘WM_DELETE_WINDOW’, onDeleteRequest) # на кнопке X окна
Button(root, text=’Destroy’, command=root.destroy).pack() # возбудит Button(root, text=’Quit’, command=root.quit).pack() # <= фатальная ошибка mainloop() # Python, quit() не
# возбуждает
Дополнительные подробности, касающиеся всего, о чем говорилось выше, ищите в листингах, которые приводятся в следующем разделе. Кроме того, обязательно прочитайте строку документирования в главном файле, где приводится список предлагаемых расширений и решений проблемы открытия файлов (под заголовком «TBD»). На реализацию редактора PyEdit значительное влияние оказали влияние мои личные предпочтения, но вы можете настроить его под себя.
Исходный программный код PyEdit
Программа PyEdit состоит из одного маленького модуля с настройками и одного главного файла с реализацией, содержащего чуть больше 1000 строк программного кода, с расширением .py, который можно запускать или импортировать. Для использования в Windows предоставляется еще один однострочный файл с расширением .pyw, который просто запускает файл .py вызовом exec(open(‘textEditor.py’).read()). Расширение .pyw предотвращает появление консоли DOS на экране при запуске в Windows.
В настоящее время файлы с расширением .pyw могут импортироваться и выполняться как обычные файлы с расширением .py (их можно запускать двойным щелчком мыши или с помощью таких инструментов языка Python, как os.system и os.startfile), поэтому в действительности нет необходимости создавать отдельный файл, чтобы обеспечить возможность импортирования и запуска без вывода окна консоли. Однако я оставил расширение .py, чтобы в процессе разработки видеть сообщения, которые выводятся в окно консоли, и использовать PyEdit, как простую интегрированную среду разработки, - когда операция запуска программного кода настроена на выполнение отдельных инструкций (а не файлов), вывод, который производится программным кодом, отображается в окне консоли DOS редактора PyEdit. Предполагается, что клиенты будут в обычном случае импортировать файл .py.
Файл с настройками пользователя
Итак, перейдем к программному коду. В первую очередь рассмотрим модуль с настройками пользователя, который приводится в примере 11.1. Он предназначен главным образом для того, чтобы было удобнее определять параметры внешнего вида, отличные от значений по умолчанию. Редактор PyEdit реализован так, что может работать и без этого модуля, и если он содержит синтаксические ошибки. Этот файл предназначен, прежде всего, для использования редактором PyEdit, когда он запускается как самостоятельный сценарий (в этом случае файл с настройками импортируется из текущего каталога), но вы также можете определить собственную версию файла с настройками PyEdit в любом другом каталоге, включенном в путь поиска модулей.
Дополнительно о том, какие настройки загружаются редактором, смотрите исходный программный код textEditor.py далее. Содержимое этого файла импортируется двумя различными способами - одна инструкция импортирования, которая загружает настройки внешнего вида, предполагает, что этот модуль (а не содержащий его пакет) находится в пути поиска модулей, и пропускает его, если его не находит, а другая, загружающая настройки порядка выбора кодировок, всегда отыскивает этот файл, независимо от способа запуска. Ниже описывается, что означает такое деление настроек для клиентов:
• Поскольку первая операция импортирования, загружающая настройки внешнего вида, ищет файл в пути поиска модулей, а не в каталоге основного пакета, то для каждого клиентского приложения, в его домашнем каталоге, можно определить собственный файл textConfig.py и тем самым обеспечить индивидуальные настройки PyEdit для каждого клиента.
• Настройки порядка выбора кодировки, напротив, всегда загружаются из файла, находящегося в каталоге пакета, с использованием операции импортирования по относительному пути, потому что они имеют более важное значение и маловероятно, что они будут отличаться от одного приложения к другому. Используемая здесь операция импортирования по относительному пути в пакете является эквивалентом импортирования всего пакета от корня PP4E, но не зависит от структуры каталогов.
Подобно эвристическим алгоритмам выбора кодировки символов, описанным выше, эта модель импортирования может считаться ориентировочной и может быть пересмотрена в соответствии с требованиями практической реализации.
Пример 11.1. PP4E\Gui\TextEditor\textConfig.py
модуль с начальными настройками PyEdit (textEditor.py);
#-----------------------------------------------------------------------------
# Общие настройки
# закомментируйте любые настройки в этом разделе, чтобы принять настройки по
# умолчанию библиотеки Tk или программы; шрифт/цвет можно также менять из меню
# в графическом интерфейсе, а также менять размеры окон после их открытия;
# импортируются из пути поиска модулей: могут определять отдельные настройки
# для каждого клиентского приложения, игнорируется, если находится не в пути
# поиска модулей;
# -----------------------------------------------------------------------------
# начальные настройки шрифта # семейство, размер, стиль
font = (‘courier’, 9, ‘normal’) # например, стиль: ‘bold italic’
# начальные настройки цвета # по умолчанию = white, black
bg = ‘lightcyan’ # название цвета или шестнадцатеричный код RGB
fg = ‘black’ # например, ‘powder blue’, ‘#690f96’
# начальные настройки размеров
height = 20 # умолчания Tk: 24 строки
width = 80 # умолчания Tk: 80 символов
# нечувствительность к регистру при поиске
caseinsens = True # по умолчанию = 1/True (включена)
# -----------------------------------------------------------------------------
# 2.1: Порядок выбора кодировки для содержимого и имен файлов в операциях
# открытия и сохранения;
# опробует каждый случай из перечисленных ниже в указанном порядке, пока не
# будет обнаружен первый, дающий положительный результат; запишите во все
# переменные false/пустое значение/0, чтобы перейти к использованию умолчаний
# для вашей платформы (то есть ‘utf-8’ - в Windows, или ‘ascii’, ‘latin-1’
# или другая кодировка в иных системах, таких как Unix);
# savesUseKnownEncoding: 0=Нет, 1=Да, только для операции Save, 2=Да для
# операций Save и SaveAs;
# всегда импортируются из этого файла: sys.path - если главный модуль, иначе -
# относительно пакета;
# -----------------------------------------------------------------------------
# 1) Сначала выполняется попытка применить известную
# кодировку (например, из заголовка сообщения
# электронной почты)
opensAskUser = True # 2) Если True, далее выполняется запрос у пользователя
# (предварительно заполняется значением по умолчанию)
opensEncoding = '' # 3) Если непустое значение, далее будет выполнена попытка
# применить эту кодировку: ‘latin-1’, ‘cp500’
# 4) Далее выполняется попытка применить
# sys.getdefaultencoding() - системное значение
# по умолчанию
# 5) В крайнем случае текст передается в двоичном виде и
# используются алгоритмы Tk
savesUseKnownEncoding = 1 # 1) Если > 0, выполняется попытка применить
# кодировку, известную по последней операции Open
# или Save
savesAskUser = True # 2) Если True, далее выполняется запрос у
# пользователя (предварительно заполняется
# известным значением?)
savesEncoding = ‘’ # 3) Если непустое значение, далее будет выполнена
# попытка применить эту кодировку: ‘utf-8’ и так
# далее
# 4) В крайнем случае выполняется попытка применить
# sys.getdefaultencoding()
Файлы запуска для Windows (и других систем)
Далее, в примере 11.2 приводится файл запуска с расширением .pyw, используемый для подавления окна консоли DOS в Windows, которое выводится при запуске в некоторых режимах (например, двойным щелчком). Окно консоли по-прежнему можно получить при запуске файла с расширением .py (например, чтобы увидеть вывод, генерируемый программным кодом, запускаемым редактором в режиме выполнения единственной инструкции). Двойной щелчок на этом файле дает тот же эффект, что и запуск PyEdit с помощью панели запуска PyDemos или PyGadgets.
Пример 11.2. PP4E\Gui\TextEditor\textEditorNoConsole.pyw
запускает редактор и подавляет вывод окна консоли DOS в Windows; с тем же успехом можно было бы просто присвоить расширение .pyw основному файлу, что не помешало бы возможности импортировать его, но файл .py был оставлен, чтобы иметь возможность наблюдать вывод в консоли
exec(open(‘textEditor.py’).read()) # как будто содержимое файла вставляется
# сюда (или textEditor.main())
Пример 11.2 прекрасно справляется с возложенной на него задачей, но когда я обновлял эту книгу, мне надоело использовать каждый раз Notepad для просмотра текстовых файлов из командных строк, запускаемых из произвольных мест, поэтому я написал сценарий, представленный в примере 11.3, который запускает PyEdit более универсальным и автоматизированным способом. Этот сценарий подавляет вывод консоли DOS, подобно примеру 11.2, когда запускается щелчком мыши на ярлыке в Windows, но дополнительно выполняет настройку пути поиска модулей на компьютерах, где я не использовал Панель Управления (Control PaneL) для этого, и позволяет запускать редактор, даже когда он находится за пределами текущего рабочего каталога.
Пример 11.3. PP4E\Gui\TextEditor\pyedit.pyw
#!/usr/bin/python
удобный сценарий для запуска pyedit из произвольного каталога, выполняет необходимую корректировку пути поиска модулей; sys.path при импортировании и функции open() требуется передавать путь относительно известного пути к каталогу со сценарием, а не относительно текущего рабочего каталога, потому что текущим является каталог сценария, только если сценарий запускается щелчком на ярлыке, а при вводе команды в командной строке он может находиться в любом другом каталоге: использует путь из argv; этому файлу дано расширение .pyw, чтобы подавить вывод окна консоли в Windows; добавьте каталог с этим сценарием в системную переменную PATH, чтобы иметь возможность запускать его из командной строки; также может использоваться в Unix: символы / и \ обрабатываются переносимым образом;
import sys, os
mydir = os.path.dirname(sys.argv[0]) # использовать каталог сценария для
# open, sys.path
sys.path.insert(1, os.sep.join([mydir] + [‘..’]*3)) # импорт: PP4E - корень,
# 3 уровнями выше
exec(open(os.path.join(mydir, ‘ textEditor.py')).read())
Чтобы запустить его из командной строки в окне консоли, достаточно, чтобы путь к каталогу со сценарием находился в системной переменной окружения PATH, - действие, выполняемое в первой строке в следующем фрагменте, достаточно было бы выполнить один раз в Панели Управления (Control Panel) Windows:
C:\..d\PP4E\Internet\Web....... set PATH=XPATHX;C:\...\PP4E\Gui\TextEditor
C:\...\PP4E\Internet\Web> pyedit.pyw test-cookies.py
Этот сценарий также работает и в Unix, хотя в нем нет необходимости, если правильно установить переменные окружения PYTHONPATH и PATH (после этого можно запускать textEditor.py непосредственно), - а я не стал выполнять эти настройки на всех моих компьютерах. Ради интереса можно попробовать зарегистрировать этот сценарий как средство автоматического открытия файлов «.txt» при щелчке на них или при вводе их имен в командной строке (если, конечно, вы спокойно перенесете расставание с Notepad).
Реализация главного файла
Наконец, модуль в примере 11.4 представляет собой реализацию PyEdit. Этот файл может запускаться как самостоятельный сценарий или импортироваться другими приложениями. Его программный код организован по пунктам главного меню. Главные классы, используемые для запуска и встраивания объекта PyEdit, находятся в конце файла. Во время экспериментов с PyEdit изучайте этот листинг, чтобы разобраться в его возможностях и используемых приемах.
Пример 11.4. PP4E\Gui\TextEditor\textEditor.py
##############################################################################
PyEdit 2.1: Текстовый редактор и компонент на Python/tkinter.
Использует текстовый виджет из библиотеки Tk, меню и панель инструментов GuiMaker для реализации полнофункционального текстового редактора, который может выполняться, как самостоятельная программа, или прикрепляться к другим графическим интерфейсам, как компонент. Используется также в PyMailGUI и PyView для редактирования сообщений электронной почты и примечаний к файлам изображений. Кроме того, используется в PyMailGUI и PyDemos во всплывающем режиме для отображения текстовых файлов и файлов с исходными текстами.
Новое в версии 2.1 (4 издание)
- работает под управлением Python 3.X (3.1)
- добавлен пункт "grep” меню и диалог: многопоточный поиск в файлах
- проверяет все окна на наличие несохраненных изменений при завершении
- поддерживает произвольные кодировки для файлов: в соответствии с настройками в файле textConfig.py
- переработаны диалоги поиска с заменой и выбора шрифта, чтобы обеспечить возможность одновременного вывода нескольких диалогов
- вызывает self.update() перед вставкой текста в новое окно
- различные улучшения в реализации операции Run Code, как описывается в следующем разделе
2.1 улучшения в реализации операции Run Code:
- после команды chdir использует базовое имя запускаемого файла, а не относительные пути
- в Windows использует инструмент запуска, поддерживающий передачу аргументов командной строки
- операция Run Code наследует преобразование символов обратного слеша от модуля launchmodes (необходимость в этом уже отпала)
Новое в версии 2.0 (3 издание)
- добавлен простой диалог выбора шрифта
- использует прикладной интерфейс Tk 8.4 к стеку отмен, чтобы добавить поддержку отмены/возврата (undo/redo) операций редактирования
- запрос подтверждения при выполнении операций Quit, Open, New, Run выполняется, только если имеются несохраненные изменения
- поиск теперь по умолчанию выполняется без учета регистра символов
- создан модуль с настройками для начальных значений шрифта/цвета/размера/чувствительности к регистру при поиске
TBD1 (и предложения для самостоятельной реализации):
- необходимость учета регистра символов при поиске можно было бы задавать в графическом интерфейсе (а не только в файле с настройками)
- при поиске по файлу или в операции Grep можно было бы использовать поддержку регулярных выражений, реализованную в модуле re (см. следующую главу)
- можно было бы попробовать реализовать подсветку синтаксиса (как в IDLE или в других редакторах)
- можно было бы попробовать проверить завершение работы программы методом quit() в неподконтрольных окнах
- можно было бы помещать в очередь каждый результат, найденный в диалоге Grep, чтобы избежать задержек
- можно было бы использовать изображения на кнопках в панели инструментов (как в примерах из главы 9)
- можно было бы просматривать строки, чтобы определить позицию вставки Tk для оформления отступов в окне Info
- можно было бы поэкспериментировать с проблемой кодировок в диалоге "grep” (смотрите примечания в программном коде);
##############################################################################
Version = ‘2.1’
import sys, os # платформа, аргументы,
# инструменты запуска
from tkinter import * # базовые виджеты, константы
from tkinter.filedialog import Open, SaveAs # стандартные диалоги from tkinter.messagebox import showinfo, showerror, askyesno from tkinter.simpledialog import askstring, askinteger from tkinter.colorchooser import askcolor
from PP4E.Gui.Tools.guimaker import * # Frame + построители
# меню/панелей инструментов
# общие настройки try:
import textConfig # начальный шрифт и цвета
configs = textConfig.__dict__ # сработает, даже если модуль отсутствует в
except: # пути поиска или содержит ошибки
configs = {}
helptext = """PyEdit, версия %s
апрель, 2010 (2.0: январь, 2006)
(1.0: октябрь, 2000)
Программирование на Python, 4 издание
Марк Лутц (Mark Lutz), для издательства O’Reilly Media, Inc.
Программа и встраиваемый компонент текстового редактора, написанный на Python/tkinter. Для быстрого доступа к операциям использует отрывные меню, панели инструментов и горячие клавиши в меню.
To Be Done - что еще можно сделать. - Прим. ред.
Дополнения в версии %s:
- поддержка 3.X
- новый диалог "grep” поиска во внешних файлах
- проверка несохраненных изменений при завершении
- поддержка произвольных кодировок для файлов
- допускает одновременный вывод нескольких диалогов поиска с заменой и выбора шрифта
- различные улучшения в операции Run Code
Дополнения в предыдущей версии:
- диалог выбора шрифта
- неограниченное количество отмен/возвратов
- quit/open/new/run предлагают сохранить, только если есть несохраненные изменения
- поиск выполняется без учета регистра символов
- модуль с начальными настройками textConfig.py
START = ‘1.0’ # индекс первого символа: строка=1,столбец=0
SEL_FIRST = SEL + ‘.first’ # отобразить тег sel в индекс
SEL_LAST = SEL + ‘.last’ # то же, что ‘sel.last’
FontScale = 0 # использовать увеличенный шрифт в Linux
if sys.platform[:3] != ‘win’: # и в других не-Windows системах FontScale = 3
##############################################################################
# Главные классы: реализуют графический интерфейс редактора, операции
# разновидности GuiMaker должны подмешиваться в более специализированные
# подклассы, а не наследоваться непосредственно, потому что этот класс
# принимает множество форм.
##############################################################################
class TextEditor: # смешать с классом Frame, имеющим меню/панель инструментов startfiledir = ‘.’ # для диалогов editwindows = [] # для проверки при завершении
# Настройки порядка выбора кодировки
# импортируется в класс, чтобы обеспечить возможность переопределения в
# подклассе
if__name__== ‘__main__’:
from textConfig import ( # мой каталог в пути поиска
opensAskUser, opensEncoding,
savesUseKnownEncoding, savesAskUser, savesEncoding)
else:
from .textConfig import ( # 2.1: всегда из этого пакета
opensAskUser, opensEncoding,
savesUseKnownEncoding, savesAskUser, savesEncoding)
ftypes = [(‘All files’, ‘*’), # для диалога открытия файла
(‘Text files’, ‘.txt’), # настроить в подклассе или
(‘Python files’, ‘.py’)] # устанавливать в каждом экземпляре
colors = [{‘fg’:’black’, ‘bg’:’white’}, # список цветов для выбора
{‘fg’:’yellow’, ‘bg’:’black’}, # первый элемент по умолчанию
{‘fg’:’white’, ‘bg’:’blue’}, # переделать по-своему или
{‘fg’:’black’, ‘bg’:’beige’}, # использовать элемент выбора
{‘fg’:’yellow’, ‘bg’:’purple’},# PickBg/Fg
{‘fg’:’black’, ‘bg’:’brown’},
{‘fg’:’lightgreen’, ‘bg’:’darkgreen’},
{‘fg’:’darkblue’, ‘bg’:’orange’},
{‘fg’:’orange’, ‘bg’:’darkblue’}]
fonts = [(‘courier’, 9+FontScale, ‘normal’), # шрифты, нейтральные
(‘courier’, 12+FontScale, ‘normal’), # в отношении платформы
(‘courier’, 10+FontScale, ‘bold’), # (семейство, размер, стиль)
(‘courier’, 10+FontScale, ‘italic’), # или вывести в списке
(‘times’, 10+FontScale, ‘normal’), # увеличить в Linux
(‘helvetica’, 10+FontScale, ‘normal’), # использовать
(‘ariel’, 10+FontScale, ‘normal’), # ‘bold italic’ для 2
(‘system’, 10+FontScale, ‘normal’), # а также ‘underline’
(‘courier’, 20+FontScale, ‘normal’)]
def __init__(self, loadFirst=’’, loadEncode=’’):
if not isinstance(self, GuiMaker):
raise TypeError(‘TextEditor needs a GuiMaker mixin’) self.setFileName(None) self.lastfind = None self.openDialog = None self.saveDialog = None
self.knownEncoding = None # 2.1 кодировки: заполняется Open или Save self.text.focus() # иначе придется щелкнуть лишний раз
if loadFirst:
self.update() # 2.1: иначе строка 2;
self.onOpen(loadFirst, loadEncode) # см. описание в книге
def start(self): # вызывается из GuiMaker.__init__
self.menuBar = [ # настройка меню/панелей
(‘File’, 0, # определение дерева меню GuiMaker
[(‘Open...’, 0, self.onOpen), # встроен. метод для self
(‘Save’, 0, self.onSave), # метка, клавиша, обработчик
(‘Save As...’, 5, self.onSaveAs),
(‘New’, 0, self.onNew),
‘separator’,
(‘Quit...’, 0, self.onQuit)]
),
(‘Edit’, 0,
[(‘Undo’, 0, self.onUndo),
(‘Redo’, 0, self.onRedo),
‘separator’,
(‘Cut’, 0, self.onCut),
(‘Copy’, 1, self.onCopy), (‘Paste’, 0, self.onPaste),
‘separator’,
(‘Delete’, 0, self.onDelete),
(‘Select All’, 0, self.onSelectAll)]
),
(‘Search’, 0,
[(‘Goto...’, 0, self.onGoto),
(‘Find...’, 0, self.onFind),
(‘Refind’, 0, self.onRefind),
(‘Change...’, 0, self.onChange),
(‘Grep...’, 3, self.onGrep)]
),
(‘Tools’, 0,
[(‘Pick Font...’, 6, self.onPickFont),
(‘Font List’, 0, self.onFontList),
‘separator’,
(‘Pick Bg...’, 3, self.onPickBg),
(‘Pick Fg...’, 0, self.onPickFg),
(‘Color List’, 0, self.onColorList),
‘separator’,
(‘Info...’, 0, self.onInfo),
(‘Clone’, 1, self.onClone),
(‘Run Code’, 0, self.onRunCode)]
)]
self.toolBar = [
(‘Save’, self.onSave, {‘side’: LEFT}),
(‘Cut’, self.onCut, {‘side’: LEFT}),
(‘Copy’, self.onCopy, {‘side’: LEFT}),
(‘Paste’, self.onPaste, {‘side’: LEFT}),
(‘Find’, self.onRefind, {‘side’: LEFT}),
(‘Help’, self.help, {‘side’: RIGHT}),
(‘Quit’, self.onQuit, {‘side’: RIGHT})]
def makeWidgets(self): # вызывается из GuiMaker.__init__
name = Label(self, bg=’black’, fg=’white’) # ниже меню, выше панели name.pack(side=TOP, fill=X) # компоновка меню/панелей
# фрейм GuiMaker
# компонуется сам
vbar = Scrollbar(self)
hbar = Scrollbar(self, orient=’horizontal’)
text = Text(self, padx=5, wrap=’none’) # запретить перенос строк
text.config(undo=1, autoseparators=1) # 2.0, по умолчанию 0, 1
vbar.pack(side=RIGHT, fill=Y)
hbar.pack(side=BOTTOM, fill=X) # скомпоновать Text последним
text.pack(side=TOP, fill=BOTH, expand=YES) # иначе обрежутся полосы
# прокрутки
text.config(yscrollcommand=vbar.set) # вызывать vbar.set при
text.config(xscrollcommand=hbar.set) # перемещении по тексту
vbar.config(command=text.yview) # вызывать text.yview при прокрутке hbar.config(command=text.xview) # или hbar[‘command’]=text.xview
# 2.0: применить пользовательские настройки или умолчания startfont = configs.get(‘font’, self.fonts[0]) startbg = configs.get(‘bg’, self.colors[0][‘bg’]) startfg = configs.get(‘fg’, self.colors[0][‘fg’]) text.config(font=startfont, bg=startbg, fg=startfg) if ‘height’ in configs: text.config(height=configs[‘height’]) if ‘width’ in configs: text.config(width =configs[‘width’]) self.text = text self.filelabel = name
##########################################################################
# Операции меню File
##########################################################################
def my_askopenfilename(self): # объекты запоминают каталог/файл if not self.openDialog: # последней операции
self.openDialog = Open(initialdir=self.startfiledir, filetypes=self.ftypes) return self.openDialog.show()
def my_asksaveasfilename(self): # объекты запоминают каталог/файл if not self.saveDialog: # последней операции
self.saveDialog = SaveAs(initialdir=self.startfiledir, filetypes=self.ftypes)
return self.saveDialog.show()
def onOpen(self, loadFirst=’’, loadEncode=’’):
2.1: полностью переписан для поддержки Юникода; открывает в текстовом режиме с кодировкой, переданной в аргументе, введенной пользователем, заданной в модуле textconfig или с кодировкой по умолчанию; в крайнем случае открывает файл в двоичном режиме и отбрасывает символы \r в Windows, если они присутствуют, чтобы обеспечить нормальное отображение текста; содержимое извлекается и возвращается в виде строки str, поэтому при сохранении его требуется кодировать: сохраняет кодировку, используемую здесь;
предварительно проверяет возможность открытия файла; мы могли бы также вручную загружать и декодировать bytes в str, чтобы избежать необходимости выполнять несколько попыток открытия, но этот прием подходит не для всех случаев;
порядок выбора кодировки настраивается в локальном textConfig.py:
1) сначала применяется кодировка, переданная клиентом (например, кодировка из заголовка сообщения электронной почты)
2) затем, если opensAskUser возвращает True, применяется кодировка, введенная пользователем (предварительно в диалог записывается кодировка по умолчанию)
3) затем, если opensEncoding содержит непустую строку, применяется эта кодировка: ‘latin-1’ и так далее.
4) затем выполняется попытка применить кодировку sys.getdefaultencoding()
5) в крайнем случае выполняется чтение в двоичном режиме и используется алгоритм, заложенный в библиотеку Tk
if self.text_edit_modified(): # 2.0
if not askyesno(‘PyEdit’, ‘Text has changed: discard changes?’): return
file = loadFirst or self.my_askopenfilename() if not file: return
if not os.path.isfile(file):
showerror(‘PyEdit’, ‘Could not open file ‘ + file) return
# применить известную кодировку, если указана
# (например, из заголовка сообщения электронной почты)
text = None # пустой файл = ‘’ = False: проверка на None! if loadEncode: try:
text = open(file, ‘r’, encoding=loadEncode).read() self.knownEncoding = loadEncode except (UnicodeError, LookupError, IOError): # Lookup: ошибка pass # в имени
# применить кодировку, введенную пользователем,
# предварительно записать в диалог следующий вариант, как значение
# по умолчанию
if text == None and self.opensAskUser:
self.update() # иначе в некоторых случаях диалог не появится askuser = askstring(‘PyEdit’, ‘Enter Unicode encoding for open’, initialvalue=(self.opensEncoding or
sys.getdefaultencoding() or ''))
if askuser: try:
text = open(file, ‘r’, encoding=askuser).read() self.knownEncoding = askuser except (UnicodeError, LookupError, IOError): pass
# применить кодировку из файла с настройками (может быть, выполнять
# эту попытку до того, как запрашивать кодировку у пользователя?) if text == None and self.opensEncoding:
try:
text = open(file, ‘r’, encoding=self.opensEncoding).read() self.knownEncoding = self.opensEncoding except (UnicodeError, LookupError, IOError): pass
# применить системную кодировку по умолчанию (utf-8 в windows;
# всегда пытаться использовать utf8?) if text == None:
try:
text = open(file, ‘r’,
encoding=sys.getdefaultencoding()).read() self.knownEncoding = sys.getdefaultencoding() except (UnicodeError, LookupError, IOError): pass
# крайний случай: использовать двоичный режим и положиться на
# возможности Tk if text == None:
try:
text = open(file, ‘rb’).read() # строка bytes text = text.replace(b’\r\n’, b’\n’) # для отображения self.knownEncoding = None # и последующего сохранения
except IOError: pass
if text == None:
showerror(‘PyEdit’, ‘Could not decode and open file ‘ + file) else:
self.setAllText(text)
self.setFileName(file)
self.text.edit_reset() # 2.0: очистка стеков undo/redo self.text.edit_modified(0) # 2.0: сбросить флаг наличия изменений
def onSave(self):
self.onSaveAs(self.currfile) # may be None
def onSaveAs(self, forcefile=None):
2.1: полностью переписан для поддержки Юникода: виджет Text всегда возвращает содержимое в виде строки str, поэтому нам необходимо побеспокоиться о кодировке, чтобы сохранить файл, независимо от режима, в котором открывается выходной файл (для двоичного режима необходимо будет получить bytes, а для текстового необходимо указать кодировку); пытается применить кодировку, использовавшуюся при открытии или сохранении (если известна), предлагаемую пользователем, указанную в файле с настройками, и системную кодировку по умолчанию; в большинстве случаев можно использовать системную кодировку по умолчанию;
в случае успешного выполнения операции сохраняет кодировку для использования в дальнейшем, потому что это может быть первая операция Save после операции New или вставки текста вручную; в файле с настройками можно определить, чтобы обе операции, Save и Save As, использовали последнюю известную кодировку (однако если для операции Save это оправданно, то в случае с операцией Save As это не так очевидно); графический интерфейс предварительно записывает эту кодировку в диалог, если она известна;
выполняет text.encode() вручную, чтобы избежать создания файла; для текстовых файлов автоматически выполняется преобразование символов конца строки: в Windows добавляются символы \r, отброшенные при открытии файла в текстовом (автоматически) или в двоичном (вручную) режиме; Если содержимое вставлялось вручную, здесь необходимо предварительно удалить символы \r, иначе они будут продублированы; knownEncoding=None перед первой операцией Open или Save, после New и если операция Open открыла файл в двоичном режиме;
порядок выбора кодировки настраивается в локальном textConfig.py:
1) если savesUseKnownEncoding > 0, применить кодировку, использованную в последней операции Open или Save
2) если savesAskUser = True, применить кодировку, указанную пользователем (предлагать известную в качестве значения по умолчанию?)
3) если savesEncoding - непустая строка, применить эту кодировку: ‘utf-8’ и так далее
4) в крайнем случае применить sys.getdefaultencoding()
filename = forcefile or self.my_asksaveasfilename() if not filename: return
text = self.getAllText() # 2.1: строка str, без символов \r, encpick = None # даже если текст читался/вставлялся
# в двоичном виде
# применить известную кодировку, использовавшуюся в последней операции
# Open или Save, если известна
if self.knownEncoding and ( # известна?
(forcefile and self.savesUseKnownEncoding >= 1) or # для Save? (not forcefile and self.savesUseKnownEncoding >= 2)):# для SaveAs? try:
text.encode(self.knownEncoding) encpick = self.knownEncoding except UnicodeError: pass
# применить кодировку, введенную пользователем,
# предварительно записать в диалог следующий вариант, как значение
# по умолчанию
if not encpick and self.savesAskUser:
self.update()# иначе в некоторых случаях диалог не появится askuser = askstring(‘PyEdit’, ‘Enter Unicode encoding for save’, initialvalue=(self.knownEncoding or self.savesEncoding or sys.getdefaultencoding() or ''))
if askuser: try:
text.encode(askuser) encpick = askuser
except (UnicodeError, LookupError): # LookupError: ошибка в имени pass # UnicodeError: ошибка
# кодирования
# применить кодировку из файла с настройками if not encpick and self.savesEncoding:
try:
text.encode(self.savesEncoding) encpick = self.savesEncoding except (UnicodeError, LookupError): pass
# применить системную кодировку по умолчанию (utf8 в windows) if not encpick:
try:
text.encode(sys.getdefaultencoding()) encpick = sys.getdefaultencoding() except (UnicodeError, LookupError): pass
# открыть в текстовом режиме, чтобы автоматически выполнить
# преобразование символов конца строки и применить кодировку if not encpick:
showerror(‘PyEdit’, ‘Could not encode for file ‘ + filename) else: try:
file = open(filename, ‘w’, encoding=encpick) file.write(text) file.close() except:
showerror(‘PyEdit’, ‘Could not write file ‘ + filename) else:
self.setFileName(filename) # может быть вновь созданным self.text.edit_modified(0) # 2.0: сбросить флаг изменений self.knownEncoding = encpick # 2.1: запомнить кодировку
# не сбрасывать стеки undo/redo!
def onNew(self):
запускает редактирование совершенно нового файла в текущем окне; смотрите метод onClone, который вместо этого создает независимое окно редактирования;
if self.text_edit_modified(): # 2.0
if not askyesno(‘PyEdit’, ‘Text has changed: discard changes?’): return
self.setFileName(None)
self.clearAllText()
self.text.edit_reset() # 2.0: очистить стеки undo/redo self.text.edit_modified(0) # 2.0: сбросить флаг наличия изменений self.knownEncoding = None # 2.1: кодировка неизвестна
def onQuit(self):
вызывается выбором операции Quit в меню/панели инструментов и щелчком на кнопке X в заголовке окна;
2.1: не завершать приложение при наличии несохраненных изменений;
2.0: не выводить запрос на подтверждение, если нет изменений в self; перемещен в классы окон верхнего уровня ниже, так как его реализация может зависеть от особенностей использования: операция Quit в графическом интерфейсе может вызывать метод quit() для завершения, destroy() - чтобы просто закрыть окно Toplevel, Tk или фрейм с редактором, эта операция может даже вообще не предоставляться, если редактор присоединяется, как компонент; проверяет self на наличие несохраненных изменений, а если предполагается вызов метода quit(), главные окна должны также проверить наличие несохраненных изменений в других окнах, присутствующих в глобальном списке процесса;
assert False, ‘onQuit must be defined in window-specific sublass’
def text_edit_modified(self):
2.1: теперь действует! кажется, проблема заключалась в типе bool результата в tkinter;
2.0: self.text.edit_modified() не работает в Python 2.4: выполнить проверку вручную;
return self.text.edit_modified()
#return self.tk.call((self.text._w, ‘edit’) + (‘modified’, None))
##########################################################################
# Операции меню Edit
##########################################################################
def onUndo(self): # 2.0
try: # tk8.4 поддерживает стеки undo/redo
self.text.edit_undo() # возбуждает исключение, если стеки пустые except TclError: # меню открывается для быстрого доступа
showinfo(‘PyEdit’, ‘Nothing to undo’) # к операциям
def onRedo(self): # 2.0: возврат отмененной операции
try: # редактирования
self.text.edit_redo() except TclError:
showinfo(‘PyEdit’, ‘Nothing to redo’)
def onCopy(self): # получить текст, выделенный мышью
if not self.text.tag_ranges(SEL): # сохранить в системном буфере showerror(‘PyEdit’, ‘No text selected’) else:
text = self.text.get(SEL_FIRST, SEL_LAST)
self.clipboard_clear()
self.clipboard_append(text)
def onDelete(self): # удалить выделенный текст без сохранения
if not self.text.tag_ranges(SEL):
showerror(‘PyEdit’, ‘No text selected’) else:
self.text.delete(SEL_FIRST, SEL_LAST)
def onCut(self):
if not self.text.tag_ranges(SEL):
showerror(‘PyEdit’, ‘No text selected’) else:
self.onCopy() # сохранить и удалить выделенный текст
self.onDelete()
def onPaste(self): try:
text = self.selection_get(selection=’CLIPBOARD’) except TclError:
showerror(‘PyEdit’, ‘Nothing to paste’) return
self.text.insert(INSERT, text) # вставить в текущую позицию курсора self.text.tag_remove(SEL, ‘1.0’, END) self.text.tag_add(SEL, INSERT+’-%dc’ % len(text), INSERT) self.text.see(INSERT) # выделить, чтобы можно было вырезать
def onSelectAll(self):
self.text.tag_add(SEL, ‘1.0’, END+’-1c’)# выделить весь текст self.text.mark_set(INSERT, ‘1.0’) # переместить позицию в начало
self.text.see(INSERT) # прокрутить в начало
##########################################################################
# Операции меню Search
##########################################################################
def onGoto(self, forceline=None):
line = forceline or askinteger(‘PyEdit’, ‘Enter line number’)
self.text.update()
self.text.focus()
if line is not None:
maxindex = self.text.index(END+’-1c’) maxline = int(maxindex.split(‘.’)[0]) if line > 0 and line <= maxline:
self.text.mark_set(INSERT, ‘%d.0’ % line) # перейти к стр.
self.text.tag_remove(SEL, ‘1.0’, END) # снять выделен.
self.text.tag_add(SEL, INSERT, ‘insert + 1l’) # выделить стр.
self.text.see(INSERT) # прокрутить
else: # до строки
showerror(‘PyEdit’, ‘Bad line number’)
def onFind(self, lastkey=None):
key = lastkey or askstring(‘PyEdit’, ‘Enter search string’) self.text.update()
self.text.focus() self.lastfind = key
if key: # 2.0: без учета регистра символов
nocase = configs.get(‘caseinsens’, True) # 2.0: настройки where = self.text.search(key, INSERT, END, nocase=nocase) if not where: # не переходить
showerror(‘PyEdit’, ‘String not found’)# в начало else:
pastkey = where + ‘+%dc’ % len(key) # позиция после ключа self.text.tag_remove(SEL, ‘1.0’, END) # снять выделение self.text.tag_add(SEL, where, pastkey) # выделить ключ self.text.mark_set(INSERT, pastkey) # для след. поиска self.text.see(where) # прокрутить экран
def onRefind(self):
self.onFind(self.lastfind)
def onChange(self):
немодальный диалог поиска с заменой
2.1: поля ввода диалога передаются обработчику, допускается открывать одновременно несколько диалогов поиска с заменой
new = Toplevel(self) new.title(‘PyEdit - change’)
Label(new, text=’Find text?’, relief=RIDGE, width=15).grid(row=0,
column=0)
Label(new, text=’Change to?’, relief=RIDGE, width=15).grid(row=1,
column=0)
entry1 = Entry(new) entry2 = Entry(new)
entry1.grid(row=0, column=1, sticky=EW) entry2.grid(row=1, column=1, sticky=EW)
def onFind(): # использует поле ввода из внешней обл. видимости
self.onFind(entry1.get()) # вызов обработчика диалога поиска
def onApply():
self.onDoChange(entry1.get(), entry2.get())
Button(new, text=’Find’, command=onFind ).grid(row=0,
column=2, sticky=EW)
Button(new, text=’Apply’, command=onApply).grid(row=1,
column=2, sticky=EW)
new.columnconfigure(1, weight=1) # растягиваемые поля ввода
def onDoChange(self, findtext, changeto):
# реализует замену для диалога поиска с заменой:
# заменяет и повторяет поиск
if self.text.tag_ranges(SEL): # сначала найти
self.text.delete(SEL_FIRST, SEL_LAST) self.text.insert(INSERT, changeto) # удалит, если пусто self.text.see(INSERT)
self.onFind(findtext) # переход к следующему
self.text.update() # принудительное обновление
def onGrep(self):
новое в версии 2.1: многопоточная реализация поиска во внешних файлах; выполняет поиск указанной строки в файлах, имена которых соответствуют заданному шаблону; щелчок на элементе в списке открывает соответствующий файл, при этом выполняется переход к строке с найденным вхождением;
поиск выполняется в отдельном потоке, чтобы графический интерфейс не блокировался и оставался активным и чтобы позволить одновременно выполнять несколько операций поиска; можно было бы использовать модуль, если прекращать цикл проверки при отсутствии активных операций поиска;
алгоритм выбора кодировки при выполнении поиска: содержимое текстовых файлов в дереве, где выполняется поиск, может храниться в любых кодировках: мы не предлагаем вводить имя кодировки для каждого файла (как при открытии), однако позволяем указать кодировку для всего дерева, предварительно устанавливая общесистемную кодировку по умолчанию, используемую файловой системой или для представления текста, и пропускаем файлы, декодирование которых терпит неудачу; в самом тяжелом случае пользователю может потребоваться выполнить поиск N раз, если в дереве могут присутствовать файлы с текстом в N различных кодировках; иначе операция открытия будет возбуждать исключение, а открытие в двоичном режиме может не дать совпадения кодированного текста с испытуемой строкой;
TBD: может, лучше было бы выводить сообщение об ошибке при встрече с файлом, который не удалось декодировать?
но файлы с кодировкой utf-16 (2 байта на символ), созданные в Notepad, благополучно могут декодироваться с применением кодировки utf-8, однако строка при этом не будет найдена;
TBD: можно было бы позволить вводить несколько имен кодировок, отделяя их друг от друга запятыми, и пробовать применять их поочередно к каждому файлу, помимо loadEncode
from PP4E.Gui.ShellGui.formrows import makeFormRow
# немодальный диалог: ввод имени каталога, шаблон имени файла,
# искомая строка popup = Toplevel() popup.title(‘PyEdit - grep’)
var1 = makeFormRow(popup, label=’Directory root’, width=18, browse=False)
var2 = makeFormRow(popup, label=’Filename pattern’, width=18, browse=False)
var3 = makeFormRow(popup, label=’Search string’, width=18, browse=False)
var4 = makeFormRow(popup, label=’Content encoding’, width=18, browse=False)
var1.set(‘.’) # текущий каталог
var2.set(‘*.py’) # начальные значения
var4.set(sys.getdefaultencoding()) # для содержимого файлов, а не имен cb = lambda: self.onDoGrep(var1.get(), var2.get(), var3.get(),
var4.get())
Button(popup, text=’Go’,command=cb).pack()
def onDoGrep(self, dirname, filenamepatt, grepkey, encoding):
вызывается щелчком на кнопке Go в диалоге Grep: заполняет список найденными совпадениями
tbd: возможно, следует запускать поток-производитель как демон, чтобы он автоматически завершался вместе с приложением?
import threading, queue
# создать немодальный и незакрываемый диалог mypopup = Tk()
mypopup.title(‘PyEdit - grepping’) status = Label(mypopup,
text=’Grep thread searching for: %r...’ % grepkey) status.pack(padx=20, pady=20)
mypopup.protocol(‘WM_DELETE_WINDOW’, lambda: None) # игнорировать
# кнопку X
# запустить поток-производитель, цикл проверки результатов myqueue = queue.Queue()
threadargs = (filenamepatt, dirname, grepkey, encoding, myqueue) threading.Thread(target=self.grepThreadProducer, args=threadargs).start()
self.grepThreadConsumer(grepkey, encoding, myqueue, mypopup)
def grepThreadProducer(self, filenamepatt, dirname, grepkey, encoding, myqueue):
выполняется в параллельном потоке, не имеющем отношения к графическому интерфейсу: помещает в очередь список с результатами find.find; найденные совпадения можно было бы помещать в очередь по мере их обнаружения, но для этого необходимо обеспечить сохранение окна на экране; здесь могут возникать ошибки декодирования не только содержимого, но и имен файлов;
TBD: чтобы избежать ошибок декодирования имен файлов в os.walk/listdir, можно было бы передавать методу find() строку bytes, но какую кодировку использовать: sys.getfilesystemencoding(), если она не равна None? Смотрите также примечание в разделе "Модуль fnmatch” в главе 6: в версии 3.1 модуль fnmatch всегда преобразует текст в двоичное представление, используя кодировку Latin-1;
from PP4E.Tools.find import find
matches = [] try:
for filepath in find(pattern=filenamepatt, startdir=dirname): try:
textfile = open(filepath, encoding=encoding) for (linenum, linestr) in enumerate(textfile): if grepkey in linestr:
msg = ‘%s@%d [%s]’ % (filepath,
linenum + 1, linestr)
matches.append(msg)
except UnicodeError as X: # напр.: декодир.
print(‘Unicode error in:’, filepath, X) # двоичный режим except IOError as X:
print(‘IO error in:’, filepath, X) # напр.: права доступа
finally:
myqueue.put(matches) # остановить цикл потребителя при исключении # имена файлов?
def grepThreadConsumer(self, grepkey, encoding, myqueue, mypopup):
выполняется в главном потоке графического интерфейса: просматривает очередь в ожидании результатов или []; может иметься несколько активных потоков/циклов/очередей, связанных с поиском; в процессе могут присутствовать другие типы потоков/циклов проверки, особенно если PyEdit прикрепляется как компонент (PyMailGUI);
import queue try:
matches = myqueue.get(block=False) except queue.Empty:
myargs = (grepkey, encoding, myqueue, mypopup) self.after(250, self.grepThreadConsumer, *myargs) else:
mypopup.destroy() # закрыть информационный диалог self.update() # и стереть его с экрана if not matches:
showinfo(‘PyEdit’, ‘Grep found no matches for: %r’ % grepkey) else:
self.grepMatchesList(matches, grepkey, encoding)
def grepMatchesList(self, matches, grepkey, encoding):
заполняет список найденными совпадениями в случае успеха; так как поиск увенчался успехом, кодировка уже известна: использовать ее в обработчике щелчка на файле в списке, чтобы обеспечить его открытие без обращения к пользователю;
from PP4E.Gui.Tour.scrolledlist import ScrolledList print(‘Matches for %s: %s’ % (grepkey, len(matches)))
# перехватывает двойной щелчок на списке class ScrolledFilenames(ScrolledList):
def runCommand(self, selection):
file, line = selection.split(‘ [‘, 1)[0].split(‘@’) editor = TextEditorMainPopup(
loadFirst=file, winTitle=’ grep match’, loadEncode=encoding) editor.onGoto(int(line))
editor.text.focus_force() # на самом деле не требуется
# новое модальное окно popup = Tk()
popup.title(‘PyEdit - grep matches: %r (%s)’ % (grepkey, encoding)) ScrolledFilenames(parent=popup, options=matches)
##########################################################################
# Операции меню Tools
##########################################################################
def onFontList(self):
self.fonts.append(self.fonts[0]) # выбрать следующий шрифт в списке del self.fonts[0] # изменит размер текстовой области
self.text.config(font=self.fonts[0])
def onColorList(self):
self.colors.append(self.colors[0]) # выбрать следующий цвет в списке del self.colors[0] # текущий сместить в конец
self.text.config(fg=self.colors[0][‘fg’], bg=self.colors[0][‘bg’])
def onPickFg(self):
self.pickColor(‘fg’) # добавлено 10/02/00
def onPickBg(self): # выбрать произвольный цвет
self.pickColor(‘bg’) # в стандартном диалоге выбора цвета
def pickColor(self, part): # это очень просто (triple, hexstr) = askcolor() if hexstr:
self.text.config(**{part: hexstr}) def onInfo(self):
диалог с информацией о тексте и о местоположении курсора;
ВНИМАНИЕ (2.1): при вычислении позиции курсора библиотека Tk считает символ табуляции, как один символ: следует умножать их на 8, чтобы обеспечить соответствие с визуальным положением?
text = self.getAllText() # добавлено 5/3/00 за 15 мин.
bytes = len(text) # словами считается все, что
lines = len(text.split(‘\n’)) # отделяется пробелами
words = len(text.split()) # 3.x: в bytes - символы
index = self.text.index(INSERT) # в str - кодовые пункты Юникода
where = tuple(index.split(‘.’)) showinfo(‘PyEdit Information’,
‘Current location:\n\n’ +
‘line:\t%s\ncolumn:\t%s\n\n' % where +
‘File text statistics:\n\n’ +
‘chars:\t%d\nlines:\t%d\nwords:\t%d\n’ % (bytes, lines,
words))
def onClone(self, makewindow=True):
открывает новое окно редактора, не изменяя уже открытое (onNew); наследует поведение операции Quit и других от окна, копия которого создается;
2.1: подклассы должны переопределять/замещать этот метод, если будут создавать собственные окна,
иначе этот метод создаст дополнительное поддельное пустое окно; if not makewindow:
new = None # предполагается, что класс создает
else: # собственное окно
new = Toplevel() # новое окно редактора в том же процессе
myclass = self.__class__ # объект класса экземпляра (самый нижний)
myclass(new) # прикрепить/запустить экземпляр моего класса
def onRunCode(self, parallelmode=True):
выполнение редактируемого программного кода Python -- это не IDE, но удобно; пытается выполнить в каталоге файла, не в cwd (может быть корнем PP4E); вводит и добавляет аргументы командной строки для файлов сценариев;
stdin/out/err для программного кода = стартовое окно редактора, если оно есть: запускайте редактор в окне консоли, чтобы увидеть вывод, производимый программным кодом; если parallelmode=True, открывает окно DOS для операций ввода-вывода; путь поиска модулей будет включать ‘.’ при запуске; при выполнении программного кода как отдельной строки корневым окном может быть окно PyEdit; здесь также можно использовать модули subprocess и multiprocessing;
2.1: исправлено на использование базового имени файла после chdir, без пути;
2.1: использует StartArgs для передачи аргументов в режиме запуска файлов в Windows;
2.1: вызывает update() после первого диалога, в противном случае второй диалог иногда не появляется на экране;
def askcmdargs():
return askstring(‘PyEdit’, ‘Commandline arguments?’) or ''
from PP4E.launchmodes import System, Start, StartArgs, Fork filemode = False
thefile = str(self.getFileName()) if os.path.exists(thefile):
filemode = askyesno(‘PyEdit’, ‘Run from file?’) self.update() # 2.1: вызывает update()
if not filemode: # выполнить как строку
cmdargs = askcmdargs()
namespace = {‘__name__’: ‘__main__’} # выполнить как сценарий
sys.argv = [thefile] + cmdargs.split() # можно использов. потоки
exec(self.getAllText() + ‘\n’, namespace)# игнорировать исключения
elif self.text_edit_modified(): # 2.0: проверка изменений
showerror(‘PyEdit’, ‘Text changed: you must save before run’) else:
cmdargs = askcmdargs()
mycwd = os.getcwd() # cwd может быть корнем
dirname, filename = os.path.split(thefile) # каталог, базовое имя
os.chdir(dirname or mycwd) # cd для файлов
thecmd = filename + ‘ ‘ + cmdargs # 2.1: не theFile
if not parallelmode: # выполнить как файл
System(thecmd, thecmd)() # блокировать редактор
else:
if sys.platform[:3] == ‘win’: # породить параллельно
run = StartArgs if cmdargs else Start # 2.1: аргументы run(thecmd, thecmd)() # или всегда Spawn
else:
Fork(thecmd, thecmd)() # породить параллельно
os.chdir(mycwd) # вернуться в каталог
def onPickFont(self):
2.0 немодальный диалог выбора шрифта
2.1: поля ввода диалога передаются обработчику, допускается открывать одновременно несколько диалогов поиска выбора шрифта
from PP4E.Gui.ShellGui.formrows import makeFormRow popup = Toplevel(self) popup.title(‘PyEdit - font’)
var1 = makeFormRow(popup, label=’Family’, browse=False) var2 = makeFormRow(popup, label=’Size’, browse=False) var3 = makeFormRow(popup, label=’Style’, browse=False) var1.set(‘courier’)
var2.set(‘12’) # предлагаемые значения
var3.set(‘bold italic’) # смотрите допустимые значения в списке выбора Button(popup, text=’Apply’, command=
lambda: self.onDoFont(var1.get(), var2.get(), var3.get())).pack()
def onDoFont(self, family, size, style): try:
self.text.config(font=(family, int(size), style)) except:
showerror(‘PyEdit’, ‘Bad font specification’)
##############################################################################
# Готовые к употреблению классы редактора, подмешиваемые в подкласс
# фрейма GuiMaker, создающий меню и панели инструментов.
#
# Эти классы реализуют типичные случаи использования, однако возможны и другие
# реализации; для запуска PyEdit, как самостоятельной программы, следует
# вызвать метод TextEditorMain().mainloop(); переопределяйте/расширяйте
# в подклассах метод onQuit, чтобы обеспечить перехват события завершения
# приложения или уничтожения окна (смотрите пример PyView);
# ВНИМАНИЕ: можно было бы использовать windows.py для создания ярлыков,
# но здесь используется собственный протокол завершения. ##############################################################################
# -----------------------------------------------------------------------------
# 2.1: в quit(), не завершать без предупреждения, если в процессе открыты
# другие окна редактора и в них имеются несохраненные изменения - изменения
# будут потеряны, потому что все остальные окна тоже закрываются, включая
# множественные родительские окна Tk, включающие редактор; для слежения за
# всеми окнами PyEdit используется список экземпляров, созданных в процессе;
# это может оказаться чрезмерной мерой (если вместо quit() вызывается
# destroy(), когда достаточно проверить только дочернее окно редактирования
# уничтожаемого родителя), но лучше перестраховаться; метод onQuit перемещен
# сюда, потому что его реализация отличается для окон разных типов и может
# присутствовать не во всех окнах;
#
# предполагается, что TextEditorMainPopup никогда не будет играть роль
# родителя для других окон редактирования - дочерние виджеты Toplevel
# уничтожаются вместе со своими родителями; это не позволяет предотвратить
# закрытие из-за пределов классов PyEdit (метод quit в tkinter доступен
# во всех виджетах, и любой виджет может быть родителем для Toplevel!);
# ответственность за проверку наличия изменений в содержимом редактора
# полностью возлагается на клиента; обратите внимание, что в данной ситуации
# привязка события не даст ровным счетом ничего, потому что его
# обработчик не может выполнять операции с графическим интерфейсом, такие как
# проверка наличия изменений и извлечение текста, - дополнительную информацию
# об этом событии смотрите в книге и в модуле destroyer.py;
# -----------------------------------------------------------------------------
########################################
# когда текстовый редактор владеет окном ########################################
class TextEditorMain(TextEditor, GuiMakerWindowMenu):
главное окно редактора PyEdit, которое вызывает метод quit() при выполнении операции Quit графического интерфейса для завершения приложения и конструирует меню в окне; родителем может быть окно Tk, по умолчанию, окно Tk, создаваемое явно, или объект Toplevel: родитель должен быть окном и, вероятно, окном Tk, чтобы избежать закрытия без предупреждения вместе с родителем; при выполнении операции Quit графического интерфейса все главные окна PyEdit проверяют остальные окна
def __init__(self, parent=None, loadFirst=’’, winTitle=’’, loadEncode=’’):
# создать собственное окно self.popup = Toplevel(parent)
GuiMaker.__init__(self, self.popup) # использует главное меню окна
TextEditor.__init__(self, loadFirst, loadEncode) # фрейм в новом окне
assert self.master == self.popup self.popup.title(‘PyEdit ‘ + Version + winTitle) self.popup.iconname(‘PyEdit’)
self.popup.protocol(‘WM_DELETE_WINDOW’, self.onQuit) TextEditor.editwindows.append(self)
def onQuit(self):
close = not self.text_edit_modified() if not close:
close = askyesno(‘PyEdit’,
‘Text changed: quit and discard changes?’)
if close:
self.popup.destroy() # закрыть только это окно
TextEditor.editwindows.remove(self) # (и все дочерние окна)
def onClone(self):
TextEditor.onClone(self, makewindow=False) # я создаю собственное окно
###########################################
# когда редактор встраивается в другое окно ###########################################
class TextEditorComponent(TextEditor, GuiMakerFrameMenu):
прикрепляемый фрейм компонента PyEdit с полными меню/панелью инструментов, который вызывает destroy() при выполнении операции Quit графического интерфейса и стирает только себя; при выполнении операции Quit проверяется наличие несохраненных изменений только в этом редакторе; не перехватывает щелчок на кнопке X в заголовке окна: не имеет собственного окна; не добавляет себя в список отслеживаемых окон: является частью более крупного приложения;
def __init__(self, parent=None, loadFirst=’’, loadEncode=’’):
# использовать меню на основе фрейма
GuiMaker.__init__(self, parent) # все меню, кнопки в GuiMaker должны TextEditor.__init__(self, loadFirst, loadEncode) # создаваться первыми
def onQuit(self):
close = not self.text_edit_modified() if not close:
close = askyesno(‘PyEdit’,
‘Text changed: quit and discard changes?’)
if close:
self.destroy() # стереть свой фрейм, но не завершать вмещающее # приложение
class TextEditorComponentMinimal(TextEditor, GuiMakerFrameMenu):
прикрепляемый фрейм компонента PyEdit без операции Quit и без меню File; на запуске удаляет кнопку Quit из панели инструментов и удаляет меню File или запрещает все его пункты (грубовато, зато эффективно); структуры меню и панели инструментов являются данными экземпляра: изменение их не затрагивает другие экземпляры;
Операция Quit графического интерфейса никогда не запускается, потому что она удаляется из доступных операций;
def __init__(self, parent=None, loadFirst=’’,
deleteFile=True, loadEncode=’’): self.deleteFile = deleteFile
GuiMaker.__init__(self, parent) # фрейм GuiMaker прикрепляет себя сам
TextEditor.__init__(self, loadFirst, loadEncode) # TextEditor
# добавляется
# в середину
def start(self):
TextEditor.start(self) # вызов метода start GuiMaker
for i in range(len(self.toolBar)): # удалить quit из панели инстр. if self.toolBar[i][0] == ‘Quit’: # удалить пункты меню file del self.toolBar[i] # или просто запретить их
break
if self.deleteFile:
for i in range(len(self.menuBar)): if self.menuBar[i][0] == ‘File’: del self.menuBar[i] break
else:
for (name, key, items) in self.menuBar: if name == ‘File’:
items.append([1,2,3,4,6])
##############################################################################
# запуск как самостоятельной программы
##############################################################################
def testPopup():
# проверку запуска как компонента смотрите в PyView и PyMail root = Tk()
TextEditorMainPopup(root)
TextEditorMainPopup(root)
Button(root, text=’More’, command=TextEditorMainPopup).pack(fill=X) Button(root, text=’Quit’, command=root.quit).pack(fill=X) root.mainloop()
def main(): # из командной строки или щелчком
try: # либо как ассоциированная программа в Windows
fname = sys.argv[1] # аргумент = необязательное имя файла except IndexError: # создается в корневом окне Tk по умолчанию
fname = None
TextEditorMain(loadFirst=fname).pack(expand=YES, fill=BOTH)# pack -mainloop() # необязательно
if __name__ == ‘__main__’: # когда запускается как сценарий
#testPopup()
main() # используйте .pyw, чтобы запустить без окна DOS
PyPhoto: программа просмотра и изменения размеров изображений
В главе 9 мы написали простую программу просмотра миниатюр изображений, реализующую прокрутку коллекции миниатюр в холсте. Эта программа в свою очередь была основана на приемах и программном коде для работы с изображениями, разработанных в конце главы 8. В обоих случаях я обещал, что мы в конечном счете встретимся с более полнофункциональным воплощением рассматривавшихся идей.
В этом разделе мы наконец завершим обсуждение миниатюр изображений знакомством с PyPhoto - улучшенной программой просмотра и изменения размеров изображений. Основу программы PyPhoto составляют простые операции: для заданного каталога с изображениями PyPhoto отображает их миниатюры в холсте с прокруткой. При выборе миниатюры отображается соответствующее ей полноразмерное изображение во всплывающем окне.
В отличие от предыдущих программ просмотра изображений, PyPhoto предусматривает возможность прокрутки изображения (вместо обрезания), если оно оказывается больше физического экрана. Кроме того, программа PyPhoto вводит понятие изменения размеров изображения -она поддерживает события от мыши и клавиатуры, которые изменяют размер изображения по одной из осей и увеличивают или уменьшают масштаб изображения. После того как изображение открыто, логика изменения размеров позволяет растягивать и сжимать изображение до произвольных размеров, что особенно удобно при просмотре цифровых фотографий, которые могут быть слишком большими, чтобы их можно было просмотреть целиком.
Кроме того, PyPhoto позволяет сохранять изображения в файлах (возможно, после изменения размеров) и дает возможность выбирать и открывать каталоги с изображениями в самом графическом интерфейсе, а не только с помощью аргументов командной строки.
Все вместе особенности PyPhoto образуют программу обработки изображений, хотя и с небольшим, по современным меркам, количеством инструментов. Я предлагаю вам самим попробовать добавить в нее новые возможности - после овладения навыками работы с прикладным интерфейсом библиотеки Python Imaging Library (PIL) объектноориентированная природа PyPhoto делает добавление новых инструментов удивительно простым делом.
Запуск PyPhoto
Чтобы запустить PyPhoto, необходимо получить и установить пакет расширения PIL, описанный в главе 8. Программа PyPhoto использует многие функциональные возможности PIL; эта библиотека поддерживает дополнительные форматы изображений, помимо тех, что поддерживаются стандартной библиотекой tkinter (например, изображений JPEG), и используется для выполнения операций над изображениями, таких как изменение размеров, создание миниатюр и сохранение в файлах. Расширение PIL распространяется с открытыми исходными текстами, как и Python, но в настоящее время оно не является частью стандартной библиотеки Python. Ищите PIL в Интернете (в настоящее время самый точный адрес: http://www.pythonware.com). Проверьте также каталог Extensions в дереве примеров, где находится самоустанавливающийся пакет PIL.
Самый лучший способ получить представление о программе PyPhoto -запустить ее у себя на компьютере и посмотреть, как она выполняет прокрутку изображений и изменение их размеров. Ниже будет представлено несколько снимков с экрана, дающих общее представление о взаимодействии с программой. Запустить PyPhoto можно щелчком на ее ярлыке или из командной строки. При непосредственном запуске программа открывает подкаталог images в исходном каталоге, который содержит несколько фотографий. При запуске из командной строки программе можно передать имя начального каталога в виде аргумента. На рис. 11.7 изображено главное окно с миниатюрами, которое выводится при непосредственном запуске программы.
Прежде чем появится это окно, PyPhoto загружает или создает миниатюры, используя инструменты, реализованные в главе 8. Если каталог с изображениями открывается впервые, запуск программы может занять несколько секунд, но все последующие запуски будут протекать быстро - PyPhoto кэширует миниатюры в локальном подкаталоге, чтобы можно было пропустить этап создания миниатюр, когда этот же каталог будет открыт в следующий раз.
Технически, существует три разных варианта поведения PyPhoto при запуске: она отображает содержимое определенного каталога, указанного в командной строке; отображает содержимое каталога images по умолчанию при запуске без аргументов командной строки и когда каталог images находится в каталоге запуска программы; или отображает единственную кнопку, после щелчка на которой предоставляется возможность выбрать и открыть каталог для просмотра, когда начальный каталог не указан или отсутствует (смотрите логику работы раздела __main__).
Рис. 11.7. Главное окно PyPhoto, каталог по умолчанию
Программа PyPhoto позволяет также открывать дополнительные папки в новых окнах с миниатюрами, для чего достаточно нажать клавишу D в окне с миниатюрами или в окне с изображением. Например, на рис. 11.8 показан диалог выбора новой папки с изображениями в Windows 7, а на рис. 11.9 показан результат того, что я открыл каталог, куда были скопированы фотографии с карты памяти моей цифровой фотокамеры, - это второе окно PyPhoto с миниатюрами на экране. Окно, изображенное на рис. 11.8, также открывается из окна с единственной кнопкой, если при запуске программе не указать начальный каталог или если этот каталог недоступен.
После выбора миниатюры на экране появляется новое окно, где в холсте отображается соответствующее изображение. Если изображение оказывается слишком большим для экрана, его можно будет прокрутить с помощью полос прокрутки в окне. На рис. 11.10 показано изображение, которое было выведено после щелчка на миниатюре, а на рис. 11.11 - диалог Save As, запущенный нажатием клавиши S в окне с изображением. В этом диалоге Save As необходимо ввести требуемое
Рис. 11.9. Окно PyPhoto с миниатюрами, другой каталог
Рис. 11.10. Окно PyPhoto для просмотра изображения
Рис. 11.11. Диалог Save As программы PyPhoto (клавиша S; включает расширение)
расширение имени файла (например, .jpg), потому что расширение PIL использует его, чтобы определить, в каком формате сохранять изображение в файле. В целом, программа PyPhoto позволяет открывать любое количество окон с миниатюрами и с полноразмерными изображениями, и каждое изображение может сохраняться независимо от других.
Помимо уже показанных снимков с экранов, довольно сложно изобразить особенности взаимодействий с программой в такой статической среде, как книга, - более полное представление вы сможете получить, опробовав программу у себя на компьютере.
Например, щелчки левой и правой кнопками мыши будут изменять высоту и ширину изображения, соответственно, а нажатие клавиш I и O будет изменять масштаб, увеличивая и уменьшая изображение с шагом 10 процентов. Обе схемы изменения размеров позволяют сжать изображение, которое не умещается на экране целиком, а также растягивать маленькие фотографии. Они также сохраняют исходное отношение сторон фотографий, пропорционально изменяя высоту или ширину, чего не делает изменение размера только по одной из осей (может растягиваться по ширине или высоте).
После изменения размеров изображения можно сохранять в файлах с их текущими размерами. Кроме того, программа PyPhoto достаточно интеллектуальна, чтобы открывать в Windows окна в полный размер, если изображение не помещается в открытое окно.
Исходный программный код PyPhoto
Поскольку PyPhoto просто расширяет и повторно использует приемы и программный код, с которыми мы встречались ранее в книге, здесь мы опустим детальное обсуждение исходных текстов. За исходными сведениями обращайтесь к обсуждению приемов обработки изображений и применения PIL в главе 8 и к описанию виджета холста в главе 9.
В двух словах отмечу, что PyPhoto использует холсты в двух случаях: для отображения коллекций миниатюр и для вывода открываемых изображений. Для вывода миниатюр используется тот же прием компоновки, что и раньше, в примере 9.15. Для вывода полноразмерных изображений также используется холст, прокручиваемая (полная) область которого соответствует размеру изображения, а видимая область вычисляется как минимум из размера физического экрана и размера самого изображения. Физический размер экрана можно определить вызовом метода maxsize() окна Toplevel. Благодаря этому полноразмерное изображение можно прокручивать, что очень удобно при просмотре изображений, размеры которых слишком велики, чтобы уместиться на экране (что весьма характерно для фотографий, снятых новейшими цифровыми фотокамерами).
Кроме того, PyPhoto выполняет привязку событий от клавиатуры и мыши для реализации операций изменения размеров и масштаби-
Рис. 11.8. Диалог открытия каталога в программе PyPhoto (клавиша D)
PyPhoto: программа просмотра и изменения размеров изображений
923
рования. Благодаря PIL эти операции реализуются очень просто - мы сохраняем оригинальное изображение в объекте изображения PIL, вызываем его метод resize, передавая новые размеры, и перерисовываем изображение на холсте. Программа PyPhoto также использует диалоги открытия и сохранения файла, чтобы запомнить последний посещенный каталог.
Расширение PIL поддерживает дополнительные операции, которыми мы могли бы расширить набор обрабатываемых событий, но для просмотра изображений вполне достаточно изменения размеров. В настоящее время PyPhoto не использует потоки выполнения, чтобы с их помощью избежать блокирования во время выполнения продолжительных операций (например, операция первого открытия большого каталога). Такие расширения я оставляю для самостоятельного упражнения.
Программа PyPhoto реализована в виде единого файла, представленного в примере 11.5, хотя она получает бесплатно некоторую дополнительную функциональность от повторного использования функции, генерирующей миниатюры, из модуля viewer_thumbs, который мы написали в конце главы 8, в примере 8.45. Чтобы не заставлять вас листать страницы взад и вперед, ниже приводится фрагмент программного кода импортируемой функции создания миниатюр, используемой здесь:
# импортировано из главы 8...
def makeThumbs(imgdir, size=(100, 100), subdir=’thumbs’):
# возвращает список кортежей
# (имя_файла_изображения, объект_миниатюры_изображения);
thumbdir = os.path.join(imgdir, subdir)
if not os.path.exists(thumbdir): os.mkdir(thumbdir)
thumbs = []
for imgfile in os.listdir(imgdir):
thumbpath = os.path.join(thumbdir, imgfile) if os.path.exists(thumbpath):
thumbobj = Image.open(thumbpath) # использовать созданные ранее thumbs.append((imgfile, thumbobj)) else:
print(‘making’, thumbpath)
imgpath = os.path.join(imgdir, imgfile)
try:
imgobj = Image.open(imgpath) # создать миниатюру
imgobj.thumbnail(size, Image.ANTIALIAS) # фильтр, дающий
# лучшее качество при
# уменьшении размеров
imgobj.save(thumbpath) # тип определяется
thumbs.append((imgfile, imgobj)) # расширением
except:
print("Skipping: ", imgpath)
return thumbs
Программный код, реализующий окно выбора миниатюр, также очень схож с представленным в главе 9 примером с прокручиваемой коллекцией миниатюр, но он не импортируется этим файлом, а просто повторяется в нем, чтобы обеспечить будущее его развитие (и его статус в главе 9 - функционального подмножества - здесь понижен до уровня прототипа).
При изучении этого файла особое внимание обратите на организацию программного кода в виде набора функций и методов многократного пользования, которая позволяет избежать избыточности, - если нам, например, когда-нибудь придется изменить реализацию операции изменения размеров, нам достаточно будет изменить один метод, а не два. Кроме того, обратите внимание на класс ScrolledCanvas - компонент многократного пользования, который обеспечивает автоматическое связывание полос прокрутки и холстов.
Пример 11.5. PP4E\Gui\PIL\pyphoto1.py
############################################################################
PyPhoto 1.1: программа просмотра миниатюр изображений с возможностью изменения размеров и сохранения.
Позволяет открывать несколько окон для просмотра миниатюр из разных каталогов - в качестве начального каталога с изображениями принимается аргумент командной строки, каталог по умолчанию "images” или выбранный щелчком на кнопке в главном окне; последующие каталоги могут открываться нажатием клавиши “D” в окне с миниатюрами или в окне просмотра полноразмерного изображения.
Программа также позволяет прокручивать изображения, если они слишком большие и не умещаются на экране;
все еще необходимо: (1) реализовать переупорядочение миниатюр при изменении размеров окна, исходя из текущего размера окна; (2) [ВЫПОЛНЕНО] возможность изменения размеров изображения в соответствии с текущими размерами окна?
(3) отключать прокрутку, если размер изображения меньше максимального размера окна: использовать Label, если шир_изобр <= шир_окна и выс_изобр <= выс_окна?
Новое в версии 1.1: работает под управлением Python 3.1 и с последней версией PIL;
Новое в версии 1.0: реализован пункт (2) выше: щелчок мышью изменяет размер изображения в соответствии с одним из размеров экрана, и предусмотрена возможность увеличения и уменьшения масштаба изображения с шагом 10% нажатием клавиши; требуется поискать более универсальные решения; ВНИМАНИЕ: похоже, что после многократного изменения размеров теряется качество изображения (вероятно, это ограничение PIL)
Следующий алгоритм масштабирования, заимствованный из реализации создания миниатюр средствами PIL, напоминает алгоритм масштабирования по высоте экрана, используемый в программе, но только для сжатия: x, y = imgwide, imghigh
if x > scrwide: y = max(y * scrwide // x, 1); x = scrwide
if y > scrhigh: x = max(x * scrhigh // y, 1); y = scrhigh ############################################################################ import sys, math, os from tkinter import *
from tkinter.filedialog import SaveAs, Directory
from PIL import Image # PIL Image: также имеется в tkinter
from PIL.ImageTk import PhotoImage # версия виджета PhotoImage из PIL from viewer_thumbs import makeThumbs # разработан ранее в книге
# запомнить последний открытый каталог
saveDialog = SaveAs(title=’Save As (filename gives image type)’) openDialog = Directory(title=’Select Image Directory To Open’)
trace = print # or lambda *x: None appname = ‘PyPhoto 1.1: ‘
class ScrolledCanvas(Canvas):
холст в контейнере, который автоматически создает вертикальную и горизонтальную полосы прокрутки
def __init__(self, container):
Canvas.__init__(self, container)
self.config(borderwidth=0)
vbar = Scrollbar(container)
hbar = Scrollbar(container, orient=’horizontal’)
vbar.pack(side=RIGHT, fill=Y) # холст прикрепляется после
hbar.pack(side=BOTTOM, fill=X) # полос, чтобы обрезался первым
self.pack(side=TOP, fill=BOTH, expand=YES)
vbar.config(command=self.yview) # вызвать при перемещении полосы
hbar.config(command=self.xview) # прокрутки
self.config(yscrollcommand=vbar.set) # вызвать при прокрутке холста
self.config(xscrollcommand=hbar.set)
class ViewOne(Toplevel):
при создании открывает единственное изображение во всплывающем окне; реализовано в виде класса, потому что объект PhotoImage должен сохраняться, иначе изображение будет стерто при утилизации; обеспечивает прокрутку больших изображений; щелчок мыши изменяет размер изображения в соответствии с высотой или шириной окна: растягивает или сжимает; нажатие клавиш I и O увеличивает и уменьшает размеры изображения; оба алгоритма изменения размеров предусматривают сохранение оригинального отношения сторон; программный код организован так, чтобы избежать избыточности, насколько это возможно;
def __init__(self, imgdir, imgfile, forcesize=()):
Toplevel.__init__(self)
helptxt = ‘(click L/R or press I/O to resize, S to save, D to open)’
self.title(appname + imgfile + ‘ ‘ + helptxt)
imgpath = os.path.join(imgdir, imgfile)
imgpil = Image.open(imgpath)
self.canvas = ScrolledCanvas(self)
self.drawImage(imgpil, forcesize)
self.canvas.bind(‘’, self.onSizeToDisplayHeight) self.canvas.bind(‘’, self.onSizeToDisplayWidth) self.bind(‘’, self.onZoomIn) self.bind(‘’, self.onZoomOut) self.bind(‘’, self.onSaveImage) self.bind(‘’, onDirectoryOpen) self.focus()
def drawImage(self, imgpil, forcesize=()):
imgtk = PhotoImage(image=imgpil) # file != imgpath
scrwide, scrhigh = forcesize or self.maxsize() # размеры x,y экрана imgwide = imgtk.width() # размеры в пикселях
imghigh = imgtk.height() # то же,
# что и imgpil.size
fullsize = (0, 0, imgwide, imghigh) # прокручиваемая
viewwide = min(imgwide, scrwide) # видимая
viewhigh = min(imghigh, scrhigh)
canvas = self.canvas
canvas.delete(‘all’) # удалить предыд. изобр.
canvas.config(height=viewhigh, width=viewwide) # видимые размеры окна canvas.config(scrollregion=fullsize) # размер прокр. области
canvas.create_image(0, 0, image=imgtk, anchor=NW)
if imgwide <= scrwide and imghigh <= scrhigh: # слишком велико?
self.state(‘normal’) # нет: размер окна по изобр.
elif sys.platform[:3] == ‘win’: # в Windows на весь экран
self.state(‘zoomed’) # в других исп. geometry()
self.saveimage = imgpil
self.savephoto = imgtk # сохранить ссылку на меня
trace((scrwide, scrhigh), imgpil.size)
def sizeToDisplaySide(self, scaler):
# изменить размер, чтобы полностью заполнить одну сторону экрана imgpil = self.saveimage
scrwide, scrhigh = self.maxsize() # размеры x,y экрана
imgwide, imghigh = imgpil.size # размеры изображения в пикселях
newwide, newhigh = scaler(scrwide, scrhigh, imgwide, imghigh) if (newwide * newhigh < imgwide * imghigh):
filter = Image.ANTIALIAS # сжатие: со сглаживанием
else: # растягивание: бикубическая
filter = Image.BICUBIC # аппроксимация
imgnew = imgpil.resize((newwide, newhigh), filter) self.drawImage(imgnew)
def onSizeToDisplayHeight(self, event):
def scaleHigh(scrwide, scrhigh, imgwide, imghigh): newhigh = scrhigh
newwide = int(scrhigh * (imgwide / imghigh)) # истинное деление return (newwide, newhigh) # пропорциональные
self.sizeToDisplaySide(scaleHigh)
def onSizeToDisplayWidth(self, event):
def scaleWide(scrwide, scrhigh, imgwide, imghigh): newwide = scrwide
newhigh = int(scrwide * (imghigh / imgwide)) # истинное деление return (newwide, newhigh) self.sizeToDisplaySide(scaleWide)
def zoom(self, factor):
# уменьшить или увеличить масштаб с шагом imgpil = self.saveimage
wide, high = imgpil.size
if factor < 1.0: # сглаживание дает лучшее качество
filter = Image.ANTIALIAS # при сжатии, также можно else: # использовать NEAREST, BILINEAR
filter = Image.BICUBIC
new = imgpil.resize((int(wide * factor), int(high * factor)), filter) self.drawImage(new)
def onZoomIn(self, event, incr=.10): self.zoom(1.0 + incr)
def onZoomOut(self, event, decr=.10): self.zoom(1.0 - decr)
def onSaveImage(self, event):
# сохранить изображение в текущем виде в файл filename = saveDialog.show()
if filename:
self.saveimage.save(filename)
def onDirectoryOpen(event):
открывает новый каталог с изображениями в новом окне
может вызываться в обоих окнах, с изображением и с миниатюрами
dirname = openDialog.show() if dirname:
viewThumbs(dirname, kind=Toplevel)
def viewThumbs(imgdir, kind=Toplevel, numcols=None, height=400, width=500):
создает окно и кнопки с миниатюрами;
использует кнопки фиксированного размера, прокручиваемый холст; устанавливает прокручиваемый (полный) размер и размещает миниатюры в холсте по абсолютным координатам x,y;
больше не предполагает, что все миниатюры имеют одинаковые размеры: за основу берет максимальные размеры (x,y) среди всех миниатюр, некоторые могут быть меньше;
win = kind()
helptxt = ‘(press D to open other)’
win.title(appname + imgdir + ‘ ‘ + helptxt)
quit = Button(win, text=’Quit’, command=win.quit, bg=’beige’)
quit.pack(side=BOTTOM, fill=X)
canvas = ScrolledCanvas(win)
canvas.config(height=height, width=width) # видимый размер окна, может
# изменяться пользователем
thumbs = makeThumbs(imgdir) # [(imgfile, imgobj)]
numthumbs = len(thumbs) if not numcols:
numcols = int(math.ceil(math.sqrt(numthumbs))) # фиксир. или N x N numrows = int(math.ceil(numthumbs / numcols)) # истинное деление
# максимальная шир|выс: thumb=(name, obj), thumb.size=(width, height) linksize = max(max(thumb[1].size) for thumb in thumbs) trace(linksize)
fullsize = (0, 0, # X,Y верхн. левого угла
(linksize*numcols),(linksize*numrows)) # X,Y прав. нижнего угла canvas.config(scrollregion=fullsize) # размер прокруч. области
rowpos = 0 savephotos = [] while thumbs:
thumbsrow, thumbs = thumbs[:numcols], thumbs[numcols:] colpos = 0
for (imgfile, imgobj) in thumbsrow: photo = PhotoImage(imgobj) link = Button(canvas, image=photo) def handler(savefile=imgfile):
ViewOne(imgdir, savefile)
link.config(command=handler, width=linksize, height=linksize) link.pack(side=LEFT, expand=YES) canvas.create_window(colpos, rowpos, anchor=NW,
window=link, width=linksize, height=linksize) colpos += linksize savephotos.append(photo) rowpos += linksize
win.bind(‘’, onDirectoryOpen) win.savephotos = savephotos return win
if__name__== ‘__main__’:
открываемый каталог = по умолчанию или из аргумента командной строки, иначе вывести простое окно с кнопкой для выбора каталога
imgdir = ‘images’
if len(sys.argv) > 1: imgdir = sys.argv[1] if os.path.exists(imgdir):
mainwin = viewThumbs(imgdir, kind=Tk) else:
mainwin = Tk()
mainwin.title(appname + ‘Open’) handler = lambda: onDirectoryOpen(None)
Button(mainwin, text=’Open Image Directory’, command=handler).pack() mainwin.mainloop()
PyView: слайд-шоу для изображений и примечаний
Одна картинка стоит тысячи слов, и их понадобится значительно меньше, чтобы вывести картинку с помощью Python. В следующей программе, PyView, представлена простая и переносимая реализация алгоритма слайд-шоу на языке Python и в библиотеке tkinter. Эта программа не обладает возможностями обработки изображений, такими как изменение их размеров, но она реализует другие инструменты, такие как файлы с примечаниями для изображений, и может выполняться при отсутствии PIL.
Запуск PyView
В PyView соединились многие из тем, изучавшихся в главе 9: последовательная смена изображений реализована с применением метода after, объекты изображений выводятся на холсте, автоматически изменяющем размер, и так далее. В главном окне программы на холсте выводится фотография; пользователь может открыть и просматривать ее непосредственно или запустить режим поочередного показа слайдов, в котором фотографии, случайным образом выбранные из каталога, выводятся через равные промежутки времени, задаваемые с помощью виджета ползунка.
По умолчанию показ слайдов в PyView производится для каталога с изображениями, входящего в состав примеров для книги (хотя кнопка Open позволяет загружать изображения из любых каталогов). Чтобы посмотреть другую коллекцию фотографий, передайте имя каталога в качестве первого аргумента командной строки или измените имя каталога по умолчанию в самом сценарии. Я не могу показать, как действует программа в режиме показа слайдов, но главное окно привести можно.
На рис. 11.12 изображено главное окно PyView, созданное сценарием slideShowPlus.py из примера 11.6, как оно выглядит в Windows 7.
На рисунке в книге этого не видно, но в действительности на метке вверху окна черным по красному выведен путь к отображаемому файлу. Сейчас переместите ползунок до конца к отметке «0», чтобы определить отсутствие задержки между сменой фотографий, и щелкните на кнопке Start, чтобы начать очень быстрый показ слайдов. Если ваш компьютер обладает хотя бы таким же быстродействием, как мой, то фотографии будут мелькать слишком быстро, чтобы их можно было применить где-либо, кроме как в рекламе, действующей на подсознание. Демонстрируемые фотографии загружаются при начальном запуске, чтобы сохранить ссылки на них (напомню, что объекты с изображениями нужно удерживать). Но скорость, с которой могут отображаться большие GIF-файлы на языке Python, впечатляет, а то и просто восхищает.
Во время показа слайдов кнопка Start изменяется на Stop (изменяется ее текстовый атрибут с помощью метода config виджета). На рис. 11.13 изображено окно после щелчка на кнопке Stop в некоторый момент.
Рис. 11.12. PyView без примечаний
Рис. 11.13. PyView после остановки показа слайдов
Кроме того, у каждой фотографии может быть свой файл «примечаний», который автоматически открывается вместе с изображением. С помощью этой функции можно записывать основные данные о фотографии. Нажмите кнопку Note, чтобы открыть дополнительный набор виджетов, с помощью которых можно просматривать и изменять файл примечаний, связанный с фотографией, просматриваемой в данный момент. Этот дополнительный набор виджетов должен показаться вам знакомым - это текстовый редактор PyEdit, представленный ранее в этой главе, прикрепленный к PyView в качестве средства просмотра и редактирования примечаний к фотографиям. На рис. 11.14 показано окно программы PyView вместе с прикрепленным к нему компонентом PyEdit для редактирования примечаний.
Встраивание PyEdit в PyView
В результате получается очень большое окно, которое обычно лучше просматривать развернутым на весь экран. Однако главное, на что нужно обратить внимание, - это правый нижний угол экрана над ползунком - там находится прикрепленный объект PyEdit, выполняющий тот же самый код, который был приведен выше. Так как редактор PyEdit
Рис. 11.14. PyView с примечаниями
реализован в виде класса, подобным образом его можно повторно использовать в любом графическом интерфейсе, где требуется обеспечить возможность редактирования текста.
При встраивании таким способом PyEdit оказывается вложенным фреймом, прикрепляемым к фрейму в интерфейсе программы слайд-шоу. При этом PyEdit создает меню на основе фрейма (он не владеет окном в целом), текстовое содержимое сохраняется и выбирается непосредственно вмещающей программой, а некоторые возможности автономного режима отсутствуют (например, отсутствуют меню FiLe и кнопка Quit). При этом вы получаете все остальные функции PyEdit, включая вырезание и копирование, поиск и поиск с заменой, поиск во внешних файлах, настройку цвета и шрифта, поддержку отмены и возврата операций редактирования и так далее. Доступна даже операция Clone, которая создает новое окно редактирования, хотя при этом меню создается на основе фрейма без операции Quit и без меню File, а при выходе не проверяется наличие несохраненных изменений, - все эти функции при желании можно связать с новым классом компонента PyEdit верхнего уровня.
Кроме того, если передать PyView третий аргумент командной строки, после имени каталога с изображениями, он будет интерпретироваться как индекс в списке классов PyEdit в соответствии с режимами верхнего уровня. Значению 0 аргумента соответствует режим главного окна, в этом случае редактор примечаний помещается под изображением, а его меню - в верхнюю часть окна (его фрейм при компоновке получает оставшееся место в окне, а не во фрейме PyView). При значении 1 редактор выводится в отдельном, независимом окне Toplevel (деактивируется при выключении показа примечаний). При значениях 2 и 3 PyEdit используется как встраиваемый компонент, прикрепляемый к фрейму PyView, с меню на основе фрейма (при значении 2 редактор включает все имеющиеся у него пункты меню, которые могут не подходить для данного случая его применения, а значение 3 обеспечивает ограниченный набор пунктов меню).
На рис. 11.15 изображен случай использования значения 0, когда PyEdit запускается в режиме главного окна. Здесь в окне в действительности создаются два независимых фрейма - фрейм PyView в верхней части и фрейм текстового редактора в нижней части. Недостаток этого режима перед режимом вложенного компонента или отдельного окна состоит в том, что PyEdit берет управление окном программы на
Рис. 11.15. PyView с PyEdit в другом режиме
себя (включая его заголовок и обработку события щелчка на кнопке закрытия), а его расположение в нижней части окна означает, что редактор может оказаться скрытым при просмотре изображений большого размера по высоте. Поэкспериментируйте с этой возможностью у себя, чтобы почувствовать особенности использования других разновидностей PyEdit, используя командную строку такого вида:
C:\...\PP4E\Gui\SlideShow> slideShowPlus.py ../gifs 0
Средство просмотра примечаний появляется только после щелчка на кнопке Note и удаляется после повторного щелчка на ней. Чтобы показать или скрыть фрейм просмотра примечаний, PyView пользуется методами pack и pack_forget виджетов, с которыми мы познакомились в конце главы 9. Окно автоматически расширяется, чтобы разместить средство просмотра примечаний, когда оно прикрепляется и отображается. Очень важно, что при переводе в видимое состояние редактор повторно прикрепляется с параметрами expand=YES и fill=BOTH, иначе в некоторых режимах он не будет растягиваться - фрейм PyEdit компонует себя в GuiMaker именно с этим параметрами, когда создается впервые, но метод pack_forget, похоже... действительно забывает51.
Файл примечаний можно также открыть во всплывающем окне PyEdit, но по умолчанию PyView встраивает редактор, чтобы сохранить прямую зрительную ассоциацию между изображением и примечанием и избежать проблем, которые могут возникнуть при независимом закрытии окна редактора. В данной реализации классы PyEdit приходится обертывать классом WrapEditor, чтобы перехватить операцию уничтожения фрейма PyEdit, когда он выполняется в отдельном всплывающем окне или в режиме полнофункционального компонента, - после уничтожения редактор будет недоступен, и его невозможно будет вновь прикрепить к графическому интерфейсу. Это не представляет проблемы при использовании редактора в режиме главного окна (операция Quit завершает программу) или в режиме минимального компонента (когда редактор не имеет операции Quit). Мы еще встретимся с приемом встраивания PyEdit внутрь другого графического интерфейса, когда будем рассматривать PyMailGUI в главе 14.
Предупреждение: в таком виде PyView поддерживает те же форматы представления графических изображений, что и объект PhotoImage библиотеки tkinter, поэтому по умолчанию он ищет файлы в формате GIF. Улучшить положение можно, установив расширение PIL для просмотра JPEG (и многих других форматов). Поскольку сегодня PIL является необязательным расширением, он не включен в данную версию PyView. Подробнее о расширении PIL и о графических форматах рассказывается в конце главы 8.
Исходный программный код PyView
Поскольку программа PyView разрабатывалась поэтапно, вам придется изучить объединение двух файлов и классов, чтобы понять, как она в действительности работает. В одном файле реализован класс, предоставляющий основные функции показа слайдов, а в другом реализован класс, расширяющий исходный и добавляющий новые функции поверх базового поведения. Начнем с класса расширения: пример 11.6 добавляет ряд функций в импортируемый базовый класс показа слайдов - редактирование примечаний, ползунок, определяющий задержку, метку для отображения имени файла и так далее. Это тот файл, который фактически запускает PyView.
Пример 11.6. PP4E\Gui\SlideShow\slideShowPlus.py
#############################################################################
PyView 1.2: программа показа слайдов с прилагаемыми к ним примечаниями.
Подкласс класса SlideShow, который добавляет отображение содержимого файлов с примечаниями в прикрепляемом объекте PyEdit, ползунок для установки интервала задержки между сменами изображений и метку с именем текущего отображаемого файла изображения;
Версия 1.2 работает под управлением Python 3.x и дополнительно использует улучшенный алгоритм повторного прикрепления компонента PyEdit, чтобы обеспечить его растягиваемость, перехватывает операцию закрытия примечания в подклассе, чтобы избежать появления исключения при закрытии PyEdit, использующегося в режиме всплывающего окна или полнофункционального компонента, и вызывает метод update() перед вставкой текста во вновь прикрепленный редактор примечаний, чтобы обеспечить правильное позиционирование в первой строке (смотрите описание этой проблемы в книге).
#############################################################################
import os
from tkinter import *
from PP4E.Gui.TextEditor.textEditor import *
from slideShow import SlideShow
#from slideShow_threads import SlideShow
Size = (300, 550) # 1.2: начальные размеры, (высота, ширина)
class SlideShowPlus(SlideShow):
def __init__(self, parent, picdir, editclass, msecs=2000, size=Size):
self.msecs = msecs self.editclass = editclass
SlideShow.__init__(self, parent, picdir, msecs, size)
def makeWidgets(self):
self.name = Label(self, text='None', bg=’red’, relief=RIDGE) self.name.pack(fill=X)
SlideShow.makeWidgets(self)
Button(self, text=’Note’, command=self.onNote).pack(fill=X) Button(self, text=’Help’, command=self.onHelp).pack(fill=X) s = Scale(label=’Speed: msec delay’, command=self.onScale, from_=0, to=3000, resolution=50, showvalue=YES, length=400, tickinterval=250, orient=’horizontal’) s.pack(side=BOTTOM, fill=X) s.set(self.msecs)
# 1.2: знать о закрытии редактора необходимо, если он используется
# в режиме всплывающего окна или полнофункционального компонента self.editorGone = False
class WrapEditor(self.editclass):# расширяет PyEdit для перехвата Quit def onQuit(editor): # editor - экземпляр PyEdit
self.editorGone = True # self - вмещающий экземпляр self.editorUp = False # класса слайд-шоу self.editclass.onQuit(editor) # предотвратить рекурсию
# прикрепить фрейм редактора к окну или к фрейму слайд-шоу
if issubclass(WrapEditor, TextEditorMain): # создать объект редактора self.editor = WrapEditor(self.master) # указать корень для меню else: # встраиваемый компонент
self.editor = WrapEditor(self) # или компонент всплывающего окна self.editor.pack_forget() # скрыть редактор при запуске
self.editorUp = self.image = None
def onStart(self):
SlideShow.onStart(self)
self.config(cursor=’watch’)
def onStop(self):
SlideShow.onStop(self)
self.config(cursor=’hand2’)
def onOpen(self):
SlideShow.onOpen(self) if self.image:
self.name.config(text=os.path.split(self.image[0])[1])
self.config(cursor=’crosshair’)
self.switchNote()
def quit(self): self.saveNote()
SlideShow.quit(self)
def drawNext(self):
SlideShow.drawNext(self) if self.image:
self.name.config(text=os.path.split(self.image[0])[1])
self.loadNote()
def onScale(self, value): self.msecs = int(value)
def onNote(self):
if self.editorGone: # 1.2: был уничтожен
return # не воссоздавать: видимо, он был нежелателен
if self.editorUp:
#self.saveNote() # если редактор уже открыт
self.editor.pack_forget() # сохранить текст?, скрыть редактор
self.editorUp = False else:
# 1.2: повторно прикрепить с параметрами, управляющими
# растягиванием, иначе виджет редактора не будет
# растягиваться
# 1.2: вызвать update после прикрепления и перед вставкой текста,
# иначе текстовый курсор будет изначально помещен во 2 строку
self.editor.pack(side=TOP, expand=YES, fill=BOTH) self.editorUp = True # или показать/прикрепить редактор self.update() # смотрите Pyedit: та же проблема с loadFirst
self.loadNote() # и загрузить текст примечания
def switchNote(self): if self.editorUp:
self.saveNote() # сохранить примечание к текущему изображению
self.loadNote() # загрузить примечание для нового изображения
def saveNote(self): if self.editorUp:
currfile = self.editor.getFileName() # или self.editor.onSave() currtext = self.editor.getAllText() # текст может отсутствовать if currfile and currtext: try:
open(currfile, ‘w’).write(currtext) except:
pass # неудача является нормальным явлением при # выполнении за пределами текущего каталога
def loadNote(self):
if self.image and self.editorUp:
root, ext = os.path.splitext(self.image[0]) notefile = root + ‘.note’ self.editor.setFileName(notefile) try:
self.editor.setAllText(open(notefile).read())
except:
self.editor.clearAllText() # примечание может отсутствовать
def onHelp(self):
showinfo(‘About PyView’,
‘PyView version 1.2\nMay, 2010\n(1.1 July, 1999)\n’
‘An image slide show\nProgramming Python 4E’)
if __name__ == ‘__main__’: import sys picdir = ‘../gifs’ if len(sys.argv) >= 2: picdir = sys.argv[1]
editstyle = TextEditorComponentMinimal if len(sys.argv) == 3: try:
editstyle = [TextEditorMain,
TextEditorMainPopup,
TextEditorComponent,
TextEditorComponentMinimal][int(sys.argv[2])]
except: pass root = Tk()
root.title(‘PyView 1.2 - plus text notes’)
Label(root, text=”Slide show subclass”).pack()
SlideShowPlus(parent=root, picdir=picdir, editclass=editstyle) root.mainloop()
Базовая функциональность, расширяемая классом SlideShowPlus, приводится в примере 11.7. Этот пример представляет первоначальную реализацию показа слайдов - он открывает файлы изображений, отображает их и организует показ слайдов в цикле. Его можно запустить как самостоятельный сценарий, но при этом вы не получите дополнительных функций, таких как примечания и ползунки, добавляемые подклассом SlideShowPlus.
Пример 11.7. PP4E\Gui\SlideShow\slideShow.py
######################################################################
SlideShow: простая реализация показа слайдов на Python/tkinter; базовый набор функций, реализованных здесь, можно расширять в подклассах; ######################################################################
from tkinter import *
from glob import glob
from tkinter.messagebox import askyesno
from tkinter.filedialog import askopenfilename
import random
Size = (450, 450) # начальная высота и ширина холста
imageTypes = [(‘Gif files’, ‘.gif’), # для диалога открытия файла (‘Ppm files’, ‘.ppm’), # плюс jpg с исправлениями Tk,
(‘Pgm files’, ‘.pgm’), # плюс растровые с помощью BitmapImage (‘All files’, ‘*’)]
class SlideShow(Frame):
def __init__(self, parent=None, picdir=’.’, msecs=3000, size=Size,**args)
Frame.__init__(self, parent, **args) self.size = size self.makeWidgets() self.pack(expand=YES, fill=BOTH) self.opens = picdir files = []
for label, ext in imageTypes[:-1]:
files = files + glob(‘%s/*%s’ % (picdir, ext)) self.images = [(x, PhotoImage(file=x)) for x in files] self.msecs = msecs self.beep = True self.drawn = None
def makeWidgets(self):
height, width = self.size
self.canvas = Canvas(self, bg=’white’, height=height, width=width) self.canvas.pack(side=LEFT, fill=BOTH, expand=YES) self.onoff = Button(self, text=’Start’, command=self.onStart) self.onoff.pack(fill=X)
Button(self, text=’Open’, command=self.onOpen).pack(fill=X) Button(self, text=’Beep’, command=self.onBeep).pack(fill=X) Button(self, text=’Quit’, command=self.onQuit).pack(fill=X)
def onStart(self): self.loop = True
self.onoff.config(text=’Stop’, command=self.onStop) self.canvas.config(height=self.size[0], width=self.size[1]) self.onTimer()
def onStop(self): self.loop = False
self.onoff.config(text=’Start’, command=self.onStart)
def onOpen(self): self.onStop()
name = askopenfilename(initialdir=self.opens, filetypes=imageTypes) if name:
if self.drawn: self.canvas.delete(self.drawn) img = PhotoImage(file=name)
self.canvas.config(height=img.height(), width=img.width()) self.drawn = self.canvas.create_image(2, 2, image=img, anchor=NW) self.image = name, img
def onQuit(self): self.onStop() self.update()
if askyesno(‘PyView’, ‘Really quit now?’): self.quit()
def onBeep(self):
self.beep = not self.beep # toggle, or use ^ 1
def onTimer(self): if self.loop:
self.drawNext()
self.after(self.msecs, self.onTimer) def drawNext(self):
if self.drawn: self.canvas.delete(self.drawn) name, img = random.choice(self.images)
self.drawn = self.canvas.create_image(2, 2, image=img, anchor=NW) self.image = name, img if self.beep: self.bell() self.canvas.update()
if __name__ == ‘__main__’: import sys
if len(sys.argv) == 2: picdir = sys.argv[1] else:
picdir = ‘../gifs’ root = Tk()
root.title(‘PyView 1.2’) root.iconname(‘PyView’)
Label(root, text=”Python Slide Show Viewer”).pack()
SlideShow(root, picdir=picdir, bd=3, relief=SUNKEN) root.mainloop()
Чтобы вы могли получить более полное представление о том, что реализует этот базовый класс, на рис. 11.16 показано, как выглядит графический интерфейс, создаваемый этим примером, если запустить его в виде самостоятельного сценария. Здесь изображены два экземпляра, создаваемые сценарием slideShow_frames, который можно найти в дереве примеров и основная реализация которого приводится ниже:
root = Tk()
Label(root, text=”Two embedded slide shows: Frames”).pack()
SlideShow(parent=root, picdir=picdir, bd=3, relief=SUNKEN).pack(side=LEFT) SlideShow(parent=root, picdir=picdir, bd=3, relief=SUNKEN).pack(side=RIGHT) root.mainloop()
Простой сценарий slideShow_frames прикрепляет два экземпляра SlideShow к одному окну. Это возможно благодаря тому, что информация о состоянии сохраняется не в глобальных переменных, а в переменных экземпляра класса. Сценарий slideShow_toplevels (также можно найти в дереве примеров) прикрепляет два экземпляра SlideShow к двум всплывающим окнам верхнего уровня. В обоих случаях показ слайдов происходит независимо, но управляется событиями after, генерируемыми одним и тем же циклом событий в одном процессе.
Рис. 11.16. Два прикрепленных объекта SlideShow
PyDraw: рисование и перемещение графики
В главе 9 мы познакомились с простыми приемами воспроизведения анимации с помощью инструментов из библиотеки tkinter (смотрите версии canvasDraw в обзоре tkinter). Представленная здесь программа PyDraw, основываясь на тех же идеях, реализует на языке Python более богатые функциональные возможности. В ней появились новые режимы рисования мышью, возможность заливки объектов и фона, встраивание фотографий и многое другое. Кроме того, в ней реализованы приемы перемещения объектов и анимации - нарисованные объекты можно перемещать по холсту, щелкая на них и перетаскивая мышью, и любой нарисованный объект можно плавно переместить через экран в место, указанное щелчком мыши.
Запуск PyDraw
PyDraw, по сути, представляет собой холст tkinter с многочисленными привязками событий от клавиатуры и мыши, которые дают возможность пользователю осуществлять стандартные операции рисования. Эту программу нельзя назвать графическим редактором профессионального уровня, но поразвлечься с ней можно. На самом деле - даже нужно, поскольку книга не позволяет передать такие вещи, как движущийся объект. Запустите PyDraw из какой-нибудь панели запуска программ (или непосредственно файл movingpics.py из примера 11.8). Нажмите клавишу ? и посмотрите подсказку по всем имеющимся командам (или прочтите строку helpstr в листинге).
На рис. 11.17 изображено окно PyDraw после того как на холсте было нарисовано несколько объектов. Чтобы переместить какой-либо из объектов, щелкните на нем средней кнопкой мыши и перетащите указателем мыши, либо щелкните средней кнопкой на объекте, а затем правой кнопкой в том месте, куда требуется его переместить. В последнем случае PyDraw воспроизводит анимационный эффект, постепенно перемещая объект в указанное место. Попробуйте сделать это с картинкой, находящейся вверху, и вы увидите, как она плавно перемещается по экрану.
Рис. 11.17. Окно программы PyDraw с нарисованными объектами, готовыми к перемещению
Для вставки фотографий нажмите клавишу p, для рисования фигур используйте левую кнопку мыши. (Пользователям Windows: щелчок средней кнопкой обычно равносилен нажатию двух кнопок одновременно или повороту колесика, но для этого может потребоваться выполнить настройки в Панели Управления.) Помимо событий от мыши можно пользоваться еще 17 командами клавиш для редактирования рисунков, о которых я не буду рассказывать здесь. Требуется некоторое время, чтобы освоиться со всеми командами клавиатуры и мыши, после чего вы тоже сможете создавать бессмысленные электронные рисованные объекты, такие как приведены на рис. 11.18.
Рис. 11.18. Окно программы PyDraw после экспериментов с ней
Исходный программный код PyDraw
Как и PyEdit, программа PyDraw размещается в одном файле. За главным модулем, представленным в примере 11.8, приводятся два расширения, изменяющие реализацию перемещения.
Пример 11.8. PP4E\Gui\MovingPics\movingpics.py
"""
##############################################################################
PyDraw 1.1: простая программа рисования на холсте и перемещения объектов с воспроизведением анимационного эффекта.
В реализации перемещения объектов используются циклы time.sleep, поэтому в каждый момент времени может перемещаться только один объект; перемещение выполняется плавно и быстро, однако далее приведены подклассы, реализующие другие режимы перемещения на основе метода widget.after и потоков выполнения. Версия 1.1 была дополнена возможностью выполнения под управлением Python 3.X (версия 2.X не поддерживается)
##############################################################################
"""
helpstr = """--PyDraw версия 1.1--
Операции, выполняемые мышью:
Левая = Начальная точка рисования
Левая+Перемещение = Рисовать новый объект Двойной щелчок левой = Удалить все объекты Правая = Переместить текущий объект
Средняя = Выбрать ближайший объект
Средняя+Перемещение = Перетащить текущий объект Keyboard commands:
w=Выбрать ширину рамки c=Выбрать цвет
u= Выбрать шаг перемещения s=Выбрать задержку при перемещении
o=Рисовать овалы т=Рисовать прямоугольники
ПРисовать линии a=Рисовать дуги
d=Удалить объект 1=Поднять объект
2=Опустить объект f=Выполнить заливку объекта
b=Выполнить заливку фона p=Добавить фотографию
z=Сохранить в формате Postscript x=Выбрать режим рисования ?=Справка другие=стереть текст
"""
import time, sys from tkinter import * from tkinter.filedialog import * from tkinter.messagebox import *
PicDir = ‘../gifs’
if sys.platform[:3] == ‘win’:
HelpFont = (‘courier’, 9, ‘normal’) else:
HelpFont = (‘courier’, 12, ‘normal’)
pickDelays = [0.01, 0.025, 0.05, 0.10, 0.25, 0.0, 0.001, 0.005] pickUnits = [1, 2, 4, 6, 8, 10, 12] pickWidths = [1, 2, 5, 10, 20]
pickFills = [None,’white’,’blue’,’red’,’black’,’yellow’,’green’,’purple’] pickPens = [‘elastic’, ‘scribble’, ‘trails’]
class MovingPics:
def __init__(self, parent=None):
canvas = Canvas(parent, width=500, height=500, bg= ‘white’) canvas.pack(expand=YES, fill=BOTH) canvas.bind(‘’, self.onStart) canvas.bind(‘’, self.onGrow) canvas.bind(‘’, self.onClear) canvas.bind(‘’, self.onMove) canvas.bind(‘’, self.onSelect) canvas.bind(‘’, self.onDrag) parent.bind(‘’, self.onOptions) self.createMethod = Canvas.create_oval self.canvas = canvas self.moving = [] self.images = [] self.object = None
self.where = None self.scribbleMode = 0
parent.title(‘PyDraw - Moving Pictures 1.1’) parent.protocol(‘WM_DEbETE_WINDOW’, self.onQuit) self.realquit = parent.quit self.textInfo = self.canvas.create_text(
5, 5, anchor=NW, font=HelpFont, text=’Press ? for help’)
def onStart(self, event): self.where = event self.object = None
def onGrow(self, event): canvas = event.widget
if self.object and pickPens[0] == ‘elastic’: canvas.delete(self.object) self.object = self.createMethod(canvas,
self.where.x, self.where.y, # начало event.x, event.y, # конец
fill=pickFills[0], width=pickWidths[0]) if pickPens[0] == ‘scribble’:
self.where = event # нач. координаты для следующей итерации def onClear(self, event):
if self.moving: return # если идет перемещение event.widget.delete(‘all’) # использовать тег all self.images = []
self.textInfo = self.canvas.create_text(
5, 5, anchor=NW, font=HelpFont, text=’Press ? for help’)
def plotMoves(self, event):
diffX = event.x - self.where.x # план анимированного перемещения diffY = event.y - self.where.y # по горизонтали, затем по вертикали reptX = abs(diffX) // pickUnits[0] # приращение на шаге, число шагов reptY = abs(diffY) // pickUnits[0] # от предыдущего до текущего щелчка incrX = pickUnits[0] * ((diffX > 0) or -1) # 3.x требуется деление // incrY = pickUnits[0] * ((diffY > 0) or -1) # с усечением return incrX, reptX, incrY, reptY
def onMove(self, event):
traceEvent(‘onMove’, event, 0) # переместить объект в точку щелчка
object = self.object # игнорировать некоторые
if object and object not in self.moving: # операции при движении msecs = int(pickDelays[0] * 1000)
parms = ‘Delay=%d msec, Units=%d’ % (msecs, pickUnits[0])
self.setTextInfo(parms)
self.moving.append(object)
canvas = event.widget
incrX, reptX, incrY, reptY = self.plotMoves(event) for i in range(reptX):
canvas.move(object, incrX, 0) canvas.update() time.sleep(pickC'0lays[Q]) for i in range(reptY):
canvas.move(object, Q, incrY)
canvas.update() # update выполнит другие операции
time.sleep(pickDelays[0]) # приостановить до следующего шага self.moving.remove(object) if self.object == object: self.where = event
def onSelect(self, event): self.where = event
self.object = self.canvas.find_closest(event.x, event.y)[0] # кортеж
def onDrag(self, event):
diffX = event.x - self.where.x # OK, если объект перемещается
diffY = event.y - self.where.y # переместить в новом направлении
self.canvas.move(self.object, diffX, diffY) self.where = event
def onOptions(self, event): keymap = {
‘w’: lambda self: self.changeOption(pickWidths, ‘Pen Width’),
‘c’: lambda self: self.changeOption(pickFills, ‘Color’),
‘u’: lambda self: self.changeOption(pickUnits, ‘Move Unit’),
‘s’: lambda self: self.changeOption(pickDelays, ‘Move Delay’),
‘x’: lambda self: self.changeOption(pickPens, ‘Pen Mode’),
‘o’: lambda self: self.changeDraw(Canvas.create_oval, ‘Oval’), ‘r’: lambda self: self.changeDraw(Canvas.create_rectangle, ‘Rect’), ‘l’: lambda self: self.changeDraw(Canvas.create_line, ‘Line’),
‘a’: lambda self: self.changeDraw(Canvas.create_arc, ‘Arc’),
‘d’: MovingPics.deleteObject,
‘1’: MovingPics.raiseObject,
‘2’: MovingPics.lowerObject, # если только 1 схема вызова ‘f’: MovingPics.fillObject, # использовать несвязанные методы ‘b’: MovingPics.fillBackground, # иначе передавать self в lambda ‘p’: MovingPics.addPhotoItem,
‘z’: MovingPics.savePostscript,
‘?’: MovingPics.help} try:
keymap[event.char](self) except KeyError:
self.setTextInfo(‘Press ? for help’)
def changeDraw(self, method, name):
self.createMethod = method # несвязанный метод объекта Canvas self.setTextInfo(‘Draw Object=’ + name)
def changeOption(self, list, name): list.append(list[0]) del list[0]
self.setTextInfo(‘%s=%s’ % (name, list[0])) def deleteObject(self):
if self.object != self.textInfo: # ok если объект перемещается
self.canvas.delete(self.object) # стереть, но движение продолжится self.object = None
def raiseObject(self):
if self.object: # ok если объект перемещается
self.canvas.tkraise(self.object) # поднять в процессе перемещения
def lowerObject(self): if self.object:
self.canvas.lower(self.object)
def fillObject(self): if self.object:
type = self.canvas.type(self.object) if type == ‘image’: pass
elif type == ‘text’:
self.canvas.itemconfig(self.object, fill=pickFills[0]) else:
self.canvas.itemconfig(self.object,
fill=pickFills[0], width=pickWidths[0])
def fillBackground(self):
self.canvas.config(bg=pickFills[0])
def addPhotoItem(self):
if not self.where: return
filetypes=[(‘Gif files’, ‘.gif’), (‘All files’, ‘*’)]
file = askopenfilename(initialdir=PicDir, filetypes=filetypes)
if file:
image = PhotoImage(file=file) # загрузить изображение
self.images.append(image) # сохранить ссылку
self.object = self.canvas.create_image( # на холст,
self.where.x, self.where.y, # в точку
image=image, anchor=NW) # посл. щелчка
def savePostscript(self):
file = asksaveasfilename() if file:
self.canvas.postscript(file=file) # сохранить холст в файл
def help(self):
self.setTextInfo(helpstr)
#showinfo(‘PyDraw’, helpstr)
def setTextInfo(self, text):
self.canvas.dchars(self.textInfo, 0, END) self.canvas.insert(self.textInfo, 0, text) self.canvas.tkraise(self.textInfo)
def onQuit(self): if self.moving:
self.setTextInfo(“Can’t quit while move in progress”) else:
self.realquit() # стандартная операция закрытия окна: сообщит # об ошибке, если выполняется перемещение
def traceEvent(label, event, fullTrace=True): print(label) if fullTrace:
for atrr in dir(event): if attr[:2] ! = ‘__’:
print(attr, ‘=>’, getattr(event, attr))
if __name__ == ‘__main__’:
from sys import argv # когда выполняется как сценарий,
if len(argv) == 2: PicDir = argv[1] # ‘..’ не действует при запуске из
# другого каталога
root = Tk() # создать и запустить объект
MovingPics(root) # MovingPics
root.mainloop()
Так как одновременно перемещаться может только один объект, запуск процедуры перемещения объекта в тот момент, когда другой уже находится в движении, приводит к приостановке перемещения первого объекта, пока не будет закончено перемещение нового. Так же как в примерах canvasDraw из главы 9, можно добавить поддержку одновременного перемещения более чем одного объекта с помощью событий планируемых обратных вызовов after или потоков выполнения.
В примере 11.9 приводится подкласс MovingPics, в котором проведены изменения, необходимые для обеспечения параллельного перемещения с помощью событий after. Он позволяет одновременно и независимо друг от друга перемещать любое количество объектов на холсте, включая картинки. Запустите этот файл непосредственно, и вы увидите разницу - я мог бы попытаться сделать снимок с экрана в момент, когда одновременно перемещаются несколько объектов, но из этого вряд ли бы что-то вышло.
Пример 11.9. PP4E\Gui\MovingPies\movingpies_after.py
PyDraw-after: простая программа рисования на холсте и перемещения объектов с воспроизведением анимационного эффекта.
Для реализации перемещения объектов используются циклы на основе метода widget. after, благодаря чему оказалось возможным организовать одновременное перемещение нескольких объектов без применения потоков выполнения; движение осуществляется параллельно, но медленнее, чем в версии с использованием time.sleep; смотрите также пример canvasDraw в обзоре: он конструирует и передает сразу весь список incX/incY: здесь могло бы быть allmoves = ([(incrX, 0)] * reptX) + ([(0, incrY)] * reptY)
from movingpics import *
class MovingPicsAfter(MovingPics):
def doMoves(self, delay, objectId, incrX, reptX, incrY, reptY): if reptX:
self.canvas.move(objectId, incrX, 0) reptX -= 1 else:
self.canvas.move(objectId, 0, incrY) reptY -= 1
if not (reptX or reptY):
self.moving.remove(objectId)
else:
self.canvas.after(delay,
self.doMoves, delay, objectId, incrX, reptX, incrY, reptY)
def onMove(self, event):
traceEvent(‘onMove’, event, 0)
object = self.object # переместить текущий объект в точку щелчка
if object:
msecs = int(pickDelays[0] * 1000)
parms = ‘Delay=%d msec, Units=%d’ % (msecs, pickUnits[0])
self.setTextInfo(parms)
self.moving.append(object)
incrX, reptX, incrY, reptY = self.plotMoves(event) self.doMoves(msecs, object, incrX, reptX, incrY, reptY) self.where = event
if __name__ == ‘__main__’:
from sys import argv # когда выполняется как сценарий
if len(argv) == 2:
import movingpics # глобальная перем. не из этого модуля
movingpics.PicDir = argv[1] # а from* не связывает имена root = Tk()
MovingPicsAfter(root) root.mainloop()
Чтобы оценить работу этого примера, распахните окно сценария на весь экран и создайте несколько объектов на его холсте, нажимая клавишу p после предварительного щелчка, чтобы вставить картинки, нарисуйте несколько фигур и так далее. Теперь, когда уже выполняется одно или несколько перемещений, можно запустить перемещение еще одного объекта, щелкнув на нем средней кнопкой и затем правой кнопкой в том месте, куда требуется его переместить. Перемещение начинается немедленно, даже если на холсте присутствуют другие движущиеся объекты. Запланированные события after всех объектов помещаются в одну и ту же очередь цикла событий и передаются библиотекой tkinter после срабатывания таймера настолько быстро, насколько возможно.
Если запустить этот модуль подкласса непосредственно, то можно заметить, что перемещение не такое плавное и быстрое, как первоначально (в зависимости от быстродействия вашего компьютера и наличия дополнительных программных уровней под Python), зато одновременно может выполняться несколько перемещений.
В примере 11.10 демонстрируется, как обеспечить параллельное перемещение нескольких объектов с помощью потоков. Этот прием действует, но, как отмечалось в главах 9 и 10, обновление графического интерфейса в дочерних потоках выполнения является, вообще говоря, опасным делом. На моей машине перемещение в этом сценарии с потоками происходит не так плавно, как в первоначальной версии, что отражает накладные расходы, связанные с переключением интерпретатора (и ЦП) между несколькими потоками, но, опять же, во многом это зависит от быстродействия компьютера.
Пример 11.10. PP4E\Gui\MovingPies\movingpies_threads.py
PyDraw-threads: использует потоки для перемещения объектов; прекрасно работает в Windows, если не вызывать метод canvas.update() в потоках (иначе сценарий будет завершаться с фатальными ошибками, некоторые объекты будут начинать движение сразу после того как будут нарисованы, и так далее); имеется как минимум несколько методов холста, которые могут вызываться из потоков выполнения; движение осуществляется менее плавно, чем с применением time.sleep, и данная реализация более опасна в целом: внутри потоков лучше ограничиться изменением глобальных переменных и никак не касаться графического интерфейса;
import _thread as thread, time, sys, random from tkinter import Tk, mainloop
from movingpics import MovingPics, pickUnits, pickDelays
class MovingPicsThreaded(MovingPics):
def __init__(self, parent=None):
MovingPics.__init__(self, parent) self.mutex = thread.allocate_lock() import sys
#sys.setcheckinterval(0) # переключение контекста после каждой
# операции виртуальной машины: не поможет
def onMove(self, event): object = self.object if object and object not in self.moving: msecs = int(pickDelays[0] * 1000)
parms = ‘Delay=%d msec, Units=%d’ % (msecs, pickUnits[0]) self.setTextInfo(parms)
#self.mutex.acquire()
self.moving.append(object)
#self.mutex.release()
thread.start_new_thread(self.doMove, (object, event))
def doMove(self, object, event): canvas = event.widget
incrX, reptX, incrY, reptY = self.plotMoves(event) for i in range(reptX):
canvas.move(object, incrX, 0)
# canvas.update()
time.sleep(pickDelays[0]) # может измениться for i in range(reptY):
canvas.move(object, 0, incrY)
# canvas.update() # update выполняет другие операции
time.sleep(pickDelays[0]) # приостановиться до следующего шага
#self.mutex.acquire()
self.moving.remove(object)
if self.object == object: self.where = event
#self.mutex.release()
if __name__ == ‘__main__’: root = Tk()
MovingPicsThreaded(root)
mainloop()
PyClock: виджет аналоговых/цифровых часов
Изучая новый интерфейс компьютера, я всегда вначале отыскиваю часы. Я столько времени неотрывно нахожусь за компьютером, что у меня совершенно не получается следить за временем, если оно не отображается прямо передо мной на экране (и даже тогда это проблематично). Следующая программа, PyClock, реализует такой виджет часов на языке Python. Своим внешним видом она не очень отличается от тех часов, которые вы привыкли видеть в системе X Window. Но так как она написана на языке Python, ее легко перенастраивать и переносить между Windows, X Window и Mac, как и все программы из этой главы. В дополнение к развитым технологиям конструирования графических интерфейсов, этот пример демонстрирует использование модулей Python math и time.
Краткий урок геометрии
Прежде чем продемонстрировать вам PyClock, немного предыстории и признаний. Ну-ка, ответьте: как поставить точки на окружности? Эта задача, а также форматы времени и возникающие события оказываются основными при создании графических элементов часов. Чтобы нарисовать циферблат аналоговых часов на холсте, необходимо уметь рисовать круг - сам циферблат состоит из точек окружности, а секундная, минутная и часовая стрелки представляют собой линии, проведенные из центра в точки на окружности. Цифровые часы нарисовать проще, но смотреть на них неинтересно.
Теперь признание: начав писать PyClock, я не знал ответа на первый вопрос предыдущего абзаца. Я совершенно забыл формулу нахождения координат точек окружности (как и большинство профессиональных программистов, к которым я с этим обращался). Бывает. Такие знания, не будучи востребованными в течение нескольких десятилетий, могут быть утилизированы сборщиком мусора. В конце концов мне удалось смахнуть пыль с нескольких нейронов, длины которых оказалось достаточно, чтобы запрограммировать действия, необходимые для построения, но блеснуть умом мне не удалось.52
Если вы в таком же положении, то я покажу вам один способ простой записи формул построения точек на языке Python, хотя для подробных занятий геометрией места здесь нет. Прежде чем взяться за более сложную задачу реализации часов, я написал сценарий plotterGui, представленный в примере 11.11, чтобы сосредоточиться только на логике построения круга.
Логика построения круга реализуется в функции point - она находит координаты (X,Y) точки окружности по относительному номеру точки, общему количеству точек, помещаемых на окружности, и радиусу окружности (расстоянию между центром окружности и ее точками). Сначала вычисляется угол между нужной точкой и верхней точкой окружности путем деления 360 на количество рисуемых точек и умножения на номер точки. Напомню, что полный круг составляет 360 градусов (например, если на окружности рисуется 4 точки, то каждая отстоит от предыдущей на 90 градусов, или на 360/4). Стандартный модуль Python math предоставляет все необходимые константы и функции - pi, sine и cosine. В действительности математика тут не такая уж непонятная, если вы потратите некоторое время, чтобы ее рассмотреть (возможно, еще взяв старый учебник геометрии). Существуют альтернативные способы реализации нужных математических расчетов, но я не буду углубляться здесь в детали (ищите подсказки в пакете с примерами).
Даже если вы не хотите разбираться с математикой, просмотрите функцию circle в примере 11.11. По указанным координатам (X,Y) точки окружности, возвращаемым функцией point, она чертит линию из центра окружности в точку и маленький прямоугольник вокруг самой точки, что несколько напоминает стрелки и отметки аналоговых часов. Чтобы удалять нарисованные объекты перед каждым построением, используются теги холста.
Пример 11.11. PP4E\Gui\Cloek\plotterGui.py
# рисует окружности на холсте
import math, sys from tkinter import *
def point(tick, range, radius): angle = tick * (360.0 / range) radiansPerDegree = math.pi / 180
pointX = int( round( radius * math.sin(angle * radiansPerDegree) )) pointY = int( round( radius * math.cos(angle * radiansPerDegree) )) return (pointX, pointY)
def circle(points, radius, centerX, centerY, slow=0): canvas.delete(‘lines’) canvas.delete(‘points’) for i in range(points):
x, y = point(i+1, points, radius-4) scaledX, scaledY = (x + centerX), (centerY - y) canvas.create_line(centerX, centerY, scaledX, scaledY, tag=’lines’) canvas.create_rectangle(scaledX-2, scaledY-2, scaledX+2, scaledY+2, fill=’red’, tag=’points’)
if slow: canvas.update()
def plotter(): # в 3.x // - деление с усечением
circle(scaleVar.get(), (Width // 2), originX, originY, checkVar.get())
def makewidgets():
global canvas, scaleVar, checkVar
canvas = Canvas(width=Width, height=Width)
canvas.pack(side=TOP)
scaleVar = IntVar()
checkVar = IntVar()
scale = Scale(label=’Points on circle’, variable=scaleVar, from_=1, to=360)
scale.pack(side=LEFT)
Checkbutton(text=’Slow mode’, variable=checkVar).pack(side=LEFT) Button(text=’Plot’, command=plotter).pack(side=LEFT, padx=50)
if __name__ == ‘__main__’:
Width = 500 # ширина, высота по умолчанию
if len(sys.argv) == 2: Width = int(sys.argv[1]) # ширина в команд. строке?
originX = originY = Width // 2 # то же, что и радиус
makewidgets() # в корневом окне Tk по умолчанию
mainloop() # в 3.x требуется // - деление с усечением
По умолчанию ширина круга составит 500 пикселей, если не определить иначе в командной строке. Получив число точек на окружности, этот сценарий размечает окружность по часовой стрелке при каждом нажатии кнопки PLot, вычерчивая прямые из центра к маленьким прямоугольникам на окружности. Переместите ползунок, чтобы задать другое число точек, и щелкните на флажке, чтобы рисование происходило достаточно медленно и можно было заметить очередность вычерчивания линий и точек (при этом сценарий вызывает update для обновления экрана после вычерчивания каждой линии). На рис. 11.19 приводится результат нанесения 120 точек при установке в командной строке ширины круга равной 400; если задать на окружности 60 или 12 точек, сходство с часовым циферблатом станет более заметным.
Рис. 11.19. Сценарий plotterGui в действии
Дополнительную помощь могут оказать ориентированные на текстовый, а не на графический вывод версии этого сценария, имеющиеся в дереве примеров, которые выводят координаты точек окружности в поток stdout, а не отображают эти точки в графическом интерфейсе. Смотрите сценарииplotterText.py в каталоге часов. Ниже показано, что он выводит для случаев 4 и 12 точек на окружности шириной 400 точек. Формат вывода прост:
номер_точки: угол = (координатаX, координатаY)
Предполагается, что центр круга имеет координаты (0,0):
1 : 90.0 = (200, 0)
2 : 180.0 = (0, -200)
3 : 270.0 = (-200, 0)
4 : 360.0 = (0, 200)
1 : 30.0 = (100, 173)
2 : 60.0 = (173, 100)
3 : 90.0 = (200, 0)
4 : 120.0 = (173, -100)
5 : 150.0 = (100, -173)
6 : 180.0 = (0, -200)
7 : 210.0 = (-100, -173)
8 : 240.0 = (-173, -100)
9 : 270.0 = (-200, 0)
10 : 300.0 = (-173, 100)
11 : 330.0 = (-100, 173)
12 : 360.0 = (0, 200)
Инструменты Python для обработки чисел
Если вы сильны в математических расчетах настолько, чтобы разобраться в этом кратком уроке геометрии, вам, возможно, покажется интересным расширение NumPy для Python, предназначенное для поддержки численного программирования. В нем вы найдете такие объекты, как векторы, а также реализацию сложных математических операций, что превращает Python в инструмент решения научных задач, который эффективно реализует матричные операции и который сравним с MatLab. Расширение NumPy с успехом используется многими организациями, включая Ливерморскую и Лос-Аламосскую национальные лаборатории, - во многих случаях применение расширения NumPy позволяет писать на Python новые программы взамен устаревших программ на языке FORTRAN.
Расширение NumPy необходимо получать и устанавливать отдельно - смотрите ссылки на веб-сайте Python. В Интернете можно также найти родственные инструменты числовой обработки (например, SciPy), а также инструменты визуализации и трехмерной анимации (например, PyOpenGL, Blender, Maya, vtk и VPython). К моменту написания этих строк расширение NumPy (подобно многим числовым инструментам, опирающимся на его использование) официально доступно только для Python 2.X, однако версия, поддерживающая обе версии, 2.X и 3.X, уже находится в разработке53. Помимо модуля math, в языке Python имеется встроенная поддержка комплексных чисел для инженерных расчетов, в версии 2.4 появился тип десятичных чисел с фиксированной точностью, а в версии 2.6 и 3.0 была добавлена поддержка рациональных дробей. Подробности ищите в руководстве по стандартной библиотеке и в книгах, описывающих основы языка Python, таких как «Изучаем Python».
Чтобы понять, как эти точки отображаются на холст, нужно учесть, что ширина и высота окружности одинаковы и равны величине радиуса, умноженной на 2. Поскольку координаты холста tkinter (X,Y) начинаются с (0,0) в левом верхнем углу, центр окружности смещается в точку с координатами (ширина/2, ширина/2) - это будет точка, из которой вычерчиваются прямые. Например, в круге 400 на 400 центр холста будет в точке (200,200)54. Прямая в точку с углом 90 градусов (точка на правой стороне окружности) соединяет точку (200,200) и точку (400,200) - результат добавления к координатам центра координат точки (200,0), полученной для данного радиуса и угла. Линия вниз, к точке под углом 180 градусов, соединяет точки (200,200) и (200,400) после учета55 координат вычисленной точки (0,-200).
Этот алгоритм построения точек, применяемый в plotterGui, а также несколько констант масштабирования лежат в основе отображения циферблата аналоговых часов в PyClock. Если вам все же кажется, что это слишком сложно, предлагаю сначала сосредоточиться на реализации отображения цифровых часов. Аналоговые геометрические построения в действительности лишь являются расширением механизма отсчета времени, использующегося в обоих режимах отображения. В действительности в основе самих часов находится общий объект Frame, одинаковым образом посылающий встроенным объектам цифровых и аналоговых часов события изменения времени и размеров. Аналоговые часы - это прикрепленный виджет Canvas, умеющий рисовать окружности, а цифровые часы - просто прикрепленный фрейм Frame с метками, отображающими время.
Запуск PyClock
За исключением части, касающейся построения окружностей, программный код PyClock выглядит достаточно просто. Он рисует циферблат для отображения текущего времени и с помощью методов after вызывает себя 10 раз в секунду, проверяя, не перевалило ли системное время на следующую секунду. Если да, то перерисовываются секундная, минутная и часовая стрелки, чтобы показать новое время (либо изменяется текст меток цифровых часов). На языке создания графических интерфейсов это означает, что аналоговое изображение выводится на холсте, перерисовывается при изменении размеров окна и изменяется по запросу на цифровой формат.
В PyClock используется также стандартный модуль Python time, с помощью которого сценарий получает и преобразует системную информацию о времени в представление, необходимое для часов. В двух словах, метод onTimer получает системное время вызовом функции time.time, встроенного средства, возвращающего число с плавающей точкой, выражающее количество секунд, прошедших с начала эпохи, - точки начала отсчета времени на вашем компьютере. Затем с помощью функции time.localtime это время преобразуется в кортеж, содержащий значения часов, минут и секунд. Дополнительные подробности можно найти в самом сценарии и руководстве по библиотеке Python.
Проверка системного времени 10 раз в секунду может показаться излишней, но она гарантирует перемещение секундной стрелки вовремя и без рывков и скачков (события after синхронизируются не очень точно). На компьютерах, которыми я пользуюсь, это не влечет существенного потребления мощности ЦП. В Linux и в Windows PyClock незначительно расходует ресурсы процессора - в основном при обновлении экрана в аналоговом режиме, но не в событиях after.56
Чтобы минимизировать обновления экрана, PyClock перерисовывает только стрелки часов при переходе к следующей секунде - риски на циферблате перерисовываются только при начальном запуске и изменении размеров окна. На рис. 11.20 показан начальный циферблат PyClock в формате по умолчанию, который выводится при непосредственном запуске файла eloek.py.
Рис. 11.20. Аналоговые часы PyCloek по умолчанию
Линии, представляющие стрелки часов, имеют стрелку на одном конце, что определяется параметрами arrow и arrowshape объекта линии. Параметр arrow может принимать значение first, last, none или both; параметр arrowshape определяется как кортеж чисел, задающих длину стрелки на конце линии, общую длину линии и ее толщину.
Как и PyView, PyClock динамически удаляет и перерисовывает части изображения по требованию (то есть в ответ на связанные события) с помощью методов pack_forget и pack. Щелчок левой кнопкой мыши на часах изменяет формат вывода на цифровой путем удаления виджета аналоговых часов и вывода цифрового интерфейса. В результате получается более простой интерфейс, изображенный на рис. 11.21.
Рис. 11.21. Цифровые часы PyCloek
Такая цифровая форма может пригодиться, если вы хотите сберечь драгоценное место на экране и уменьшить использование ЦП (расходы на обновление изображения этих часов очень малы). Следующий щелчок левой кнопкой на часах снова переводит их в аналоговый режим отображения. При запуске сценария конструируются оба отображения -аналоговое и цифровое, но в каждый отдельный момент прикреплено только одно из них.
Щелчок правой кнопкой мыши на часах в любом режиме отображения вызывает появление или исчезновение прикрепленной метки, показывающей текущую дату в простом текстовом формате. На рис. 11.22 показан аналоговый интерфейс PyClock с меткой даты и размещенной в центре фотографией (в таком виде часы запускаются из панели запуска PyLauncher).
Рис. 11.22. Улучшенный графический интерфейс PyCloek с изображением
Изображение в центре на рис. 11.22 добавлено путем передачи объекта с соответствующими настройками конструктору объекта PyClock. Почти все особенности этого изображения могут быть настроены через атрибуты объектов PyClock - цвет стрелок, цвет меток, центральное изображение и начальный размер.
Так как сценарий PyClock в аналоговом режиме сам отображает фигуры на холсте, ему необходимо также самостоятельно обрабатывать события изменения размеров окна: когда окно уменьшается или увеличивается, нужно перерисовывать циферблат часов в соответствии с новыми размерами окна. Чтобы реагировать на изменение размеров окна, сценарий регистрирует событие с помощью метода bind; удивительно, но это событие не является событием менеджера окон, как событие для кнопки закрытия. Если растянуть окно PyClock, циферблат увеличится вместе с окном, - попробуйте растянуть окно часов, сжать или распахнуть его во весь экран на своем компьютере. Так как циферблат строится в квадратной системе координат, окно PyClock всегда растягивается в равном отношении по вертикали и горизонтали - если растянуть окно только по горизонтали или только по вертикали, циферблат не изменится.
В третьем издании этой книги в часы был добавлен таймер обратного отсчета: нажатие клавиши s или m выводит простой диалог ввода числа секунд или минут, соответственно, через которое должен сработать таймер. По истечении отсчета таймера выводится всплывающее окно, как показано на рис. 11.23, заполняющее весь экран в Windows. Я иногда использую этот таймер на курсах, которые я веду, - для напоминания мне и моим студентам, когда подходит время двигаться дальше (эффект получается особенно потрясающий, когда изображение экрана компьютера проецируется во всю стену!).
Рис. 11.23. Истек таймер PyCloek
Наконец, подобно PyEdit, часы PyClock можно запускать автономно или прикреплять и встраивать их в другие графические интерфейсы, где требуется вывести текущее время. При автономном запуске повторно используется модуль windows из предыдущей главы (пример 10.16) -чтобы установить значок и заголовок окна, а также добавить вывод диалога подтверждения перед выходом. Для упрощения запуска часов, выполненных в заданном стиле, существует вспомогательный модуль clockStyles, предоставляющий ряд объектов с настройками, которые можно импортировать, расширять в подклассах и передавать конструктору часов. На рис. 11.24 показано несколько часов разных размеров и стилей, подготовленных заранее, ведущих синхронный отсчет времени.
Запустите сценарий eloekstyles.py (или щелкните на кнопке PyClock в программе PyDemos, которая делает то же самое), чтобы воссоздать эту сцену с часами на своем компьютере. Во всех этих часах 10 раз в секунду проверяется изменение системного времени с использованием со-
Рис. 11.24. Несколько готовых стилей часов: eloekstyles.py
бытий after. При выполнении в виде окон верхнего уровня в одном и том же процессе все они получают событие от таймера из одного и того же цикла событий. При запуске в качестве независимых программ в каждой из них имеется собственный цикл событий. В том и другом случае их секундные стрелки дружно перемещаются раз в секунду.
Исходный программный код PyClock
Вся реализация PyClock находится в одном файле, за исключением предварительно подготовленных объектов с настройками стилей. Если посмотреть в конец примера 11.12, можно заметить, что объект часов можно создать, либо передав конструктору объект с настройками, либо определив параметры настройки в аргументах командной строки, как показано ниже (в этом случае сценарий просто сам создаст объект с настройками):
C:\...\PP4E\Gui\Clock> clock.py -bg gold -sh brown -size 300
Вообще говоря, для запуска часов этот файл можно выполнить непосредственно, с аргументами или без; импортировать его и создать объекты, используя объекты с настройками, чтобы часы выглядели более индивидуально; или импортировать и прикрепить его объекты к другим графическим интерфейсам. Например, PyGadgets из главы 10 запускает этот файл с параметрами командной строки, управляющими внешним видом часов.
Пример 11.12. PP4E\Gui\Cloek\eloek.py
##############################################################################
PyClock 2.1: часы с графическим интерфейсом на Python/tkinter.
В обоих режимах отображения, аналоговом и цифровом, могут выводить метку с датой, графические изображения на циферблате, изменять размеры и так далее. Могут запускаться автономно или встраиваться (прикрепляться) в другие графические интерфейсы, где требуется вывести текущее время.
Новое в версии 2.0: клавиши s/m устанавливают таймер, отсчитывающий секунды/ минуты перед выводом всплывающего сообщения; значок окна.
Новое в версии 2.1: добавлена возможность выполнения под управлением Python 3.X (2.X больше не поддерживается)
##############################################################################
from tkinter import *
from tkinter.simpledialog import askinteger import math, time, sys
##############################################################################
# Классы параметров настройки
##############################################################################
class ClockConfig:
# умолчания - переопределите в экземпляре или в подклассе
size = 200 # ширина=высота
bg, fg = ‘beige’, ‘brown’ # цвет циферблата, рисок
hh, mh, sh, cog = ‘black’, ‘navy’, ‘blue’, ‘red’ # стрелок, центра picture = None # файл картинки
class PhotoClockConfig(ClockConfig):
# пример комплекта настроек size = 320
picture = ‘../gifs/ora-pp.gif’
bg, hh, mh = ‘white’, ‘blue’, ‘orange’
##############################################################################
# Объект цифрового интерфейса
##############################################################################
class DigitalDisplay(Frame):
def __init__(self, parent, cfg):
Frame.__init__(self, parent) self.hour = Label(self) self.mins = Label(self) self.secs = Label(self) self.ampm = Label(self)
for label in self.hour, self.mins, self.secs, self.ampm: label.config(bd=4, relief=SUNKEN, bg=cfg.bg, fg=cfg.fg) label.pack(side=LEFT) # TBD: при изменении размеров можно было бы # изменять размер шрифта def onUpdate(self, hour, mins, secs, ampm, cfg):
mins = str(mins).zfill(2) # или ‘%02d’ % x
self.hour.config(text=str(hour), width=4) self.mins.config(text=str(mins), width=4) self.secs.config(text=str(secs), width=4) self.ampm.config(text=str(ampm), width=4)
def onResize(self, newWidth, newHeight, cfg):
pass # здесь ничего перерисовывать не требуется
##############################################################################
# Объект аналогового интерфейса
##############################################################################
class AnalogDisplay(Canvas):
def __init__(self, parent, cfg):
Canvas.__init__(self, parent,
width=cfg.size, height=cfg.size, bg=cfg.bg) self.drawClockface(cfg)
self.hourHand = self.minsHand = self.secsHand = self.cog = None
def drawClockface(self, cfg): # при запуске и изменении размеров if cfg.picture: # рисует овалы, картинку
try:
self.image = PhotoImage(file=cfg.picture) # фон except:
self.image = BitmapImage(file=cfg.picture) # сохранить ссылку imgx = (cfg.size - self.image.width()) // 2 # центрировать
imgy = (cfg.size - self.image.height()) // 2 # 3.x деление //
self.create_image(imgx+1, imgy+1, anchor=NW, image=self.image) originX = originY = radius = cfg.size // 2 # 3.x деление //
for i in range(60):
x, y = self.point(i, 60, radius-6, originX, originY) self.create_rectangle(x-1, y-1, x+1, y+1, fill=cfg.fg) # минуты for i in range(12):
x, y = self.point(i, 12, radius-6, originX, originY) self.create_rectangle(x-3, y-3, x+3, y+3, fill=cfg.fg) # часы self.ampm = self.create_text(3, 3, anchor=NW, fill=cfg.fg)
def point(self, tick, units, radius, originX, originY): angle = tick * (360.0 / units) radiansPerDegree = math.pi / 180
pointX = int( round( radius * math.sin(angle * radiansPerDegree) )) pointY = int( round( radius * math.cos(angle * radiansPerDegree) )) return (pointX + originX+1), (originY+1 - pointY)
def onUpdate(self, hour, mins, secs, ampm, cfg): # вызывается из
if self.cog: # обработчика событий
self.delete(self.cog) # таймера, перерисовывает
self.delete(self.hourHand) # стрелки, центр
self.delete(self.minsHand) self.delete(self.secsHand)
originX = originY = radius = cfg.size // 2 # 3.x деление //
hour = hour + (mins / 60.0)
hx, hy = self.point(hour, 12, (radius * .80), originX, originY)
mx, my = self.point(mins, 60, (radius * .90), originX, originY)
sx, sy = self.point(secs, 60, (radius * .95), originX, originY)
self.hourHand = self.create_line(originX, originY, hx, hy, width=(cfg.size * .04),
arrow=’last’, arrowshape=(25,25,15), fill=cfg.hh) self.minsHand = self.create_line(originX, originY, mx, my, width=(cfg.size * .03),
arrow=’last’, arrowshape=(20,20,10), fill=cfg.mh) self.secsHand = self.create_line(originX, originY, sx, sy, width=1,
arrow=’last’, arrowshape=(5,10,5), fill=cfg.sh) cogsz = cfg.size * .01
self.cog = self.create_oval(originX-cogsz, originY+cogsz,
originX+cogsz, originY-cogsz, fill=cfg.cog) self.dchars(self.ampm, 0, END) self.insert(self.ampm, END, ampm)
def onResize(self, newWidth, newHeight, cfg): newSize = min(newWidth, newHeight)
#print(‘analog onResize’, cfg.size+4, newSize) if newSize != cfg.size+4: cfg.size = newSize-4 self.delete(‘all’)
self.drawClockface(cfg) # onUpdate called next
##############################################################################
# Составной объект часов
##############################################################################
ChecksPerSec = 10 # частота проверки системного времени
class Clock(Frame):
def __init__(self, config=ClockConfig, parent=None):
Frame.__init__(self, parent) self.cfg = config
self.makeWidgets(parent) # дочерние виджеты компонуются методом pack, self.labelOn = 0 # но клиенты могут использовать pack или grid
self.display = self.digitalDisplay self.lastSec = self.lastMin = -1 self.countdownSeconds = 0
self.onSwitchMode(None)
self.onTimer()
def makeWidgets(self, parent):
self.digitalDisplay = DigitalDisplay(self, self.cfg) self.analogDisplay = AnalogDisplay(self, self.cfg) self.dateLabel = Label(self, bd=3, bg=’red’, fg=’blue’) parent.bind(‘’, self.onSwitchMode) parent.bind(‘’, self.onToggleLabel) parent.bind(‘’, self.onResize) parent.bind(‘’, self.onCountdownSec) parent.bind(‘’, self.onCountdownMin)
def onSwitchMode(self, event): self.display.pack_forget() if self.display == self.analogDisplay: self.display = self.digitalDisplay else:
self.display = self.analogDisplay self.display.pack(side=TOP, expand=YES, fill=BOTH)
def onToggleLabel(self, event): self.labelOn += 1 if self.labelOn % 2:
self.dateLabel.pack(side=BOTTOM, fill=X) else:
self.dateLabel.pack_forget()
self.update()
def onResize(self, event):
if event.widget == self.display:
self.display.onResize(event.width, event.height, self.cfg)
def onTimer(self):
secsSinceEpoch = time.time() timeTuple = time.localtime(secsSinceEpoch) hour, min, sec = timeTuple[3:6] if sec != self.lastSec: self.lastSec = sec
ampm = ((hour >= 12) and ‘PM’) or ‘AM’ # 0...23
hour = (hour % 12) or 12 # 12..11
self.display.onUpdate(hour, min, sec, ampm, self.cfg) self.dateLabel.config(text=time.ctime(secsSinceEpoch)) self.countdownSeconds -= 1 if self.countdownSeconds == 0:
self.onCountdownExpire() # таймер обратного отсчета
self.after(1000 // ChecksPerSec, self.onTimer) # вызывать N раз в сек.
# 3.x // целочисленное
# деление с усечением
def onCountdownSec(self, event):
secs = askinteger(‘Countdown’, ‘Seconds?’) if secs: self.countdownSeconds = secs
def onCountdownMin(self, event):
secs = askinteger(‘Countdown’, ‘Minutes’) if secs: self.countdownSeconds = secs * 60
def onCountdownExpire(self):
# ВНИМАНИЕ: только один активный таймер,
# текущее состояние таймера не отображается win = Toplevel()
msg = Button(win, text=’Timer Expired!’, command=win.destroy) msg.config(font=(‘courier’, 80, ‘normal’), fg=’white’, bg=’navy’) msg.config(padx=10, pady=10) msg.pack(expand=YES, fill=BOTH)
win.lift() # поднять над другими окнами
if sys.platform[:3] == ‘win’: # в Windows - на полный экран win.state(‘zoomed’)
##############################################################################
# Автономные часы
##############################################################################
appname = ‘PyClock 2.1’
# использовать новые окна Tk, Toplevel со своими значками и так далее from PP4E.Gui.Tools.windows import PopupWindow, MainWindow
class ClockPopup(PopupWindow):
def __init__(self, config=ClockConfig, name=’’):
PopupWindow.__init__(self, appname, name) clock = Clock(config, self) clock.pack(expand=YES, fill=BOTH)
class ClockMain(MainWindow):
def __init__(self, config=ClockConfig, name=’’):
MainWindow.__init__(self, appname, name) clock = Clock(config, self) clock.pack(expand=YES, fill=BOTH)
# для обратной совместимости: рамки окна устанавливаются вручную,
# передается родитель class ClockWindow(Clock):
def __init__(self, config=ClockConfig, parent=None, name=’’):
Clock.__init__(self, config, parent) self.pack(expand=YES, fill=BOTH) title = appname
if name: title = appname + ‘ - ‘ + name
self.master.title(title) # владелец=parent или окно по умолчанию self.master.protocol('WM_DELETE_WINDOW', self.quit)
##############################################################################
# Запуск программы
##############################################################################
if __name__ == ‘__main__’:
def getOptions(config, argv):
for attr in dir(ClockConfig): # заполнить объект с настройками
try: # из арг. ком. строки “-attr val”
ix = argv.index(‘-’ + attr) # пропустит внутр. __x__
except:
continue else:
if ix in range(1, len(argv)-1):
if type(getattr(ClockConfig, attr)) == int: setattr(config, attr, int(argv[ix+1])) else:
setattr(config, attr, argv[ix+1])
#config = PhotoClockConfig() config = ClockConfig() if len(sys.argv) >= 2:
getOptions(config, sys.argv) # clock.py -size n -bg ‘blue’...
#myclock = ClockWindow(config, Tk()) # при автономном выполнении
#myclock = ClockPopup(ClockConfig(), ‘popup’) # родителем является корневое myclock = ClockMain(config) # окно Tk
myclock.mainloop()
И наконец, в примере 11.13 приводится модуль, выполняемый сценарием PyDemos, - в нем определяется несколько стилей часов и производится запуск одновременно семи экземпляров часов, прикрепляемых к новым окнам верхнего уровня для создания демонстрационного эффекта (хотя на практике обычно достаточно иметь на экране одни часы, даже мне!).
Пример 11.13. PP4E\Gui\Cloek\eloekStyles.py
# предопределенные стили часов
from clock import *
from tkinter import mainloop
gifdir = ‘../gifs/’ if __name__ == ‘__main__’: from sys import argv if len(argv) > 1:
gifdir = argv[1] + ‘/’
class PPClockBig(PhotoClockConfig):
picture, bg, fg = gifdir + ‘ora-pp.gif’, ‘navy’, ‘green’
class PPClockSmall(ClockConfig): size = 175
picture = gifdir + ‘ora-pp.gif’
bg, fg, hh, mh = ‘white’, ‘red’, ‘blue’, ‘orange’
class GilliganClock(ClockConfig): size = 550
picture = gifdir + ‘gilligan.gif’
bg, fg, hh, mh = ‘black’, ‘white’, ‘green’, ‘yellow’
class LP4EClock(GilliganClock): size = 700
picture = gifdir + ‘ora-lp4e.gif’ bg = ‘navy’
class LP4EClockSmall(LP4EClock): size, fg = 350, ‘orange’
class Pyref4EClock(ClockConfig):
size, picture = 400, gifdir + ‘ora-pyref4e.gif’ bg, fg, hh = ‘black’, ‘gold’, ‘brown’
class GreyClock(ClockConfig):
bg, fg, hh, mh, sh = ‘grey’, ‘black’, ‘black’, ‘black’, ‘white’ class PinkClock(ClockConfig):
bg, fg, hh, mh, sh = ‘pink’, ‘yellow’, ‘purple’, ‘orange’, ‘yellow’
class PythonPoweredClock(ClockConfig):
bg, size, picture = ‘white’, 175, gifdir + ‘pythonPowered.gif’
if __name__ == ‘__main__’: root = Tk() for configClass in [
ClockConfig,
PPClockBig,
#PPClockSmall,
LP4EClockSmall,
#GilliganClock,
Pyref4EClock,
GreyClock,
PinkClock,
PythonPoweredClock
]:
ClockPopup(configClass, configClass.__name__)
Button(root, text=’Quit Clocks’, command=root.quit).pack() root.mainloop()
При запуске этот сценарий создает множество часов различного вида, как показано на рис. 11.24. Объекты конфигурации поддерживают большое число параметров. Судя по семи парам часов, отображаемых на экране, пришло время перейти к последнему примеру.
PyToe: виджет игры в крестики-нолики
И наконец, в завершение главы немного развлечемся. В нашем последнем примере, PyToe, на языке Python реализована программа игры в крестики-нолики с привлечением искусственного интеллекта. Большинству читателей, вероятно, знакома эта простая игра, поэтому я не стану останавливаться на ее описании. В двух словах: игроки поочередно ставят свои метки в клетках игрового поля, пытаясь занять целиком строку, колонку или диагональ. Победителем является тот, кому удалось сделать это первым.
В PyToe позиции на игровом поле помечаются щелчком мыши, а одним из игроков является программа на языке Python. Само игровое поле реализовано в виде простого графического интерфейса на основе tkinter. По умолчанию PyToe создает игровое поле размером 3 на 3 (стандартный вариант игры), но можно настроиться на игру произвольного размера N на N.
Когда приходит очередь компьютера сделать ход, с помощью алгоритмов искусственного интеллекта (ИИ) оцениваются возможные ходы и ведется поиск в дереве этих ходов и возможных ответов на них. Это довольно простая задача для игровых программ, а эвристики, применяемые для выбора ходов, несовершенны. Все же PyToe обычно достаточно сообразителен, чтобы победить на несколько ходов раньше, чем пользователь.
Запуск PyToe
Графический интерфейс PyToe реализован в виде фрейма с прикрепленными к нему метками и привязкой обработчиков событий щелчков мыши к этим меткам для перехвата ходов пользователя. Текст метки устанавливается равным метке игрока после каждого хода компьютера или пользователя. Здесь также повторно был использован класс GuiMaker, который мы создали ранее в предыдущей главе (пример 10.3), для создания простой полосы меню в верхней части окна (но без панели инструментов внизу, так как PyToe оставляет ее дескриптор пустым). По умолчанию пользователь ставит крестики («X»), а PyToe - нолики («O»). На рис. 11.25 показано игровое поле сценария PyToe, запущенного с помощью PyGadgets, и диалог с информацией о результатах игры; игра отображена на стадии, когда у сценария есть два хода, ведущие к победе.
Рис. 11.25. PyToe обдумывает путь к победе
На рис. 11.26 изображен всплывающий диалог со справочной информацией о параметрах командной строки PyToe. Есть возможность определить цвет и размер для меток игрового поля, игрока, делающего первый ход, метку пользователя («X» или «О»), размер игрового поля (переопределяющий размер 3 на 3 по умолчанию) и стратегию выбора хода для компьютера (например, «Minimax» выполняет поиск выигрышей и поражений в дереве ходов, а «Expert1» и «Expert2» используют статические эвристические функции оценки).
Используемая в PyToe технология ИИ интенсивно использует ЦП, и в зависимости от игровой ситуации компьютер тратит на определение следующего хода разное время, но скорость ответа компьютера зависит в основном от скорости компьютера. Задержка, связанная с выбором хода на игровом поле 3 на 3, составляет доли секунды для любой стратегии выбора хода «-mode».
На рис. 11.27 изображен альтернативный вариант настройки PyToe (сценарий PyToe был запущен непосредственно из командной строки без аргументов) в момент, когда программа только что выиграла у меня. Хотя по сценам игры, отобранным для этой книги, этого не скажешь, но при установке некоторых режимов выбора хода мне все же удается иногда выигрывать. На игровом поле большего размера и на более
Рис. 11.26. Диалог со справочной информацией о параметрах командной строки PyToe
сложных уровнях алгоритм выбора хода, реализованный в PyToe, становится еще более эффективным.
Исходный программный код PyToe (внешний)
PyToe является крупной системой, для знакомства с которой предполагается наличие некоторой подготовки в области ИИ, но в отношении графического интерфейса, в сущности, не демонстрирует ничего ново-
Рис. 11.27. Альтернативный вариант настройки
го. Кроме того, она была написана для выполнения под управлением Python 2.X более десяти лет тому назад, и хотя она и была перенесена на Python 3.X для этого издания, некоторые ее части было бы лучше реализовать заново. Отчасти по этой причине, но в основном из-за того, что я уже исчерпал объем страниц, отведенных на эту главу, я не привожу здесь исходный программный код, а отсылаю вас к пакету с примерами. За деталями реализации PyToe обращайтесь к следующим двум файлам из пакета примеров:
PP4E\Ai\TieTaeToe\tietaetoe.py
Сценарий оболочки верхнего уровня PP4E\Ai\TieTaeToe\tietaetoe_lists.py Основная реализация
Если вы решитесь заглянуть в эти сценарии, могу посоветовать обратить внимание на структуру данных, используемую для представления состояния игрового поля, которая составляет наибольшую сложность. Если вы разберетесь, каким образом моделируется игровое поле, то остальная часть реализации станет вполне понятна.
Например, в варианте, основанном на списках, для представления состояния игрового поля используется список списков, а также простой словарь из виджетов полей ввода для графического интерфейса, индексируемый координатами игрового поля. Очистка игрового поля после игры заключается в простой очистке исходных структур данных, как показано в следующем фрагменте программного кода из указанных выше примеров:
def clearBoard(self):
for row, col in self.label.keys(): self.board[row][col] = Empty self.label[(row, col)].config(text=’ ‘)
Аналогично выбор хода, по крайней мере, в случайном режиме, заключается в том, чтобы найти пустую ячейку в массиве, представляющем игровое поле, и записать метку компьютера в нее и передать в графический интерфейс (атрибут degree хранит размер игрового поля):
def machineMove(self):
row, col = self.pickMove() self.board[row][col] = self.machineMark self.label[(row, col)].config(text=self.machineMark)
def pickMove(self): empties = [] for row in self.degree: for col in self.degree:
if self.board[row][col] == Empty: empties.append((row, col)) return random.choice(empties)
Наконец, проверка состояния конца игры сводится к просмотру строк, колонок и диагоналей по следующей схеме:
def checkDraw(self, board=None): board = board or self.board for row in board: if Empty in row: return 0
return 1 # не пусто: ничья или победа
def checkWin(self, mark, board=None): board = board or self.board for row in board:
if row.count(mark) == self.degree: # проверка горизонтали return 1
for col in range(self.degree):
for row in board: # проверка вертикали
if row[col] != mark: break else:
return 1
for row in range(self.degree): # проверка первой диагонали
col = row # row == col
if board[row][col] != mark: break else:
return 1
for row in range(self.degree): # проверка второй диагонали
col = (self.degree-1) - row # row+col = degree-1
if board[row][col] != mark: break else:
return 1
def checkFinish(self):
if self.checkWin(self.userMark): outcome = "You’ve won!” elif self.checkWin(self.machineMark): outcome = ‘I win again :-)’ elif self.checkDraw():
outcome = ‘Looks like a draw’
Другой программный код, связанный с выбором хода, в основном просто проводит другие виды анализа структуры данных игрового поля или генерирует новые состояния для поиска в дереве ходов и контрхо-дов.
В том же каталоге находятся родственные файлы, реализующие альтернативные схемы поиска и оценки ходов, различные представления игрового поля и так далее. За дополнительными сведениями об оценке ходов в игре и о поиске в целом обращайтесь к учебникам по ИИ. Это интересный материал, но слишком сложный, чтобы его можно было достаточным образом осветить в данной книге.
Что дальше
На этом завершается часть данной книги, посвященная графическим интерфейсам, но рассказ о графических интерфейсах на этом не заканчивается. Если вам необходимы дополнительные знания о графических интерфейсах, посмотрите примеры использования tkinter, которые будут встречаться дальше в книге и описаны в начале этой главы. PyMailGUI, PyCalc, а также внешние примеры PyForm и PyTree - все они представляют собой дополнительные примеры реализации графических интерфейсов. В следующей части книги мы также узнаем, как создавать интерфейсы пользователя, выполняемые в веб-броузерах, -совершенно другая идея, но еще один вариант конструирования простых интерфейсов.
Имейте в виду, что даже если ни один из рассмотренных в этой книге примеров графического интерфейса не похож на тот, который вам нужно запрограммировать, тем не менее вам уже были представлены все необходимые конструктивные элементы. Создание более крупного графического интерфейса для вашего приложения в действительности заключается в иерархическом расположении составляющих его виджетов, представленных в этой части книги.
Например, сложный интерфейс может быть реализован в виде совокупности радиокнопок, списков, ползунков, текстовых полей, меню и других виджетов, располагаемых во фреймах или в сетках для получения требуемого внешнего вида. Сложный графический интерфейс может быть дополнен всплывающими окнами верхнего уровня, а также независимо выполняемыми программами с графическим интерфейсом, связь с которыми поддерживается через механизмы взаимодействий между процессами (IPC), такими как каналы, сигналы и сокеты.
Кроме того, крупные компоненты графического интерфейса могут быть реализованы в виде классов Python, прикрепляемых или расширяемых всюду, где требуется аналогичный инструмент интерфейса, - важным примером таких компонентов может служить редактор PyEdit и его использование в PyView и PyMailGUI. Подойдите к делу творчески, и набор виджетов tkinter и Python обеспечит вам практически неограниченное число структур.
Помимо данной книги, посмотрите также документацию по библиотеке tkinter, представленную в главе 7, и книги, перечисленные на сайте Python http://www.python.org и в Интернете в целом. Наконец, если мне удалось вас увлечь библиотекой tkinter, еще раз хочу порекомендовать загрузить пакеты, о которых было сказано в главе 7, особенно Pmw, PIL, Tix и ttk (в настоящее время Tix и ttk входят в состав стандартной библиотеки), и поэкспериментировать с ними. Такие инструменты наращивают мощь арсенала tkinter, позволяя создавать более сложные графические интерфейсы за счет небольшого объема программного кода.
Алфавитный указатель
Символы
* (звездочка), групповой символ, 245 /, прямой слеш, 148 \\ обратный слеш, 148 |, оператор создания канала, 183
A
after, метод
возможности, 752 недостатки, 757
планирование вызовов функций,
747, 756
append, метод списков, 45, 52 Array, объект (multiprocessing, пакет), 350
ASCII, кодировка, 224 askyesno, функция, 567
B
BDFL (Benevolent Dictator for Life), 82 bell, метод, 753
BigGui, клиентская демонстрационная программа, 781 bind, метод
возможности, 528 связывание событий, 529 BitmapImage, класс виджетов, 549, 633 BooleanVar, класс, 599 Button, класс виджетов, 511, 549 command, параметр, 603 bytearray, тип объектов, 141 bytes, строковый тип объектов, 141, 696, 701
C
Canvas, класс виджетов, 550, 634, 683 config, метод, 713 create_polygon, метод, 712 create_, метод, 713 delete, метод, 723 find_closest, метод, 714, 726
itemconfig, метод, 713 move, метод, 714 tag_bind, метод, 726 tkraise, метод, 713 update, метод, 756 xscrollcommand, параметр, 681 xview, метод, 680 yscrollcommand, параметр, 681 yview, метод, 680 базовые операции, 710 возможности, 709 идентификаторы объектов, 713 и миниатюры изображений, 718 перемещение объектов, 724 программирование, 711 прокрутка холстов, 715 система координат, 711 события, 722 создание объектов, 712 создание произвольной графики, 100 теги объектов, 714 cat, команда, 161 cd, команда, 171 cgi, модуль, 104
escape, функция, 111 CGI-сценарии
urllib, модуль, 109 веб-серверы, 106 основы, 103
предложения по усовершенствованию, 122
строки запроса, 109 форматирование текста ответа, 110 Checkbutton, класс виджетов, 549, 602 command, параметр, 603 и переменные, 605 chmod, команда, 57, 105 comparedirs, функция, 424 Connection, объект (multiprocessing, пакет), 349
csh, язык командной оболочки, 204 Cygwin, система
ветвление процессов, 262, 268
стстемные инструменты определение, 129
D
Dabo, построитель графических интерфейсов, 487 db.keys, метод, 53 dialog, модуль, 580 dialogTable, модуль, 572, 576 dirdiff, модуль, 425 dir, команда
пример использования, 157 шаблоны имен файлов, 244 dir, функция, 135 __doc__, атрибут, 135
форматирование вывода, 135 doctest, фреймворк, 416 DoubleVar, класс, 599
E
EBCDIC, кодировка символов, 222 EditVisitor, класс, 454 Entry, класс виджетов, 549, 593 xscrollcommand, параметр, 681 xview, метод, 680 yscrollcommand, параметр, 681 yview, метод, 680
и ассоциированные переменные, 599 компоновка в формах ввода, 595 программирование, 594
F
FileVisitor, класс, 449 find, команда, 436 find, модуль, 437 flash, метод, 753 Flex, фреймворк, 488 FLI, формат файлов, 763 fnmatch, модуль, 440 fork, функция, 261 Frame, класс виджетов, 549
добавление нескольких виджетов, 531
прикрепление виджетов к фреймам, 533
разработка графических интерфейсов, 89
G
getopt, модуль, 173 glob, модуль, 133, 245 glob, функция, 246, 254
обработка имен файлов в Юникоде, 254
возможности, 64 кнопки с изображениями, 638 поиск в деревьях каталогов, 436 сканирование каталогов, 378 grep, команда, 436
grid, менеджер компоновки, 597, 653, 726
изменение размеров в сетках, 736 объединение колонок и рядов, 737 преимущества, 727 реализация растягивания виджетов, 734
создание таблиц, 738 сочетание с pack, 731 сравнение с pack, 729 формы ввода, 727 GuiMaker, инструмент
BigGui, клиентская демонстрационная программа, 781 описание, 773
поддерживаемые классы, 779 программный код самотестирования, 779
протоколы подклассов, 778 GuiMixin, 676 GuiMixin, инструмент, 767
вспомогательные подмешиваемые классы, 769
GuiStreams, инструмент, 797
перенаправление для сценариев архивирования, 802
GUI (графический интерфейс пользователя), 479
возможности создания, 483 добавление кнопок, 511 добавление нескольких виджетов, 530
добавление обработчиков, 511 собственных, 514 запуск программ, 481, 501 менеджеры компоновки, 500 настройка виджетов с помощью классов, 537
повторно используемые компоненты GUI, 540
приемы программирования, 497 программа «Hello World», 497, 508 создание виджетов, 499
H
help, функция, 136
I
IDLE, графический интерфейс
проблема начального позиционирования в текстовом редакторе, 879 функциональные возможности, 495 ImageTk, модуль, 718 __import__, функция, 621 Input, класс, 194 input, функция, 180 interact, функция, 182 IntVar, класс, 599 io.BytesIO, класс, 196 io.StringIO, класс, 196 IronPython, 487
J
JavaFX, платформа, 488 Jython, 487
K
kill, команда оболочки, 343
L
Label, виджет
pack, метод, 508 Label, класс виджетов, 549 LabelFrame, класс виджетов, 765 lambda-выражения, как обработчики событий, 515
launchmodes, модуль, 369, 626 Listbox, класс виджетов, 550, 676 curselection, метод, 680 insert, метод, 678 runCommand, метод, 679 xscrollcommand, параметр, 681 xview, метод, 680 yscrollcommand, параметр, 681 yview, метод, 680 программирование, 678 ls, команда
шаблоны имен файлов, 244
M
mainloop, функция (tkinter), 498 Menu, класс виджетов, 549 add_cascade, метод, 660 описание, 660
Menubutton, класс виджетов, 550, 665 Message, класс виджетов, 549, 592 messagebox, модуль, 567 MFC (Microsoft Foundation Classes), библиотека, 489 mimetypes, модуль, 470
проигрывание медиафайлов, 464 mmap, модуль, 318 MPEG, формат файлов, 763 multiprocessing, модуль, 134, 318 multiprocessing, пакет, 343
дополнительные инструменты, 359 запуск независимых программ, 357 и глобальная блокировка интерпретатора (GIL), 305 ограничения, 360 правила использования, 348 процессы и блокировки, 346 реализация, 348
N
__name__, переменная, 143 NumPy, расширение, 955
O
open, функция, 207, 210
поддерживаемые режимы, 218 политика буферизации, 219 Optionmenu, класс виджетов, 668 optparse, модуль, 173 ORM (Object Relational Mapper объектно-реляционное отображение) другие разновидности баз данных, 82 os, модуль, 134, 150
abspath, функция, 156 chdir, функция, 152, 168 chmod, функция, 237 chown, функция, 237 close, функция, 326 dup2, функция, 326 dup, функция
перенаправление, 203 environ, словарь, 167
доступ к переменным оболочки, 175
изменение значений переменных оболочки, 177 environ, функция, 163 execle, функция, 266 execlpe, функция, 266 execlp, функция, 163, 265, 266 execl, функция, 266 execve, функция, 266 execvpe, функция, 266 execvp, функция, 266, 326 execv, функция, 266 _exit, функция, 307 fdopen, функция, 236, 321
fork, функция, 163, 261, 326 перенаправление, 203 getcwd, функция, 152, 167 getenv, функция, 179 getpid, функция, 152, 263 kill, функция, 343 linesep, константа, 153 listdir, функция, 254
вывод имен файлов с символами Юникода, 387
обработка имен файлов в Юникоде, 254
обход одного каталога, 247 сканирование деревьев каталогов, 252
соединение файлов, 397 lseek, функция, 233 mkdir, функция, 164 mkfifo, функция, 164, 332 open, функция, 163, 233, 234 pathsep, константа, 153 pipe, функция, 163, 326
и дескрипторы файлов, 319 перенаправление, 203 popen, функция,156, 158
выполнение команд оболочки для получения списка файлов, 243 и стандартные потоки ввода-вывода, 167 код завершения, 309 обмен данными с командами оболочки, 158
перенаправление потоков ввода-вывода, 198, 199 putenv, функция, 179 read, функция, 233 remove, функция, 164, 237 rename, функция, 237 sep, константа, 153 spawnve, функция, 362 spawnv, функция, 163, 178, 362 startfile, функция, 366, 368 stat, функция, 164, 239 system, функция, 156, 158, 309 unlink, функция, 238 walk, функция, 164, 254 и функция find, 438 обработка имен файлов в Юникоде, 254
сканирование деревьев каталогов, 249, 379
write, функция, 233 выполнение команд оболочки из сценариев, 156
завершение программ, 307 инструменты администрирования, 152
инструменты для работы с файлами, 233
константы переносимости, 153 os.path, модуль, 134 exists, функция, 153 getsize, функция, 153 isdir, функция, 153 isfile, функция, 153 join, функция, 154 split, функция, 154 инструменты, 152, 153 Output, класс, 194
P
Pack, класс, 508 pack, менеджер компоновки сочетание с grid, 731 сравнение с grid, 729 PanedWindow, класс виджетов, 765 Pexpect, пакет, 134, 202 PhotoImage, класс виджетов, 549, 633, 670
pickle, модуль
возможности, 61
сохранение каждой записи в отдельном файле, 64
PIL (Python Imaging Library), 641
отображение других типов графических изображений, 643 создание миниатюр изображений, 647
PIL, расширение, 483
функциональные возможности, 494 Pipe, объект (multiprocessing, пакет), 349
Pmw, библиотека, 483, 491
функциональные возможности, 493 popen, функция, 156, 158
выполнение команд оболочки для получения списка файлов, 243 и стандартные потоки ввода-вывода, 167
код завершения, 309 обмен данными с командами оболочки, 158
перенаправление потоков ввода-вывода, 198, 199 print, функция, 136
и стандартные потоки ввода-вывода, 180
перенаправление, 197
pprint, модуль
вывод содержимого баз данных, 53 Process, класс (multiprocessing, пакет), 346
pty, модуль, 330 py2exe, инструмент, 484 PyClock, программа, 951 запуск, 957
исходный программный код, 961 описание, 951 точки на окружности, 951 PyDemos, панель запуска, 846, 860 PyDoc, система, 136 PyDraw, программа рисования, 941 запуск, 941
исходный программный код, 943 описание, 941
PyEdit, текстовый редактор встраивание в PyView, 931 диалоги, 865, 872 другие примеры и рисунки, 871 запуск, 863
запуск программного кода, 866 изменения в версии 2.0, 872 диалог выбора шрифта, 872 модуль с настройками, 872, 873 неограниченное количество отмен и возвратов операций редактирования, 872, 873 перечень, 872
изменения в версии 2.1, 874
изменение модального режима диалогов, 874 новый диалог Grep, 875 перечень, 874
проверка при завершении, 875 исходный программный код обзор, 888
файл с настройками пользователя, 889
файл с основной реализацией, 892 файлы запуска, 891 меню и панель инструментов, 864 несколько окон, 867 новое в версии 2.1
исправление проблемы начального позиционирования, 878 поддержка Юникода, 880 проверка при завершении, 886 улучшения в операции запуска программного кода, 879 описание, 862 поддержка Юникода, 706 пример, реализация, 682
PyGadgets, панель запуска, 852, 860 PyGame, пакет, 763 PyGTK, пакет, 486 PyInstaller, инструмент, 484 pyjamas, фреймворк, 488 PyMailGUI, программа
помещение обработчиков событий в очередь, 817 PyObjC,библиотека, 489 PyPhoto, просмотр изображений, 917 запуск, 918
исходный программный код, 922 обзор, 917 PyQt, пакет, 486 pySerial, интерфейс, 134 PythonCard, построитель графических интерфейсов, 487
PYTHONPATH, переменная окружения определение, 176 синтаксические ошибки, 147 Python, язык программирования происхождение имени, 69 сторонние расширения, 134 PyToe, виджет игры, 969 запуск, 969
исходный программный код, 971 описание, 969 PyTree, программа, 718 PyView, программа просмотра изображений, 929 запуск, 929
исходный программный код, 935 описание, 929 PyWin32, пакет обзор, 489
Q
queue, модуль, 134, 293
аргументы или глобальные переменные, 295
завершение программ с дочерними потоками выполнения, 295 запуск сценариев, 297 и потоки выполнения, 272 Queue, объект (multiprocessing, пакет), 350
R
Radiobutton, класс виджетов, 549, 602 command, параметр, 607 и ассоциированные переменные, 602 и переменные, 609 описание, 607
random, модуль, 101, 638 repeater, метод, 753 ReplaceVisitor, класс, 456
S
Scale, класс виджетов, 549 command, параметр, 614 from_, параметр, 615 get/set методы, 614 label, параметр, 615 length, параметр, 615 orient, параметр, 615 resolution, параметр, 615 showvalue, параметр, 616 tickinterval, параметр, 615 to, параметр, 615 и переменные, 617 описание, 614 scanner, функция, 239 Scrollbar, класс виджетов, 550, 676 возможности, 676 компоновка полос прокрутки, 681 программирование, 680 ScrolledCanvas, класс, 715 ScrolledList, класс компонента, 677 ScrolledText, класс компонента, 684, 690, 694
search_all, сценарий, 448 searcher, функция, 446 SearchVisitor, класс, 449, 471 select, модуль, 134 ShellGui, инструмент, 785 диалоги ввода, 792 добавление графических интерфейсов к инструментам командной строки, 789
классы наборов утилит, 788 обобщенный графический интерфейс инструментов оболочки, 785 сценарии командной строки, 789 shelve, модуль close, метод, 66 open, метод, 66 веб-интерфейс, 111 возможности, 66 интерфейс командной строки, 83 формат словаря словарей, 54 shutil, модуль, 134
дополнительная информация, 238 signal, модуль, 134, 340 alarm, функция, 342 pause, функция, 341 signal, функция, 341
Silverligh, фреймворк, 488 SimpleEditor, класс возможности, 691 наследование, 694 ограничения, 695 поддержка буфера обмена, 693 socket, модуль, 133, 335 socketserver, модуль, 107 sorted, функция, 187 Spinbox, класс виджетов, 765 SqlAlchemy, система, 82 SQLObject, система, 82 start, команда, 162, 366 string, модуль константы, 139 StringVar, класс, 599 struct, модуль
pack, функция, 228 unpack, функция, 229 анализ двоичных данных, 228 str, тип объектов, 141 и виджет Text, 696 особенности использования, 702 subprocess, модуль, 134, 156, 159, 178 Popen, объект, 165 код завершения, 309, 311 перенаправление потоков ввода-вывода, 198, 200 SumGrid, класс, 743 sys, модуль
argv, параметр, 167, 171 exc_info, функция, 149 exit, функция, 306 getdefaultencoding, функция, 222 getrefcount, функция, 149 modules, словарь, 148 platform, строка, 146 setcheckinterval, функция, 302 завершение программ, 306 завершение программы, 511 и аргументы командной строки, 171 и стандартные потоки ввода-вывода, 180
источники документации по модулям, 135
и текущий рабочий каталог, 169 платформы и версии, 146 путь поиска модулей, 146, 169, 381 сведения об исключениях, 149 таблица загруженных модулей, 148 sys.stderr, поток вывода ошибок буферизация, 327 особенности, 167 перехват потока, 197 sys.stdin
и взаимодействие с пользователем, 188
особенности, 167
перенаправление в объекты Python, 192
символ конца файла, 182 sys.stdout
особенности, 167
перенаправление в объекты Python, 192
перенаправление в функции print, 197
T
Tcl, apsr программирования, 551 tempfile, модуль, 134 Text, класс виджетов, 550 get, метод, 688 mark_set, метод, 688 tag_add, метод, 688 tag_bind, метод, 707 tag_config, метод, 707 tag_delete, метод, 689 tag_remove, метод, 689 более сложные операции с текстом, 707
возможности, 683 и Юникод, 695, 701 метки, 688
операции редактирования текста, 689
поддержка индексирования, 687 программирование, 685 теги, 688
Thread, класс, 288 _thread, модуль, 134, 274
allocate_lock, функция, 281 start_new_thread, функция, 275 альтернативные приемы, 285 запуск нескольких потоков выполнения, 277
ожидание завершения порожденных потоков выполнения, 282 основы использования, 275 синхронизация доступа, 280 способы реализации потоков выполнения, 276
threading, модуль, 134, 287
завершение потоков выполнения в графических интерфейсах, 816 синхронизация доступа, 290 способы реализации потоков выполнения, 289 time, модуль, 134
sleep, функция, 263, 756, 757, 760 timeit, модуль, 134 Tix, расширение, 491
функциональные возможности, 493 tkinter, библиотека, 483
createfilehandler, функция, 749 документация, 975 tkinter, модуль after, метод, 300
альтернативные приемы использования, 502
документация, 492 менеджеры компоновки, 500 настройка заголовка окна, 506 обзор, 490
основы использования, 498 особенности, 87 поддержка расширений, 492 рограммная структура, 496 Tk, библиотека, 551 Tk, класс виджетов, 549, 560, 660 destroy, метод, 561, 563 iconbitmap, метод, 564 iconify, метод, 564 maxsize, метод, 564 menu, параметр, 565 protocol, метод, 563 quit, метод, 563 title, метод, 564 withdraw, метод, 564 Toplevel, класс виджетов, 549, 559, 660 deiconify, метод, 754 destroy, метод, 563 iconbitmap, метод, 564 iconify, метод, 564, 755 lift, метод, 755 maxsize, метод, 564 menu, параметр, 565 protocol, метод, 563 quit, метод, 563 state, метод, 755 title, метод, 564 tkraise, метод, 755 withdraw, метод, 564, 754 автоматизация создания окон, 805 и пользовательские диалоги, 581 независимые окна, 624 traceback, модуль, 149 try/finally, инструкция, 212 ttk, библиотека, 483, 491
функциональные возможности, 494
U
unittest, фреймворк, 416 Unix, платформа
и выполняемые сценарии, 174 перенаправление потоков ввода-вывода, 183 urllib, модуль, 109
поддержка CGI-сценариями, 109
V
Value, объект (multiprocessing, пакет), 350
W
webbrowser, модуль, 464, 468 Windows
и потоки ввода-вывода стандартные, 181 перенаправление, 183 пути к каталогам, 148 with, инструкция, 213 wxPython, система, 485
Z
ZODB, система, особенности, 82
А
анализ
аргументов командной строки, 172 двоичных данных, 228 анимация
другие эффекты, 762 и графика, 763 и потоки выполнения, 762 простые приемы, 755 циклы time.sleep, 756, 757, 760 анонимные каналы
буферизация потоков вывода, 327 взаимоблокировки, 327 двунаправленный обмен данными, 324
дескрипторы файлов, 319
обертывание объектами, 321 и потоки выполнения, 323 определение, 317, 318 основы использования, 319 аргументы
и глобальные переменные, 295, 518 и потоки выполнения, 285 командной строки анализ, 172 доступ, 167
ассоциированные переменные, 599, 602
Б
базы данных
вывод содержимого с помощью модуля pprint, 53
дополнительная информация, 81 безопасность и веб-интерфейсы, 115 буферизация потока вывода Pexpect, пакет, 202 pty, модуль, 330 взаимоблокировки, 327 и завершение программ, 310 буфер обмена, использование, 693
В
веб-интерфейсы
CGI-сценарии, 102 shelve, модуль, 111 urllib, модуль, 109 дополнительные инструменты, 102 запуск веб-сервера, 106 предложения по усовершенствованию, 122
строки запроса, 109 форматирование текста ответа, 110 веб-страницы
создание для переадресации, 403 сценарий генератора страниц, 405 файлы шаблонов, 404 ветвление процессов, 259, 260
os.exec, функция, формы вызова, 265 fork/exec, комбинация функций, 264 получение кода завершения, 312 порождение дочерней программы, 266
взаимодействия между процессами, 316 multiprocessing, модуль, 318, 349 socket, модуль, 133 анонимные каналы, 317, 319 двунаправленный обмен данными, 324
именованные каналы, 317, 331 обзор, 316 сигналы, 317, 340 сокеты, 317 виджеты, 592
after_cancel, метод, 748 after_idle, метод, 748 after, метод, 747, 756 anchor, параметр, 536 bd, параметр, 557 config, метод, 507, 555 cursor, параметр, 557 focus, метод, 750 grab, метод, 750 grid_forget, метод, 754 menu, параметр, 565 pack_forget, метод, 754
padx, параметр, 557
pady, параметр, 557 state, параметр, 557 update_idletasks, метод, 749 update, метод, 749 wait_variable, метод, 750 wait_visibility, метод, 750 wait_window, метод, 750 добавление без сохранения, 508 добавление нескольких виджетов,
530
дополнительные виджеты, 764 и диалоги, 566
изменение размеров, 504, 531 использование якорей, 536 компоновка элементов ввода в формах, 595 настройка
внешнего вида, 554 меток, 555 параметров, 506 с помощью классов, 537 обрезание, 531 окна верхнего уровня, 558 перенаправление потоков ввода-вывода, 797
порядок компоновки, 533 привязка событий, 585 прикрепление к фреймам, 532, 619 растягивание, 512 скрытие и перерисовка, 754 создание, 499 стандартизация
внешнего вида, 538 поведения, 538 вложенные структуры словари, 51 списки, 52
вспомогательные подмешиваемые классы, 769
входные файлы, 881 вывод
в файлы, 210
имен файлов с символами Юникода, 387
результатов диалогов, 576 выполнение программ
автоматизированный запуск, 473 обмен данными, 629 с графическим интерфейсом, 626
Г
Гвидо ван Россум (Guido van Rossum), 482
глобальная блокировка интерпретатора (Global Interpreter Lock, GIL), 302 API потоков выполнения на языке C, 304
multiprocessing, пакет, 305 атомарные операции, 304 интервал переключения потоков выполнения, 303 и потоки выполнения, 272 глобальная замена в деревьях каталогов, 456
глобальные переменные
multiprocessing, пакет, 352 и аргументы, 518 против аргументов, 295 графические интерфейсы
динамическая перезагрузка обработчиков, 803
добавление к сценариям командной строки, 825
дополнительная информация, 974 запуск программ, 626 и потоки выполнения, 298, 750, 816, 839
к инструментам командной строки, 785
независимые окна, 624 приемы программирования, 810 прикрепление к фреймам, 619 графический интерфейс пользователя (GUI, ГИП), 87, 479, 483 добавление кнопок, 511 добавление нескольких виджетов, 530
добавление обработчиков, 511 добавление собственных обработчиков, 514
дополнительные инструменты, 100 запуск программ, 481, 501 менеджеры компоновки, 500 настройка виджетов с помощью классов, 537 ООП, 89
повторно используемые компоненты GUI, 540
получение ввода от пользователя, 92 приемы программирования, 497 программа^^ World, 497, 508 пути усовершенствования, 98 создание виджетов, 499 групповые символы, 245
Д
двоичные файлы
struct, модуль, анализ с помощью, 228
и Юникод, 703 определение, 208, 220 произвольный доступ, 230 деревья каталогов
глобальная замена, 456 копирование, 417 обход, 249
подсчет строк исходного программного кода, 458 поиск, 435
различий, 425 редактирование файлов, 454 сканирование, 249, 378 сравнение, 422
текстовый редактор PyEdit, 875 удаление файлов с байт-кодом, 442 дескрипторы файлов
обертывание объектами файлов, 236, 321
диалоги, 566
PyEdit, текстовый редактор, 865, 872, 874
Quit, кнопка, 569 выбор шрифта, 872 вывод результатов, 576 динамический выбор цвета, 578 пользовательские, 581 разновидности, 566 стандартные, 567 динамический выбор цвета, 578 добавление виджетов без их сохранения, 508
дочерний процесс, 261 порождение, 266
З
завершение программ, 306 os, модуль, 307 sys, модуль, 306
с дочерними потоками выполнения, 295
закрытие файлов, 211 записи
pickle, модуль, сохранение записи с помощью, 61, 64 shelve, модуль, сохранение записи с помощью, 66 в текстовых файлах, 55 представление, 43 запись в файлы, 211 запросы, поддержка CGI-сценариями, 109
запуск программ
и потоки выполнения, 271 с графическим интерфейсом, 501
И
изображения, 633
в панелях инструментов, 672 миниатюры, 647, 718 имена полей (списки), 46 именованные каналы, 331 области применения, 334 определение, 319 основы использования, 332 индексы, 687
инструменты ветвления процессов, 260 инструменты для работы с каталогами обзор, 243
обработка имен файлов в Юникоде, 254
обход деревьев каталогов, 249 обход одного каталога, 243 инструменты для работы с файлами в модуле os, 233
встроенные объекты файлов, 209 вывод в файлы, 210 двоичные файлы, 208, 220 модель объекта файла, 207 обзор, 206
сканеры файлов, 239 текстовые файлы, 207, 220 фильтры файлов, 241 инструменты командной строки, 785 инструменты обработки чисел, 955 инструменты реализации игровых программ, 763
интерфейс командной строки к хранилищу shelve, 83 интерфейс передачи сообщений (Message Passing Interface, MPI), 260 источники документации по модулям, 134
итераторы, 164
объектов файлов, 242 файлов, 216
К
каналы
multiprocessing, пакет, 351 анонимные, 317-319 именованные, 317, 331
и сокеты, 842 реализация каналов, 318 реализация графического интерфейса в виде отдельной программы, 835 каталоги
веб-интерфейсы, 115 обход, 243, 448
отображение всех изображений в каталоге, 645
отчет о различиях, 433 поиск расхождений, 422 сканирование, 377 классы, 814 GUI
повторно используемые компоненты, 540
расширение классов компонентов, 544
альтернативные, 77 другие разновидности баз данных, 81 контейнеры, 546 наследование, 74 настройка виджетов с помощью классов, 537 программирование, 71 реализация возможности сохранения, 79
реализация поведения, 73 кнопки Quit, 569
выбор случайной картинками, 637 добавление, 511 отложенные вызовы, 516 фиксированного размера, 654 коды завершения, 308
и ветвление процессов, 312 и потоки выполнения, 314 команд оболочки, 308 команды оболочки find, 436
subprocess, модуль, выполнение с помощью, 159 выполнение, 157 обмен данными, 158 ограничения, 161 определение, 156 конструкторы, специализация, 77 контейнерные классы, 546 копирование деревьев каталогов, 417
М
медиафайлы, проигрывание, 464 менеджеры компоновки, 500 grid, 726, 729
expand и fill, параметры, 534 pack, 729
изменение размеров виджетов, 504 определение, 500 порядок компоновки, 533 размещение, 505 менеджеры контекста
и закрытие файлов, 212 и потоки выполнения, 285 и фильтры файлов, 242 меню
PyEdit, в редакторе, 864 Menubutton, виджет, 665 автоматизация создания, 675, 773 на основе фреймов, 665 окон верхнего уровня, 660 определение, 660 отображение в окнах, 670 метки
bg, параметр, 555 expand, параметр, 556 fg, параметр, 555 fill, параметр, 556 font, атрибут, 556 height, атрибут, 556 width, атрибут, 556 настройка, 555 миниатюры изображений
и холсты с прокруткой,718 создание, 647
модули, источники документации, 134
Н
наследование
SimpleEditor, класс, 694 и классы, 74 независимые окна, 624 независимые программы, 337 запуск, 357
О
обертывание дескрипторов объектами файлов, 236, 321
обработчики исключений и закрытие файлов, 212
обработчики обратного вызова, 496
обработчики событий
lambda-выражения, 515 аргументы и глобальные переменные, 518 добавление, 511
динамическая перезагрузка, 803 добавление собственных обработчиков, 514
дополнительные протоколы, 528 объекты вызываемых классов, 527 отложенные вызовы, 516 передача данных, 576 помещение в очередь, 817 привязка событий, 588 связанные методы, 525 связывание событий, 529 обрезание виджетов, 531 объекты вызываемых классов как обработчики событий, 527 объекты файлов, 321 объемлющая области видимости, 519 окна
PyEdit, текстовый редактор, 867 автоматизация создания, 805 вывод по требованию, 826 независимые, 624 консоли DOS
как избежать появления, 502 скрытие и перерисовка, 754 с меню и панелью инструментов, 670 ООП (объектно-ориентированное программирование), 69 другие разновидности баз данных, 81 классы, 71 наследование, 74
при разработке графических интерфейсов, 89
реализация возможности сохранения, 79
реализация поведения, 73 реструктуризация программного кода, 75
открытие файлов, 210, 218 открытое программное обеспечение, 860 отчет о различиях между деревьями каталогов, 433 очереди
помещение данных, 813 помещение обработчиков событий, 817
П
панели инструментов
PyEdit, в текстовом редакторе, 864 PyDemos, 846, 860 PyGadgets, 852, 860 автоматизация создания, 773 изображения, 672 отображение в окнах, 670 параллельная обработка
multiprocessing, пакет, 343 ветвление процессов, 260 другие системные инструменты, 374 запуск программ, 362 и взаимодействия между процессами, 316
и завершение программ, 306 определение, 259 переносимый модуль запуска программ, 368
потоки выполнения, 270 переменные
Checkbutton, класс виджетов, 605 ассоциированные, 599, 602 глобальные, 295, 352 и переключатели, 609 и ползунки, 617
рекомендации по использованию, 612
переменные оболочки доступ, 167 изменение, 177 определение, 175 получение значений, 176 подсчет строк исходного программного кода, 458 поиск
в деревьях каталогов, 435 различий между деревьями каталогов, 425
полиморфизм, 192 полнофункциональные интернетприложения, 488
полосы прокрутки, компоновка, 681 порожденные программы, 178 порядок следования байтов, 228 потоки ввода-вывода io.BytesIO, класс, 196 io.StringIO, класс, 196 буферизация потока вывода, 310 и взаимодействие с пользователем, 187 потоки ввода-вывода
перенаправление в виджеты, 797 перенаправление в объекты Python, 192
перенаправление в файлы/програм-мы, 181
перенаправление в функции print, 197
перенаправление с помощью функции os.popen, 198, 199 перенаправление с помощью функции модуля subprocess, 198, 200 перехват потока stderr, 197 стандартные потоки, 167, 180 потоки выполнения, 270
PyEdit, текстовый редактор, 876 queue, модуль, 293 _thread, модуль, 274 threading, модуль, 287 завершение, 816 и анимация, 762 и анонимные каналы, 323 и глобальная блокировка интерпретатора, 302
и графические интерфейсы, 298, 750, 839
порождение, 259 преимущества, 270 преобразование строк, 140 привязка
событий, 585, 724 тегов, 707
программирование на Python
«Hello World», программа, 497 веб-интерфейс, 102 графический интерфейс, 86 другие разновидности баз данных, 81 интерфейс командной строки, 83 классы, 71 наследование, 74
обеспечивающее повторное использование, 630
объектно-ориентированное программирование, 69
получение ввода от пользователя, 92 реализация возможности сохранения, 79
реализация поведения, 73 реструктуризация программного кода, 75
сохранение записей на длительное время, 54
программы
независимые, 337, 357 перенаправление стандартных потоков ввода-вывода, 181 производительность
и потоки выполнения, 270 сохранение миниатюр в файлах, 652 произвольный доступ к данным в фай-лах,230
пути к каталогам и символы обратного слеша, 148
Р
разделяемая память, 318 mmap, модуль, 318 multiprocessing, пакет, 352 разрезание файлов, 391, 399 расширение методов, 76 редактирование файлов в деревьях каталогов, 454
резервные копии, проверка, 431 реструктуризация программного кода альтернативные классы, 77 расширение методов, 76 специализация конструкторов, 77 формат отображения, 76 родительский процесс, 261
С
связанные методы, 814 определение, 90
связанные методы как обработчики событий, 525
связывание событий, 529 сигналы, 340
символы конца строки, 138 в текстовых файлах, 224 синхронизация
_thread, модуль, 280 threading, модуль, 290 и потоки выполнения, 272 система координат, холсты, 711 системные инструменты, 258 os, модуль, 150 sys, модуль, 146
разработка системных сценариев,
133
системные программы
автоматизированный запуск программ, 473
вывод имен файлов с символами Юникода, 387 другие примеры, 462
копирование деревьев каталогов, 417 с помощью классов, 460 обход каталогов, 448 подсчет строк исходного программного кода, 458 поиск
в деревьях каталогов, 435 различий между деревьями каталогов, 425
проигрывание медиафайлов, 464 разрезание и объединение файлов, 390
сканирование
всего компьютера, 382 деревьев каталогов, 378 каталогов, 377 пути поиска модулей, 379 создание веб-страниц для переадресации, 403
сравнение деревьев каталогов, 422 сценарии регрессивного тестирования, 408
системные сценарии, разработка bytes, тип объектов, 141 дополнительные справочники, 145 источники документации по моду-лям,134 обзор, 132
операции с файлами, 142 постраничный вывод строк документации, 135
руководства по библиотекам Python, 144
способы использования программ, 143
строковые методы, 138
сценарий постраничного вывода, 137
Юникод, 141
системных приложений область, 129 сканеры файлов, 239 сканирование
всего компьютера, 382 дерева каталогов, 378 каталогов, 377 пути поиска модулей, 379 скомпилированные двоичные файлы, 99 словарей итераторы, 53 словари
вложенные структуры, 51 примеры реализации записей, 48 словарей, 52 списки словарей, 50 способы создания, 49
события
от мыши, 588 привязка, 585, 724 связывание, 529 совместно используемая память и потоки выполнения, 270 соглашения об именовании файлов, 56 соединение файлов, 395, 399 создание веб-страниц для переадресации, 403 сокеты, 335
и каналы, 842
и независимые программы, 337 области применения, 339 основы, 335
реализация графического интерфейса в виде отдельной программы, 830
сохранения возможность, реализация, 79
списки
append, метод, 45, 52 вложенные структуры, 52 имена полей, 46
примеры реализации записей, 43 словарей, 50
сравнение деревьев каталогов, 422 ссылки на объекты
и обработчики событий, 803 стандартные диалоги, 567 стандартные потоки ввода-вывода доступ, 167 определение, 180
перенаправление в файлы/програм-мы, 181 строки
Text, виджет, 686 запроса, 109
определение позиции, 686 преобразование, 140 текст Юникода, 697 форматирование, 115 строковые методы join, метод, 155 основы, 138 сценарии
queue, пример использования модуля, 297
start, использование команды, 367 Unix, особенности на платформе, 174 вспомогательные сценарии, 60 выполнение команд оболочки из сценариев, 156
записи/чтения данных, 57 и аргументы командной строки, 171 и переменные оболочки, 175 и стандартные потоки ввода-вывода, 180
и текущий рабочий каталог, 168 первые замечания, 57 регрессивного тестирования, 408 сценарий постраничного вывода, 137 пример, 137 тестовые данные, 55
Т
таймеры, 300
теги
объектов, 714 привязка, 707 текст, 688
текстовые файлы, 207
вспомогательные сценарии, 60 и Юникод, 207, 695 преобразование символов конца строки, 224
сценарий записи/чтения данных, 57 тестовый сценарий создания данных, 55
текущий рабочий каталог, 168 доступ, 167
и командные строки, 170 и путь поиска модулей, 168
точки на окружности, 951
Ф
файлов объекты
close, метод, 209, 211 readlines, метод, 215 readline, метод, 215, 216 read, метод, 215 seek, метод, 230 writelines, метод, 211 write, метод, 211 встроенные, 209 вывод в файлы, 210 гарантированное закрытие, 212 другие режимы открытия файлов, 218
запись, 211
методы чтения-записи, 209 модель объекта файла, 207 обертывание дескрипторов, 236 определение, 207 открытие, 210, 218 чтение из файлов, 214
файлы, 55
закрытие, 212
и текущий рабочий каталог, 168 открытие, 218
перенаправление стандартных потоков ввода-вывода, 181 разработка системных сценариев, 142
разрезание, 391, 399 редактирование файлов в деревьях каталогов, 454 с байт-кодом, удаление, 442 соглашения об именовании, 56 соединение, 395, 399 текст Юникода, 700 чтение, 214
фильтры и сканирование файлов, 241 формы ввода, 595, 727 компоновка, 595 основы работы с сеткой, 728 функции и потоки выполнения, 271 функции-генераторы, 249
Х
холсты
базовые операции, 710 вытягивание фигур, 723 идентификаторы объектов, 713 и миниатюры изображений, 718 определение, 709 очистка, 723
перемещение объектов, 724 программирование, 711 прокрутка, 715 система координат, 711 события, 722 создание объектов, 712 теги объектов, 714
Ц
циклы
time.sleep, функция, 756, 757, 760 и потоки выполнения, 285
Ю
Юникод, 141, 221
PyEdit, поддержка в текстовом редакторе, 877, 878, 880 Text, виджет, 695 вывод имен файлов, 387 и текстовые файлы, 207 обработка имен файлов, 254, 256
1
Марк Лутц «Изучаем Python», 4 издание, СПб.: Символ-Плюс, 2010.
2
Я являюсь автором всех трех книг, упомянутых в этом разделе, и это дает мне возможность контролировать их содержимое и избегать повторений. Это также означает, что как автор я стараюсь не комментировать многие другие книги о Python, которые могут оказаться для вас весьма полезными и в которых могут обсуждаться темы, не рассматривающиеся ни в одной из моих книг. Упоминания об этих книгах вы найдете в Интернете или в других источниках информации о Python. Все три мои книги отражают опыт 13 лет преподавания Python и путь, пройденный от момента выхода первого издания книги «Programming Python» в 1995 году. (Здесь вполне уместно поместить фотографию убеленного сединами путешественника-иссле-дователя.)
3
Я вполне серьезно. На курсах по изучению Python, которые я веду уже довольно давно, я постоянно использовал имя «Bob Smith» (Боб Смит), возраст 40,5 лет и должности «developer» (разработчик) и «manager» (руководитель) для создания фиктивной записи в базе данных, пока на курсах в Чикаго я не встретил студента с именем Боб Смит (Bob Smith), которому было 40,5 лет, и который занимал должности разработчика и руководителя. В жизни иногда случаются курьезы.
4
Они могут проникать и в ваше подсознание. Новички Python иногда описывают такое явление, как «сны на Python» (попробуйте дать упрощенную интерпретацию по Фрейду...).
5
Д. Бизли «Python. Подробный справочник», СПб.: Символ-Плюс, 2010.
6
Я написал последний справочник в качестве замены справочному приложению, имевшемуся в первом издании этой книги. Он задуман как дополнение к книге, которую вы читаете, а его последнее издание также может служить переправой для читателей, использующих версию Python 2.X. Как уже говорилось в предисловии, книга, которую вы сейчас держите, является учебником, а не справочником, поэтому вам, вероятно, придется в конечном счете найти какой-нибудь источник справочной информации (однако я настолько самонадеян, что предлагаю выбрать мой справочник).
7
Может случиться, что Python видит переменную окружения PYTHONPATH иначе, чем вы. Синтаксическая ошибка в файлах настройки системной оболочки может испортить значение PYTHONPATH, даже если она кажется вам нормальной. Например, в Windows при наличии пробелов вокруг = в команде DOS set в файле с настройками (например, set NAME = VALUE) в переменную NAME в действительности будет записана пустая строка, а не VALUE!
8
Инструкция на языке Python exec(open(file).read()) тоже выполняет код программного файла, но внутри того же процесса, который ее вызвал. В этом отношении она похожа на операцию импортирования, но по своему действию она больше похожа на операцию вставки содержимого файла в вызывающую программу в том месте, где стоит вызов exec (если явно не передаются словари глобального или локального пространства имен). В отличие от операции импортирования, функция exec читает и выполняет программный код файла без всяких проверок (один и тот же файл можно выполнить несколько раз в одном процессе); при выполнении файла не создается объект модуля; и, если функции явно не передаются словари пространств имен, операции присваивания в программном коде файла могут затирать переменные в области видимости, где находится вызов exec. За дополнительными подробностями обращайтесь к руководству по библиотеке Python.
9
Так происходит по умолчанию. Некоторые инструменты запуска программ позволяют сценариям передавать в дочерние программы значения переменных окружения, отличные от своих собственных. Например, функция os.spawnve по своему поведению напоминает функцию os.spawnv, но принимает в виде аргумента дополнительный словарь, представляющий окружение оболочки, которое должно быть передано запускаемой программе. Некоторые разновидности os.exec* (имена которых оканчиваются на «е») тоже принимают явное определение окружения. Подробнее о формате вызова os.exec* рассказывается в главе 5.
10
Обратите внимание, что функция input возбуждает исключение, сигнализируя о конце файла, однако методы чтения файлов просто возвращают в этом случае пустую строку. Поскольку input также отсекает символ конца строки, то при чтении пустой строки из файла также возвращается пустая строка, поэтому исключение совершенно необходимо, чтобы определить конец файла. Методы чтения файлов сохраняют символ конца строки и возвращают для пустых строк символ \n , а не “”. Это одно из отличий прямого чтения из sys.stdin от функции input. Последняя также принимает в качестве аргумента строку приглашения к вводу, которая автоматически выводится перед приемом входных данных.
11
Например, для обработки каналов, описываемых в главе 5. В Python функция os.pipe возвращает два файловых дескриптора, которые можно обрабатывать средствами модуля os или обертывать их объектами файлов с помощью функции os.fdopen. При использовании файловых инструментов из модуля os данные через каналы передаются в виде строк байтов, а не текста. Кроме того, низкоуровневые механизмы могут также потребоваться для работы с некоторыми файлами устройств.
12
Похожие инструменты вы найдете также в модуле shutil, в стандартной библиотеке Python. Он содержит высокоуровневые инструменты для выполнения операций копирования и удаления файлов и многие другие. В главе 6 мы дополнительно напишем инструменты, позволяющие выполнять операции над каталогами, такие как сравнение, копирование и поиск, после того как познакомимся с инструментами для работы с каталогами далее в этой главе.
13
В действительности функция glob просто использует стандартный модуль fnmatch для поиска имен по шаблону; смотрите описание fnmatch в примере модуля find в главе 6.
14
Для этого в Windows нужно щелкнуть на кнопке Пуск (Start), выбрать пункт меню Все программы (AH Programs) ^ Стандартные (Accessories) ^ Служебные (System TooLs) ^ Системный монитор (Resource Monitor) и перейти на монитор ЦП (CP^/За-грузка ЦП (Processor Usage) (аналогичную картину можно наблюдать на вкладке Производительность (Performance) в окне Диспетчера задач (Task Manager) ). Когда я писал эту сноску, на моем ноутбуке график не подымался выше 10% (по крайней мере, пока я не ввел while 1: pass в окне консоли интерактивного сеанса Python...).
15
По крайней мере, в текущей реализации Python функция os.fork в сценарии Python фактически копирует процесс интерпретатора (если взглянуть на список процессов, то после ветвления в нем можно будет найти два процесса Python). Но поскольку интерпретатор Python заботится обо всем, что касается работы сценария, можно считать вызов функции fork непосредственным копированием программы. Собственно, так и будет, если скомпилировать сценарии на языке Python в двоичный машинный код.
16
В примерах использования модуля _thread в этой книге теперь везде используется функция start_new_thread. По исторически сложившимся причинам эта функция доступна также под именем thread.start_new, но в будущих версиях Python этот синоним может быть удален. В версии Python 3.1 оба имени по-прежнему доступны, но в документации, которая выводится функцией help, функция start_new объявлена устаревшей. Другими словами, ее не следует использовать, если вы беспокоитесь о будущем (и что должно учитываться в книге!).
17
Однако их нельзя использовать для непосредственной синхронизации процессов. Поскольку процессы более независимы, им обычно требуются ме
18
ханизмы блокировки, более долговременные и внешние по отношению
19
к программам. Вызов функции os.open, представленной в главе 4, с флагом
20
O_EXCL позволяет сценариям блокировать и разблокировать доступ к файлам и потому может считаться идеальным инструментом блокировки для использования в процессах. Обратите также внимание на инструменты син
21
хронизации в модулях multiprocessing и threading, а также прочитайте раздел
22
организации взаимодействий между процессами далее в этой главе, где представлены другие универсальные приемы синхронизации.
23
Пояснение для программистов Java: блокировки и условные переменные в языке Python являются отдельными объектами, а не чем-то присущим всем объектам, а класс Thread в языке Python не обладает всеми характеристиками, которые есть у одноименного класса в языке Java. Дополнительные детали можно найти в руководстве по библиотеке Python.
24
Понятия «клиент» и «сервер» будут разъяснены в части книги, посвященной приложениям для Интернета. Там взаимодействие будет организовано с помощью сокетов (с которыми мы встретимся далее в этой главе и которые грубо можно назвать двунаправленными каналами связи между программами, выполняющимися на компьютерах, соединенных сетью, или на одном и том же компьютере), но модель обмена информацией в целом остается схожей. Именованные каналы (fifo), описываемые ниже, лучше соответствуют модели клиент/сервер, поскольку доступ к ним может осуществляться произвольными, несвязанными процессами (выполнять ветвление при этом не требуется). Но как мы увидим, модели сокетов повсеместно используются большинством протоколов сценариев для Интернета - сообщения электронной почты, например, являются, по сути, всего лишь форматированными строками, передаваемыми между программами через сокеты со стандартными номерами портов, зарезервированными для протоколов обмена электронной почтой.
25
Сходная проблема, связанная с функцией print, описывается в главе 14, где предлагается обходное решение, позволяющее предотвратить аварийное завершение программы в случае вывода трассировочной информации в поток стандартного вывода порожденными программами. В отличие от проблемы, описываемой здесь, та проблема, похоже, не связана с выводом символов Юникода, которые могут оказаться непечатаемыми в окне командной оболочки, а отражает еще один недостаток механизма вывода в стандартный поток вывода в версии Python 3.1, который может быть исправлен к моменту, когда вы будете читать эти строки. Смотрите также описание переменной окружения PYTH0NI0ENC0DING, с помощью которой можно переопределить кодировку, используемую по умолчанию для стандартного потока вывода.
26
Необходимо отметить, что эту историю я рассказывал еще во втором издании книги, которое вышло в 2000 году. За последние десять лет гибкие диски практически закончили путь, который уже прошли параллельные порты и динозавры. Кроме того, запись CD или DVD выполняется не так долго, как прежде; в настоящее время появились новые возможности, такие как флешки огромного объема, беспроводные сети и даже простая электронная почта; и, естественно, у меня дома теперь стоят более совершенные компьютеры. А что касается моих детей - некоторые из них уже выросли (хотя и сохранили некоторую обратную совместимость с ними прежними).
27
Как оказывается, команды zip, gzip и tar также можно заменить программным кодом на языке Python. В стандартной библиотеке имеется модуль gzip, который предоставляет инструменты чтения и записи файлов gzip, имена которых обычно имеют расширение .gz. Он служит в Python общим эквивалентом стандартных утилит командной строки gzip и gunzip. Этот встроенный модуль в свою очередь использует модуль zlib, в котором реализовано gzip-совместимое сжатие данных. В последних версиях Python присутствуют также модуль zipfile для обработки архивов в формате ZIP (zip - это формат архивных файлов и сжатия, а gzip - это алгоритм сжатия) и модуль tarfile, позволяющий сценариям работать с tar-архивами. Подробности ищите в руководстве по библиотеке Python.
28
Это случается. Действительно, почти все, кто проводит в киберпространстве значительное время, могут рассказать пару ужасных историй. Моя состоит в следующем: несколько лет тому назад я пользовался услугами провайдера, который полностью отключился от Интернета на несколько недель из-за проникновения в систему защиты бывшего служащего. Что еще хуже, персональная электронная почта не просто не работала, но накапливавшиеся сообщения были утеряны навсегда. Если ваше существование зависит от электронной почты и Веб в такой же мере, как мое, вы хорошо представляете, какую панику может вызвать подобное отключение.
29
Среди разработчиков, проведших в гетто Unix достаточное время, операция поиска в файлах часто носит разговорное название «grepping».
30
Термин «набор графических элементов» означает объекты, используемые для создания привычных элементов интерфейса «укажи-и-щелкни» - кнопок, ползунков, полей ввода и так далее. В библиотеке tkinter определяются классы Python, соответствующие всем графическим элементам, к которым вы привыкли в графических интерфейсах. Помимо графических элементов в tkinter присутствуют также инструменты для решения иных задач, таких как планирование событий, ожидание появления данных в сокетах и так далее.
31
В данной книге «Windows» относится к интерфейсу Microsoft Windows, распространенному на PC, а «X Window» относится к интерфейсу X11, чаще всего встречающемуся на платформах Unix и Linux. Эти два интерфейса в целом привязаны к платформам Microsoft и Unix (и Unix-подобным), соответственно. Существует возможность выполнения X Window поверх операционной системы Microsoft и эмуляции Windows в Unix и Linux, но эта возможность используется достаточно редко. Чтобы добавить туману, замечу, что Mac OS X обеспечивает поддержку tkinter в X Window и в родной графической подсистеме Aqua, в дополнение к платформозависимой поддержке cocoa (хотя обычно особенности OS X не слишком выделяются в коктейле Unix-подобных систем).
32
Формально вызов mainloop возвращает управление сценарию только после выхода из цикла событий. Обычно это происходит при закрытии главного окна, но может случиться и в ответ на явный вызов метода quit, который завершает вложенный цикл событий, но оставляет окно открытым. Почему это имеет значение, вы узнаете в главе 8.
33
Совет: Как уже предлагалось выше, при вводе программного кода, использующего библиотеку tkinter, в интерактивной оболочке, вам может не потребоваться вызывать функцию mainloop, чтобы отобразить виджеты. Это необходимо делать в текущей версии IDLE, но в простом интерактивном сеансе, запущенном в окне консоли, этого может не потребоваться. В любом случае управление будет возвращено интерактивной оболочке, как только вы закроете созданное окно. Примечательно, что если явно создать виджет главного окна вызовом конструктора Tk() и присоединить к нему виджеты (как описывается ниже), вам придется вызвать его снова после закрытия окна, иначе окно приложения не появится.
34
Если рассмотреть главный файл tkinter в библиотеке исходного программного кода Python (в настоящее время Lib\tkinter\__init__.py), можно заме
тить, что имена модулей, не предназначенных для экспорта, начинаются с одного символа подчеркивания. Python не копирует такие имена при обращении к модулю в операторе from в формате *. Модуль с константами называется constants.py и находится в том же самом каталоге пакета, хотя с течением времени имя и местоположение его может измениться*
35
В действительности именованные аргументы впервые появились в Python, чтобы сделать более очевидными такие вызовы tkinter. Внутри интерпретатора именованные аргументы передаются как словарь (который можно получить, указав аргумент вида **name в инструкции def объявления функции), поэтому обе схемы аналогичны по реализации. Но они отличаются количеством символов, которые нужно ввести и проверить.
36
Бывшим программистам на языке Tcl, возможно, будет интересно узнать, что Python не только внутренне строит дерево виджетов, но и использует его для автоматического создания строк путей к виджетам, которые приходится вручную писать в Tcl/Tk (например, .panel.row.cmd). Python использует адреса объектов классов виджетов, помещает их в компоненты пути и сохраняет полученные пути в дереве виджетов. Например, метке, прикрепленной к контейнеру, может быть присвоено внутреннее имя, такое как .8220096.821 9408. Однако вас это не должно волновать. Просто создавайте и связывайте объекты графических элементов, передавая их родителей, и предоставьте Python самому работать с путями, опираясь на дерево объектов. Дополнительные сведения об отношениях Tk и tkinter приводятся в конце главы.
37
Технически после изменения размеров окна этапы добавления просто выполняются заново. Но поскольку это означает, что для графических элементов, добавляемых последними, останется недостаточно места, это равносильно тому, что элементы, добавленные последними, обрезаются первыми.
38
Если заглянуть в исходные тексты модуля tkinter (главным образом в файл __init__.py в каталоге Lib\tkinter), можно заметить, что многие из создаваемых им имен атрибутов начинаются с одного символа подчеркивания, что делает их уникальными; другие имена - нет, поскольку они могут быть полезны за пределами реализации tkinter (например, self.master, self. children). Странно, но библиотека tkinter по-прежнему не использует трюк с «псевдочастными» атрибутами Python, имена которых начинаются с двух символов подчеркивания, что влечет за собой автоматическое добавление имени содержащего их класса и локализации для создающего класса. Если библиотека tkinter будет когда-нибудь переписана так, чтобы использовать эту особенность, конфликты имен в подклассах виджетов будут происходить гораздо реже. Большинство атрибутов классов виджетов являются методами, предназначенными для использования в клиентских сценариях; имена, начинающиеся с одного символа подчеркивания, могут использоваться тоже, но при этом вероятность конфликтов имен все-таки ниже.
39
Всемирно известный производитель товаров для детского творчества, в том числе цветных карандашей, красок, мелков, фломастеров и пр. - Прим. ред.
40
Видимо, у автора установлены какие-то дополнительные драйверы от производителя мыши. В стандартной поставке Windows такая настройка отсутствует. - Прим. ред.
41
Исторический анекдот: в устаревшей в данное время версии tkinter, поставлявшейся с Python 1.3, можно было также устанавливать и извлекать значения переменных, обращаясь к ним как к функциям с аргументами или без (например, var(value) и var()). В настоящее время вместо этого нужно вызывать методы set и get переменных. По неустановленным причинам функциональная форма вызова прекратила работать годы назад, хотя ее все еще можно встретить в старом программном коде на языке Python (и в первых изданиях, по крайней мере, одной книги по языку Python, выпущенной издательством O’Reilly). Если исправление, выполненное из эстетических соображений, приводит к неработоспособности существующего программного кода, можно ли его считать исправлением?
42
Не я автор данной картинки - она появилась в качестве баннера на сайтах для разработчиков, таких как slashdot.com, когда в 1999 году вышло первое издание «Learning Python». Она породила такую волну возмущения приверженцев Perl, что издательство O’Reilly в конце концов было вынуждено убрать эту рекламу. Хотя возможно, именно поэтому она оказалась в этой книге.
43
Использована цитата из фильма Стенли Кубрика «Сияние». - Прим. ред.
44
О технике анимации рассказывается в конце данного обзора. Поскольку в область отрисовки холста можно встраивать другие виджеты, собственная координатная система делает холсты идеальными инструментами для реализации графических интерфейсов, дающих пользователям возможность создания других графических интерфейсов путем перетаскивания встроенных виджетов по холсту - весьма полезное применение холста, которое мы изучили бы в этой книге, будь у меня несколько сотен лишних страниц.
45
Я решил обратить ваше внимание на это, поскольку считаю, что понимание опасности позволит в будущем избежать ее - если процесс Python обладает правом удаления файлов, передача функции eval строки с программным
кодом__import__(‘ os’ ). system(‘ rm -rf *’ ) в Unix приведет к вызову команды
оболочки, которая удалит все файлы в текущем каталоге и во вложенных в него подкаталогах (в Windows аналогичный эффект можно получить с помощью команды ‘ rmdir /S /Q . ’). Не делайте этого! Чтобы увидеть менее опасное и более полезное применение этой особенности, введите выражение__import__(‘ math’ ). pi в одну из ячеек таблицы - щелчок на кнопке Sum
вычислит значение pi (3.14159). Также безопасно будет передать функции
eval выражение “__import__(‘os’ ). system( ‘ di r’)” в интерактивном сеансе. Все
вышесказанное относится и к встроенной функции exec - функция eval выполняет строки выражений, функция exec - инструкции, а выражения являются инструкциями (но не наоборот). Разумеется, обычный пользователь графического интерфейса едва ли введет подобный программный код случайно, особенно если этот пользователь вы сами, но будьте внимательны!
46
Игра-симулятор пинг-понга, появившаяся в 1972 году и ставшая прародительницей таких известных игр, как Breakout и Arkanoid. - Прим. перев.
47
Самая известная, пожалуй, компания Eve Online по производству игровых программ использует Python для создания сценариев и значительной доли функциональности - не только для серверной, но и для клиентской части. Она использует версию Stackless Python, чтобы обеспечить высокую отзывчивость интерфейса при большом количестве параллельно выполняющихся заданий. Из других известных компаний, использующих Python, можно назвать производителя игры Civilization IV и ныне несуществующую Origin Systems (в последних сообщениях говорилось, что их игра Ultima Online II должна была использовать Python для поддержки анимации).
48
Имеется в виду модель автомобиля «Chevrolet Camaro», пользующаяся славой надежного и неприхотливого автомобиля. - Прим. перев.
49
Названия всех крупных примеров этой книги начинаются с приставки «Py». Это - соглашение, принятое в мире Python. Если покопаться на сайте http://www.python.org, можно найти другое свободно распространяемое программное обеспечение, следующее этой схеме именования: PyOpenGL (интерфейс к графической библиотеке OpenGL для языка Python), PyGame (набор инструментов для разработки игровых программ на языке Python) и многие другие. Я не знаю, с кого это началось, но эта схема оказалась достаточно «Пи-кантным» способом рекламы языка программирования для всего мира программного обеспечения с открытыми исходными текстами. Если Питонист слишком прямолинеен - это не Питонист!
50
Интересно отметить, что даже текстовый редактор IDLE в Python 3.1 страдает от тех же двух ошибок, описываемых здесь и ликвидированных в текущей версии PyEdit, - IDLE в версии 3.1 вставляет содержимое файла при открытии начиная со второй строки, а его операция поиска во внешних файлах (напоминающая диалог Grep в PyEdit) вызывает крах в результате ошибки декодирования при просмотре стандартной библиотеки Python, что вызывает аварийное завершение IDLE. Здесь вполне уместно вспомнить поговорку про сапожника без сапог...
51
Здесь игра слов: имя метода pack_forget дословно означает «забыть, что был скомпонован». - Прим. перев.
52
Чтобы не выставлять программистов в невыгодном свете, следует отметить, что ко мне неоднократно обращались с просьбами прочитать лекции о программировании на языке Python для физиков, которые имели более богатую математическую практику, чем я, но многие из которых благополучно злоупотребляли общими блоками и операторами GO TO языка FORTRAN. Специализация в профессиональной деятельности может всех нас в чем-то превратить в новичков.
53
В ноябре 2010 года вышла версия NumPu 1.5.1 для Python 3.1. - Прим. перев.
54
Кроме этого следует учитывать, что, в отличие от координатных осей, используемых в планиметрии, на которых значения по оси Y возрастают снизу вверх (ось направлена вверх), на холсте ось Y направлена вниз. Это приводит к тому, что для вычисления на холсте позиции по Y вычисленная для точки координата Y вычитается из начальной координаты Y, а не прибавляется к ней, как в случае со значениями по оси X. - Прим. ред.
55
После прибавления значения вычисленной координаты по X и вычитания значения по Y. - Прим. ред.
56
Например, сценарий PyDemos, представленный в предыдущей главе, запускает семь часов, выполняющихся в одном процессе, и во всех них обновление времени на моем (относительно медленном) нетбуке, работающем под управлением Windows 7, происходит плавно. Все вместе они потребляют единицы процентов мощности ЦП и нередко даже меньше, чем сама программа Диспетчер задач (Task Manager).
