Уважаемые коллеги! В процессе ваяния небольшого GUI на tkinter (именно tkinter, поскольку он включен в windows-установку python по дефолту и гораздо проще сказать пользователю “установи питон”, чем “установи питон, а потом…”) столкнулся с проблемой. Как известно, в tkinter размеры виджетов, содержащих текст, измеряются в неких странных попугаях, именуемых “знакоместо”. Следовательно, одно знакоместо при кегле шрифта 8 совсем не то же самое, что при кегле 14. Но это ладно, собирая GUI под линуксом, я все выровнял и аккуратно подогнал кнопочки (button) к строкам ввода (entry). Но стоило запустить файлик под проклятыми форточками, как все виджеты весело разъехались как попало: entry стали длиннее, а кнопки размером в 1 знакоместо стали совсем крохотными. Упаковывал все это безобразие упаковщиком place. Буду признателен за дельный совет, каким образом сохранить неизменный вид GUI при переносе с платформы на платформу.

Потому как использовали менеджер геометрии объектов .place, который использовать никак нельзя. Точнее можно, но только для очень (ключевое слово “очень”) специфических задач. Размеры некоторых виджетов действительно задаются в знакоместах, однако их реальный размер можно все же получить и подкорректировать, если надо. Хотя это неверный путь. Лучше использовать отступы и растяжения. Заодно и к html - css подготовитесь.

Спасибо, уважаемый друг! Совет по делу и Вашу мысль по поводу place я кажется понял. К сожалению, привычка размещать элементы с точной привязкой по x и y - это тяжелый груз многолетнего “сидения” в Delphi (предвижу град камней в свой адрес - и поделом, ибо кто остановился, тот до цели уже не дойдет). Так что будем колдовать с отступами, растяжениями, может упаковщик grid поможет чем-нибудь. Еще раз спасибо!

Аналогично было. Сам оттуда. Первый проект напилил только с place. Потом для при изменении экрана проводил серьезные расчеты и переделывал размещения. Короче. Занимался всякой лабуденью. Кроме grid можно смело смотреть pack(). grid используется тогда, когда уж очень табличное размещение и множество элементов. place - для более адаптивной верстки. Но вот при его использовании чаще приходится пользоваться рамками. И одно “но”. Не забывайте, что для виджетов одного уровня можно использовать только один менеджер геометрии!!! Для разграничения менеджеров можно применять рамку (frame).

Да, это верно - в одном фрейме разные менеджеры применять нельзя, об этом многие авторы мануалов пишут. Почему-то Джон Шипман из New Mexico Computer Center в Tkinter 8.5 reference рассматривает только grid, подчеркивая, что он его “strongly prefers”. Видимо, его личное мнение. Я как раз нижний фрейм данной программулины собрал pack`ом и получилось недурственно. Буду перебирать верхний. Ваши рекомендации ценны, еще раз благодарю.

Получилось, собрал верхний фрейм pack'ом, правда пришлось добавить два под-фрейма, по одному для каждой “строки” компонентов. А для компенсации разницы между начертанием шрифтов на каждой платформе применил мощное “колдунство” sys.platform и задал добавки к width и ipadx для “форточного” случая. Конечно, есть еще платформа darwin, тоже активно пользуемая широким кругом лиц, но как это будет выглядеть там, пока одному Стиву Джобсу ведомо.

Нормально. Только вот зафиксируйте размер базового окна или подумайте как можно динамически изменять.

Точно подметили - зафиксировать. Я с самого начала так и записал:
Размер окна небольшой, даже на VGA экран поместится. Динамически изменять уметь надо, но применять не в этой программе, которая запускается не более чем на минуту для быстрой обработки указанных файлов. Более интересна сама обработка, в пакетном режиме для каждого xml-файла будет создаваться отдельный поток и произвольное количество файлов будет парситься одновременно. Успел оценить удобство функции path.walk для создания списка файлов начиная от стартового пути по всем вложенным директориям. В Делфе для подобных целей городил страшные рекурсивные конструкции. Здесь внутри самой walk тоже конечно же сидит рекурсия, но насколько же читабельнее и проще конечный код!