Решение проблемы :)

Если разделить поток отображения и поток выполнения цикла? Сам не пробовал, но интересно - жуть. Где-то читал, что так решаються некоторые проблемы потока событий. Где не помню. Какие проблемы-тоже не помню. Посему и спросил. Может есть позитивный или негативный опыт?

Если разделить поток отображения и поток выполнения цикла?

А как предлагаете обмениваться информацией между потоками?

Может есть позитивный или негативный опыт?

Нету, это моё первое весомое приложение на питоне.

А как предлагаете обмениваться информацией между потоками?

Я пока никак не предлагаю. Просто напрашивается такое решение. Возможно потоки смогут обращаться к одной переменной… Надо смотреть и пробовать. Если перенесете тему в раздел GUI или продублируете - я могу попробовать. Самому, если честно, интересно. Но Ваше решение - это явный бок (без обид :)).

P.S. Только пробовать буду завтра во второй половине дня. У меня уже пол второго ночи :)

Кстати, забыл сказать.

В этом классе я компоную Entry и Canvas'ы в самодельную таблицу.

Чем Вам листбоксы не угодили?

Если разделить поток отображения и поток выполнения цикла?

Я сейчас ещё подумал над вашим предложением. Мне кажется в моём случае это бессмысленно, т.к. единственная задача цикла - приём коротких сообщений из очереди, уведомляющих об изменениях в GUI.
Если я засуну этот цикл в отдельный поток, мне придётся создать очередь (между потоками отображения, и цикла).
А в потоке отображения нужно будет городить ещё один цикл, для постоянного приёма сообщений (другого способа я не знаю).
Получится то же самое, что у меня, только с одним дополнительным звеном.

Может быть проблема №2 (которая с использованием задержки при закрытии, в противовес проблеме №1, которую я описал в первом сообщении этого топика) вызвана тем, что у я использую два класса, отвечающие за интерфейс?
Может быть стоит перенести функцию с бесконечным циклом из класса Grid в класс Gui, но точно также поднимать флаг-переменную, когда нужно выйти из цикла? Даст ли мне это что-либо?

Чем Вам листбоксы не угодили?

У меня несколько столбцов в таблице. Не знаю, умеют ли листбоксы такое.

По проблеме №1, описанной в начале этого топика: я заметил, что та функция, с которой убивать интерфейс, имеет значение.

С root.destroy() деструктор конфига нормально срабатывает, а вот с root.quit() - нет. Помогите понять почему.

У меня несколько столбцов в таблице. Не знаю, умеют ли листбоксы такое.

Ну так соберите их из нескольких виджетов Listbox :)

По проблеме №1, описанной в начале этого топика: я заметил, что та функция, с которой убивать интерфейс, имеет значение.

Я Вам об этом написал еще во втором ответе :).

Я сейчас ещё подумал над вашим предложением. Мне кажется в моём случае это бессмысленно, т.к. единственная задача цикла - приём коротких сообщений из очереди, уведомляющих об изменениях в GUI.
Если я засуну этот цикл в отдельный поток, мне придётся создать очередь (между потоками отображения, и цикла).
А в потоке отображения нужно будет городить ещё один цикл, для постоянного приёма сообщений (другого способа я не знаю).
Получится то же самое, что у меня, только с одним дополнительным звеном.

Весомо… Первое объяснение было более размытым. Нужен код для анализа.

Может быть проблема №2 (которая с использованием задержки при закрытии, в противовес проблеме №1, которую я описал в первом сообщении этого топика) вызвана тем, что у я использую два класса, отвечающие за интерфейс?
Может быть стоит перенести функцию с бесконечным циклом из класса Grid в класс Gui, но точно также поднимать флаг-переменную, когда нужно выйти из цикла? Даст ли мне это что-либо?

Думаю вряд-ли… Мне кажется, здесь другое… Не видя кода…
P.S. Больше отвечать не буду. Перенесете тему в раздел GUI :)

Ну так соберите их из нескольких виджетов Listbox :)

А в чём преимущеста такого подхода? Строки таблицы не расползутся из-ра разной величины ячеек? Я сейчас компоную Entry и Canvas'ы с помощью .grid(), который естественным путём задаёт высоту строк, так что если вддруг одна ячейка расширится по высоте, то все остальные ячейки этой строки - тоже.

Я Вам об этом написал еще во втором ответе

Да и заметил и полез эксперементировать.

Дело в том, что у меня в программе есть минимум три потока, и кроме gui объект конфига используется ещё парой других потоков и классов. Я подумал, что может быть эти другие классы не освобождают конфиг, и поэтому не вызывается деструктор (опять же: возможно ли такое? Это нормальное поведение объектов в Python?)
Я создал один объект конфига чисто для gui, ещё один - для остальных классов и потоков, попутно обнаружил такую проблему, что лучше иметь не более одного потока на класс, иначе деструктор класса (я говорю уже про другой класс, не про Config) вызывается дважды, по разу от потока, его использующего!
В общем такой подход сработал - деструктор вызвался.
Я снова всё перевёл на единый объект config и деструктор вновь сработал. Единственное что принципиально поменялось с состоянием кода на начало создания этой темы - так это рекомендованная вами замена root.quit() на root.destroy(). Но дело в том, что я это уже пробовал, ещё до темы. И так не работало. Странно.

Ну пока ладно с этим, сейчас меня интересует проблема №2.