Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 28
Этих разговоров уже) Вступительных топиков — уйма, а когда дальше идешь, тогда проблемы и начинаются. Вы бы лучше поведали про использование QGraphicsView или про то, как вы структурируете свои проекты(все слоты пишете в одном классе? :) ).
Прекрасный старт!
Поведайте, пожалуйста, о деталях и тонкостях написания истинно кроссплатформенных GUI applications или там неужели в дейсвтительности всё гладко и можно не задумываться о том, что мой код будет компиляться под маком или виндами;
Поведайте, пожалуйста, о деталях и тонкостях написания истинно кроссплатформенных GUI applications или там неужели в дейсвтительности всё гладко и можно не задумываться о том, что мой код будет компиляться под маком или виндами;
Ну, в питоне нет понятия «компилиться» и это уже плюс :) а для работы всех примеров достаточно установить бинарный пакет с сайта PyQt4. Ну или можете поступить совсем по-гиковски и собрать из исходников Sip и PyQt, установив MinGW — компилятор на винду. Если вам интересно — могу рассказать об этом на следующей посиделке.
Хорошо ;-) я имел ввиду, конечно, запускаться и работать; Я имею ввиду следующее: стоит ли мне заботиться о нюансах или можно написать приложение дать ссылку на svn, из которого пользователи могут скачивать мой код, далее python main.py и всё, и это одинаково хорошо и корректно работает на известных платформах (ну или на тех, где установлен кит); или мне придётся таки делать ос-специфичные билды?; в теории проблем не должно быть, но хочется узнать у человека, который непосредственно разрабатывал, как это на практике?
ну а трансляцию в промежуточный код *.pyc можно также назвать компиляцией, хотя корректность этого утверждения под сомнением;
ну а трансляцию в промежуточный код *.pyc можно также назвать компиляцией, хотя корректность этого утверждения под сомнением;
В данном случае все, что требуется для работы простого оконного приложения — это интерпретатор питона и, собственно, PyQt4. Но приложение, написанное c использованием последних версий PyQt4, не всегда будет хорошо работать на более старых. В частности, сейчас стандартом де-факто является версия не ниже 4.5. Таким образом, можно поступить несколькими способами — например, в описании к программе давать ссылку на закачку нужной версии, собирать все в один инсталлятор (например, exe для винды, собранный чем-то потипу Inno Setup, или deb-пакет для систем наподобие Debian GNU/Linux или Ubuntu, в котором все зависимости определяются и устанавливаются автоматически), ну или использовать вещи потипу py2exe, даром что собранные им Qt-приложения отлично работают под виндой без всяких дополнительных телодвижений. В остальном нюансов для Qt практически нет, все зависит именно от программиста и переносимости написанного им Python-кода. Но, повторюсь, при установленных интерпретаторе и PyQt4 проблем ни на какой системе быть не должно.
Не надо, пожалуйста, лучше обещанную практику. Тот, кто не сможет поставить под винду питон+pyqt+qt, безнадежен, куда уж ему программировать то?
Неплохая статья, радует что код грамотно подсвечен и не слишком перегружен деталями.
Высказывания в первой части спорны. В частности вы выступаете портив 3-4 лишних генерируемых строк, забывая о том, что сам по себе PyQt содержит десятки тысяч строк на python и C++, не говоря уж о самом Qt. Но в любом случае стремление к чистоте похвально:) Не надо лишь делать столь категоричных выводов о том, что pyuic4 плохо.
По поводу того, зачем класс интерфейса наследуется от object:
Стиль кода Qt и рекомендации по стилю для Python программ очень отличаются. Вы не можете полностью отказаться от питон-стиля (т.к. он используется стандартной библиотеке), а так же не можете отказаться от стиля Qt (иначе вы потеряете связь с интерфейсом).
В серьезных программах единство кода является серьезной проблемой. Разделение кода формы и генерируемого кода для этой формы на разные классы и разные файлы позволяют изолировать визуальный Qt-код от кода программы и свести использование Qt-стиля к минимуму, сохраняя единство и целостность проекта.
Единственный минус, который вижу в статье — отсутствие выводов. Здесь, возможно, уместно добавить области использования PyQt и наоборот те случаи, когда его использование не целесообразно.
Впрочем, коли вы обозначили стиль как беседу, то это простительно, но все равно могло бы значительно улучшить полезность текста.
Высказывания в первой части спорны. В частности вы выступаете портив 3-4 лишних генерируемых строк, забывая о том, что сам по себе PyQt содержит десятки тысяч строк на python и C++, не говоря уж о самом Qt. Но в любом случае стремление к чистоте похвально:) Не надо лишь делать столь категоричных выводов о том, что pyuic4 плохо.
По поводу того, зачем класс интерфейса наследуется от object:
Стиль кода Qt и рекомендации по стилю для Python программ очень отличаются. Вы не можете полностью отказаться от питон-стиля (т.к. он используется стандартной библиотеке), а так же не можете отказаться от стиля Qt (иначе вы потеряете связь с интерфейсом).
В серьезных программах единство кода является серьезной проблемой. Разделение кода формы и генерируемого кода для этой формы на разные классы и разные файлы позволяют изолировать визуальный Qt-код от кода программы и свести использование Qt-стиля к минимуму, сохраняя единство и целостность проекта.
Единственный минус, который вижу в статье — отсутствие выводов. Здесь, возможно, уместно добавить области использования PyQt и наоборот те случаи, когда его использование не целесообразно.
Впрочем, коли вы обозначили стиль как беседу, то это простительно, но все равно могло бы значительно улучшить полезность текста.
оффтоп не совсем в тему, а для общего кругозора: www.pyside.org, Википедия,
PySide — привязка языка Python к инструментарию Qt, совместимая на уровне API с PyQt, но, в отличие от последней, доступная для свободного использования как в открытых, так и закрытых (чем чаще всего являются коммерческие) проектах, поскольку лицензирована по LGPL.
Я почему-то всегда встречаю такой код для навешивания обработчиков:
MainWindow.connect(self.btnHello, QtCore.SIGNAL('clicked()'), self.showChildWindow)
А сам использую такой код:
self.cb_scale.currentIndexChanged.connect(self.cbScaleChange)
По-моему второй способ проще, но как-будто нигде не используется?..
MainWindow.connect(self.btnHello, QtCore.SIGNAL('clicked()'), self.showChildWindow)
А сам использую такой код:
self.cb_scale.currentIndexChanged.connect(self.cbScaleChange)
По-моему второй способ проще, но как-будто нигде не используется?..
А прикручивал ui динамически. На знаю насколько это оправдано вообще в этом конкретном случае, но может быть весьма полезным для сложных приложений, где формы могут добавляться (ну типа 1С).
И потом можно же использовать метод передачи формы с Qtscript в ответе сервера — может быть очень удобно.
И потом можно же использовать метод передачи формы с Qtscript в ответе сервера — может быть очень удобно.
Сейчас пару строк со своей колокольни скажу:
Потихоньку кодю на родном для Qt языке C++ и могу сказать, что все эти PyQt PySide и так далее не слишком подходят для серьезных проектов. Это все можно применять в мелких графических утилитках, но писать на PyQt или PyGTK нечто большое и объемное это неоправданное безумие. Так как на выходе получится прожорливый монстрик. Более того скажу, что освоение C++/Qt4 не многим сложнее Питона.
Конечно мне возразят, что если писать на C++, то придется компилировать код под каждую платформу, а питонью программу можно просто запускать. Это да, но для серьезных проектов это не проблема. Также как и не проблема для маленьких проектов падение скорости даже в 1000 раз по сравнению с C++.
А те, кому нужна расширяемость приложения за счет скриптов, могут обратить внимание на обычный javascript, за счет обьектной модели, его можно легко и очень глубоко интегрировать в свое Qt приложение.
Но даже если этого мало, то скоро придет QML, который перевернёт все ваши представления о гуестроении. Фактически дни традиционных виджетов уже сочтены.
Потихоньку кодю на родном для Qt языке C++ и могу сказать, что все эти PyQt PySide и так далее не слишком подходят для серьезных проектов. Это все можно применять в мелких графических утилитках, но писать на PyQt или PyGTK нечто большое и объемное это неоправданное безумие. Так как на выходе получится прожорливый монстрик. Более того скажу, что освоение C++/Qt4 не многим сложнее Питона.
Конечно мне возразят, что если писать на C++, то придется компилировать код под каждую платформу, а питонью программу можно просто запускать. Это да, но для серьезных проектов это не проблема. Также как и не проблема для маленьких проектов падение скорости даже в 1000 раз по сравнению с C++.
А те, кому нужна расширяемость приложения за счет скриптов, могут обратить внимание на обычный javascript, за счет обьектной модели, его можно легко и очень глубоко интегрировать в свое Qt приложение.
Но даже если этого мало, то скоро придет QML, который перевернёт все ваши представления о гуестроении. Фактически дни традиционных виджетов уже сочтены.
Согласен с предыдущими ораторами, что в большинстве случаев использование форм — скорее добро чем зло. Генерируемые файлы редактировать не надо, надо вызывать их setupUi из кода с логикой приложения.
Я же возражу по поводу toUtf — вы как вообще приложение переводить потом собрались? Ведь делается это так: с использованием pylupdate4 сканируется код на предмет вызовов QtGui.QApplication.translate, параметры этих вызовов собираются в единую базу и переводятся в Qt Linguist.
Я же возражу по поводу toUtf — вы как вообще приложение переводить потом собрались? Ведь делается это так: с использованием pylupdate4 сканируется код на предмет вызовов QtGui.QApplication.translate, параметры этих вызовов собираются в единую базу и переводятся в Qt Linguist.
Я с вами согласен, но неужели вы сто процентов приложений пишете с поддержкой многоязычности? И потом, именно для того и существует функция retranslateUI — необязательно ковыряться с лингвистом, просто в случае крайней необходимости можно сделать подгрузку языкового файла из внешнего плагина, а функция уже любые строки переварит. Но если писать что-то большое и серьезное (хотя меня выше уже начали убеждать, что это почти невозможно :) ) с поддержкой кучи языков — тогда я с вами полностью согласен.
кстати для интересующихся темой — нашел на микрохабре отличную статейку по переводу в Qt с примерами на C++. Кому понадобится — переписать на питон легко, ибо фактически все одно и то же.
Если вы не собираетесь писать локализуемое приложение, то тем более непонятно зачем делать метод toUtf, то возможно проще писать так, да и работать будет явно быстрее:
Следующий вопрос — редактирование автосгенерированного файла — это неверный подход. pyuic4 как я вижу написан с таким же рассчетом, что и оригинальная утилита uic4 из Qt4 SDK, т.е. код генерируется таким образом чтобы максимально отделить бизнес логику приложения от графического интерфейса пользователя. Пример: вы захотите поменять две кнопки местами, что для этого делать? Если вы оставите файл как есть, то просто в ui форме поменяете две кнопки местами и снова сгенерируете код на питоне, логику приложения менять не придется. В вашем же случае нужно будет либо а) править код построения gui руками б) заново генерировать код из ui файла и опять же приводить его к нужному виду. А теперь представим ситуацию, что надо не просто переставить две кнопки, но и добавить еще пару причем с хитрым расположением Layout'ов… Как показывает практика ручное редактирование такого кода довольно дорогое удовольствие…
PS извиняюсь за возможные ошибки синтаксиса — я пишу все таки не на питоне, а на c++ :)
MainWindow.setWindowTitle(QString.toUtf8("ХабраОкно 2.0"))Следующий вопрос — редактирование автосгенерированного файла — это неверный подход. pyuic4 как я вижу написан с таким же рассчетом, что и оригинальная утилита uic4 из Qt4 SDK, т.е. код генерируется таким образом чтобы максимально отделить бизнес логику приложения от графического интерфейса пользователя. Пример: вы захотите поменять две кнопки местами, что для этого делать? Если вы оставите файл как есть, то просто в ui форме поменяете две кнопки местами и снова сгенерируете код на питоне, логику приложения менять не придется. В вашем же случае нужно будет либо а) править код построения gui руками б) заново генерировать код из ui файла и опять же приводить его к нужному виду. А теперь представим ситуацию, что надо не просто переставить две кнопки, но и добавить еще пару причем с хитрым расположением Layout'ов… Как показывает практика ручное редактирование такого кода довольно дорогое удовольствие…
PS извиняюсь за возможные ошибки синтаксиса — я пишу все таки не на питоне, а на c++ :)
ну я не то чтобы использую полностью ui-конвертированный код, я пишу на его основе свой (не без копипасты), однако ничего не мешает провести действия в дизайнере, опять сгенерить в кодовый файл одной командой и посмотреть, что необходимо изменить, это не так долго и неудобно, как может показаться.
А насчет QString.toUtf8() — этот метод я сам нашел буквально через час после написания топика :) Спасибо за совет, попробую. Все попробую!)
А насчет QString.toUtf8() — этот метод я сам нашел буквально через час после написания топика :) Спасибо за совет, попробую. Все попробую!)
Извиняюсь, там fromUtf8 :)
что по поводу правок ручных — у меня в проекте некоторые файлы, сгенерированные на основе ui достигают в размере до полутора тысяч строк — думается такое руками править довольно сложно, не находите?
что по поводу правок ручных — у меня в проекте некоторые файлы, сгенерированные на основе ui достигают в размере до полутора тысяч строк — думается такое руками править довольно сложно, не находите?
>ну я не то чтобы использую полностью ui-конвертированный код, я пишу на его основе свой (не без копипасты), однако ничего не мешает провести действия в дизайнере, опять сгенерить в кодовый файл одной командой и посмотреть, что необходимо изменить, это не так долго и неудобно, как может показаться.
После тысячной правки у вас мнение поменяется на противоположное, к тому же ui файлы помогают лучшей кастомизации. Для обучения может и сгодится, но для чего-то серьезного только ui файлы.
После тысячной правки у вас мнение поменяется на противоположное, к тому же ui файлы помогают лучшей кастомизации. Для обучения может и сгодится, но для чего-то серьезного только ui файлы.
Если вы не собираетесь писать локализуемое приложение, то тем более непонятно зачем делать метод toUtf, то возможно проще писать так, да и работать будет явно быстрее:
MainWindow.setWindowTitle(QString.toUtf8("ХабраОкно 2.0"))
А можно еще проще —
MainWindow.setWindowTitle(u"ХабраОкно 2.0")PyQt отлично умеет мэппить unicode в QString :-)
Не очень понял, чем вам uic не угодил. Код, который он генерит не нужно изменять. Его даже читать не нужно, это код «оживляющий» xml-представление формы, которое создается в дизайнере.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Разговариваем про PyQt4 — Посиделка первая