Ну, этот вопрос опасно близок к флагу "на основе мнения", но он также является распространенным, и я считаю, что он заслуживает хотя бы частичного ответа.
Концептуально, оба используют pyuic подход и метод uic.loadUi() одинаковы и ведут себя очень похожим образом, но с некоторыми небольшими различиями.
Чтобы лучше объяснить все это, я буду использовать документацию о с использованием Designer в качестве справочного материала .
pyuic или метод "python object"
Это, пожалуй, самый популярный метод, особенно среди начинающих. Что он делает, так это создает python объект, который используется для создания пользовательского интерфейса, и, если он используется по принципу «одиночное наследование» , он также ведет себя как «интерфейс» к самому пользовательскому интерфейсу, поскольку объект ui, который создает его экземпляр, имеет все виджеты, доступные в качестве его атрибутов: если вы создаете кнопку pu sh, она будет доступна как ui.pushButton, первая метка будет ui.label и т. д.
В первом примере документации, связанной выше, этот ui объект является автономным; это очень простой c пример (я полагаю, что он был дан просто для демонстрации его использования, поскольку он не обеспечивал бы большого взаимодействия, кроме соединений, созданных в Designer) и не очень полезен, но он очень похож на единый метод наследования: кнопка будет self.ui.pushButton, et c.
IF , используется метод "множественного наследования" , объект ui будет совпадают с подклассом виджета. В этом случае кнопка будет self.pushButton, метка self.label, et c.
Это очень важно с точки зрения python, поскольку это означает, что имена этих атрибутов будут переписать любой другой атрибут экземпляра, который будет использовать то же имя: если у вас есть функция с именем «saveFile» и вы называете кнопку «saveFile», у вас не будет никакого [прямого] доступа к этому методу экземпляра больше, как только setupUi возвращается. В этом случае может оказаться полезным использование метода одиночного наследования, но в действительности вы могли бы просто быть более осторожными с именами функций и объектов.
Наконец, если вы не знаете, что такое pyui c сгенерированный файл и для чего он нужен, вы можете использовать его для создания своей программы. Это неправильно по многим причинам, но, самое главное, потому что вы, возможно, в какой-то момент поймете, что вам нужно отредактировать свой пользовательский интерфейс, и объединение новых изменений с вашим измененным кодом - это явно PITA, с которым вы не хотите сталкиваться. .
Я недавно ответил на связанный вопрос, пытаясь объяснить, что происходит, когда setupUi() вызывается гораздо глубже.
Использование uic.loadUi
Я бы сказал, что это более «модульный» подход, в основном потому, что он гораздо более прямой: как уже указывалось в вопросе, вам не нужно постоянно обновлять файлы пользовательского интерфейса каждый раз, когда они модифицируются.
Но тут есть одна загвоздка.
Прежде всего: очевидно, что загрузка, анализ и построение пользовательского интерфейса из файла XML не так быстры, как создание пользовательского интерфейса непосредственно из кода (который это именно то, что файл pyui c делает в setupUi()).
Тогда есть по крайней мере одна относительно небольшая ошибка с полями содержимого макета: при использовании loadUi, система / форма по умолчанию поля могут быть полностью проигнорированы и установлены в 0, если явно не установлено. Об этом есть обходной путь, объясненный в Размер вертикального расположения отличается в Qt Designer и программе PyQt (благодаря eyllanes c).
Сравнение
pyuic подход
Плюсы:
это быстрее; в очень простом тесте с сотней кнопок и табличным виджетом с более чем 1200 элементами я измерил следующие показатели:
- pyui c загрузка: 33,2 мс
- loadUi загрузка: 51,8 РС
это соотношение, очевидно, не является линейным по множеству причин, но вы можете понять,
- при использовании с методом одиночного наследования он может предотвратить случайные перезаписи атрибутов экземпляра, а также означает более «сдержанную» структуру объекта
- с использованием импорта python обеспечивает более согласованную структуру проекта, особенно в процесс развертывания (наличие не python файлов является распространенным источником проблем)
- содержимое этих файлов на самом деле поучительно, особенно для начинающих
Минусы:
- вы всегда должны помнить, чтобы python файлов каждый раз регенерировалось вы обновляете пользовательский интерфейс; мы все знаем, как легко забыть такой бессмысленный шаг, как этот, особенно после нескольких часов кодирования: я видел множество ситуаций, когда люди часами стучали головами по столам (возможно, обеим) из-за неразрешимых проблем, прежде чем понять, что они просто забыли запустить pyui c или не запустили его на нужных файлах; мой лоб все еще болит; -)
- отслеживание файлов: вам нужно сосчитать два файлов для каждого пользовательского интерфейса, и вы можете забыть один из них в процессе миграции / разветвления / et c, и если вы забыли файл пользовательского интерфейса, это, возможно, означает, что вы должны воссоздать его полностью с нуля
- n00b alert : новички обычно думают, что сгенерированный файл python тот, который будет использоваться для создания своих программ, что явно неправильно; к сожалению, сообщение
# WARNING! недостаточно ясно (я почти просил об этом главного разработчика PyQt); хотя это, очевидно, не является актуальной проблемой этого подхода, сейчас это приводит к тому, что - некоторые содержимого сгенерированных файлов pyui c обычно не нужны (самое главное, имя объекта, которое используется только для определенных c случаев), и это довольно очевидно, поскольку оно генерируется автоматически («это может понадобиться, так что лучше, чем потом сожалеть»); Кроме того, в связи с вышеуказанной проблемой люди могут подумать, что все, что создает pyui c, действительно необходимо для GUI, что приводит к ненужному коду, который снижает его читаемость
loadUi Метод
Плюсы:
- это прямое и непосредственное: вы редактируете свой пользовательский интерфейс в Designer, сохраняете его (или, по крайней мере, не забываете делать это ...), и когда вы запускаете свой код, он уже там; без суеты, без суеты, и столы / лоб безопасны (r)
- отслеживание и развертывание файлов: это всего один файл на пользовательский интерфейс, вы можете поместить все эти файлы пользовательского интерфейса в отдельную папку, у вас нет делать что-то еще, и вы не рискуете что-то забыть в пути
- прямой доступ к виджетам (но это может быть достигнуто также с использованием подхода множественного наследования)
Минусы:
- проблема макета, упомянутая выше
- возможная перезапись атрибута экземпляра и отсутствие "пользовательского интерфейса" объекта "сдерживание"
- немного медленнее загрузка
- путь и развертывание: загрузка выполняется с использованием
os относительных путей и системных разделителей, поэтому, если вы поместите пользовательский интерфейс в каталог, отличный от файла py, который загружает этот .ui, вы должны будете это учитывать; Кроме того, некоторые менеджеры пакетов используют для сжатия все, что приводит к ошибкам доступа, если пути не управляются правильно
По моему мнению, если учесть, что метод loadUi обычно является лучшим выбором. Это не отвлекает меня, это позволяет лучше концептуальное разделение (которое, как правило, хорошо, а также следует шаблону, подобному MVC гораздо более близко, концептуально говоря), и я твердо верю, что это гораздо менее подвержено ошибкам программиста, для множество причин.
Но это, безусловно, вопрос выбора.
Мы должны также и всегда помнить, что, как и любой другой выбор, который мы делаем, использование файлов пользовательского интерфейса - это опция .
Есть люди, которые полностью избегают их (как есть люди, которые используют их буквально для чего-либо), но, как и все, все это и всегда зависит от контекста.