Python-сообщество

Возьми и позапускай его на разных DM. Это будет для тебя полезным.

Проект ещё не перешёл в стадию тестирования. Ты специально превращаешь тему в бесполезный флуд? Твои сообщения нисколько не помогают мне хотя бы приблизительно понять проблему, одни голословные утверждения.

Пройдусь по тому, что было обработано. Что не упомянуто - то голословные придирки. Печально, что в теме больше критиканства, чем обоснованной критики, которая мне и нужна. В принципе, я уже доволен полученным результатом, некоторые конструктивные моменты оказались весьма полезными для развития проекта.

использование Qt Designer нет
Видимо имелось ввиду предложение подгружать *.ui файлы. Это лишь повысит “жирность” проекта, так как всё равно в коде будет setText, setToolTip, ивенты и так далее, он не станет меньше. Если же использовать конвертер, то его код не очень хорош и его удобство сомнительно. Текущая структура кода значительно удобнее - там сразу всё понятно, комменты для быстрого поиска. А сам редактор часто бывает не нужен, потому что интерфейсы довольно просты и легко верстаются на слоях без подгонки.

наследование от QDialog нет
Не ясно для чего это предлагалось. Окна справок - не диалоги.

gettext вместо конфигов локали нет
Километровые строки прямо в коде, в два раза больше в файлах локализации, отдельный конфиг с некоторыми параметрами. Недостатки перевешивают преимущества. Особенно это касается строк со справкой - сомневаюсь, что и переводчики оценили бы фетиш на данный стандарт.

использование системы локализации самого Qt нет
Нет, потому что она ведёт себя странно, на моей системе часто не работает. Хотя возможно я что-то делаю не так.

активация / деактивация кнопок да
Это удобнее, чем сообщения в нижней строке. Небыло сделано изначально по причине лени.

более удобное перетаскивание виджетов возможно
Режим редактирования и попиксельное выравнивание через специальное меню - действительно не лучшее решение. Возможно, в будущем появятся всплывающие боковые плашки, как в виджетах KDE.

избавление от дублирования частично
Отрефакторил код и перешёл, теперь используются нужные конструкторы. От дублирования решил не избавлятся, так как была бы функция с кучей параметров и экономия строк получилась бы сомнительной, а вот удобство снизилось бы. Кроме диалоговых окон заметных проблем с дублированием обнаружено небыло.

использование модуля logging нет
Потоки stdout и stderr перенаправляются в файлы, чтобы весь выхлоп не пропадал. Поэтому туда же летят все стактрейсы. Кроме крашей и сообщений о запуске / завершении больше ничего не выводится, решено было не тащить лишний модуль, создавая лишнюю нагрузку и лишний лог файл.

декораторы для try-except нет
Идея хорошая, если бы не одно но - в некоторых местах при исключении происходит не только стак трейс. И количество таких мест иногда увеличивается. Декораторы усложнили бы процесс дописывания / переписывания кода, которое пока ещё часто случается. И усложнили бы сам код, для понимания которого пришлось бы распутывать более длинную цепочку, а так всё на виду. Ради экономии 2 строк кода - оно того не стоит, было решено не делать. Для API декораторы тоже сознательно не делались, потому что нет надобности обрабатывать события в нескольких местах, хватает обычного наследования.

вынос информации о виджете частично
Информация была вынесена в отдельный класс, а главный класс не инициализируется и не хранится если виджет не установлен на рабочий стол. Это позволяет экономить ощутимо больше ресурсов, когда установлены не все виджеты. И это удобнее опции загрузки только установленных. Правда, есть не критичные накладки из-за такой архитектуры. Хранить эту информацию в модуле не стал, так как потребовался бы более длинный валидатор и всё равно бы пришлось запихивать данные в класс, который будет хранится в словаре, поэтому лучше так, чем шаманить.

Отредактировано InterVi (Янв. 15, 2018 15:18:00)

Вот ты и сам понял что не готов воспринимать то что я тебе говорю. В этом нет ничего страшного, ты со временем сам поймёшь те вещи о которых я тебе говорил, ну если конечно выживешь.

Я не оспаривал сами подходы или стандарты, я их применяю в других программах, когда это уместно. Почему всё именно так - описал выше довольно подробно. Внятных аргументов за всю тему так и не увидел. Не можешь аргументировать - значит просто навязываешь свои личные предпочтения, направленные на код ради кода, а не код ради приемлемого выполнения задач. Не хочу продолжать этот глупый диалог, он похож на троллинг.

За это время в проекте накопились довольно значительные изменения.

• Много фиксов и рефакторинга. Работа с конфигом, локализацией, лок-файлом - были вынесены в отдельные модули.
  
• Таки появился декоратор try_except. Главной причиной послужило то, что сторонние разработчики виджетов вряд ли вообще будут ловить ошибки (а эксепшен в правильном месте валит питон с сегфолтом), пусть для них будет простой инструмент. Но я по-прежнему считаю это плохим подходом.
  
• Теперь используется модуль logging. Приложение стало выводить некоторую отладочную информацию (тоже по большей части для сторонних разработчиков), поэтому появилось надобность иметь возможность настраивать уровни логирования.
  
• Появились панельки для перетаскивания виджетов. Но они пока маленькие и убогие, над ними ещё надо работать, хотя бы с визуальной частью. Ещё хотелось бы научить их масштабированию, как в KDE.
  

InterVi
Не помню всех случаев, но если главное окно скрыто, приложение точно закроется при закрытии мессенджа.

 ...
app = QtGui.QApplication(sys.argv)
app.setQuitOnLastWindowClosed(False)  

[code python][/code]

Отредактировано PEHDOM (Фев. 19, 2018 23:44:18)

Есть пункт в контекстном меню и кнопка. И по крестику тоже. Благодарю, как всегда не дочитал документацию

по крестику оно закроет окно, но не завершит основной цикл, нужно явно вызывать QApplication.quit()

[code python][/code]

исправлено