Прогресбар и нити в PyGTK

[spanasik]

Как только добрые люди добавят Вам достаточно кармы, можете перенести в блог PyGTK :-)

[Strange]

Как только, так сразу)

[Rajken]

вот отличная статья! Как раз тема с которой я сейчас начал разбираться.
Странно, питон вроде достаточно популярен, а вот PyGTK (в рунете) не особо. По крайней мере материалов на русском действительно очень мало.

[Strange]

Многие предпочитают wxPython или вообще PyQT, но кажется мне, с литературой там ситуация та же.

[Rajken]

wxPython не смотрел, а вот по pyQT все так-же плохо. Причем из-за этого pyGTK освоить все-таки проще.
Кстати, назрел вопрос. Использование формата GtkBuilder дает какие-то преимущества по сравнению с форматом glade или это упомянуто просто потому что пример использует формат GtkBuilder?

[Strange]

В данном случае, только потому что пример в GtkBuilder.

Хотя GtkBuilder позиционируется как замена старому libglade и новые проекты рекомендуют начинать на нем. Более широкие функциональные возможности есть, это GtkTreeView и зависимые виджеты (думаю есть еще что-то, с чем я пока не столкнулся).

[Rajken]

а вот про функциональные различия я и не знал. Буду иметь в виду теперь.
Glade мне понравился тем, как там можно описывать события. Удобно передать структуру, вместо нудного перечисления для билдера.

[Strange]

Спасибо всем за карму, перенес в PyGTK.

[mkevac]

Мммм, очень сочная статья, спасибо! С нетерпением жду завтрашнего вечера, когда начну ее читать и применять.
Я как раз пишу программу на PyGTK и мне очень нужны примеры средней сложности. В них проще вникать, чем в монстров типа gajim.

Карма +1.

[Prapor]

Спасибо!

[samurai]

На счёт расчёта процента выполнения и его изменение для диалога в нити — самый простой вариант по-моему, такой чтоб не испортить простоту примера и избавиться от «плохого тона» — передать в конструктор вместо диалога ссылку на callback-функцию, которая в качестве параметра будет принимать текущее значение прогресса и вызываться нитью. Ну а в классе граф. интерфейса соответственно такую создать — которая уже будет обновлять прогресс-бар. По крайней мере это позволит отделить мух от котлет (гуи от обработки). Или такие трюки в нитях с гуи не рекомендуются?

[Strange]

Это уже правильнее, но если две нити обработки — могу быть неточности.
1 нить берет на обработку файл, и в конце должна установить значение 15%
2 нить берет на обработку файл, и в конце должна установить значение 20%
Если вторая нить отработает быстрее (а такое вполне возможно, в зависимости от размера файла, в данном примере) — сначала установит 20%, а потом 15%.

У себя в siconverter я использую callback-функцию, которая запускает метод класса GUI, а он уже с помощью других классов высчитывает значение у устанавливает его.
Но я не ручаюсь, что это истинно верный путь :)