Опубликован (http://blog.qt.io/blog/2018/06/13/qt-python-5-11-released/) первый выпуск проекта Qt for Python (https://wiki.qt.io/Qt_for_Python), в рамках которого подготовлен набор модулей для создания графических приложений на языке Python с использованием Qt5. Продукт Qt for Python основан на модуле PySide2 (http://pyside.org) и продолжает его развитие (по сути под новым именем предлагается первый выпуск PySide с поддержкой Qt 5). В отличие от PySide новый продукт призван предоставить целостное решение для использования Qt в Python-приложениях, включающие сопутствующие сервисы, такие как оказание коммерческой технической поддержки.
URL: http://blog.qt.io/blog/2018/06/13/qt-python-5-11-released/
Новость: https://www.opennet.ru/opennews/art.shtml?num=48774
Из новости непонятно внезапно Python 5 вышел? или речь идет о Qt 5.11. Подкорректируйте пожалустаЕсли по теме, то не совсем понятно зачем все это, так как переписывать старое не будут, а новое писать смысла под многотонную Qt не видно. Потом судя по всему будут постоянные проблемы с компиляцией как и у многих модулей в Python.
В целом вероятно проблема вообще в стеке нужно уже придумать модуль который в виде DLL бросил к программе и все загрузил дескрипторный файл UI в виде XML и наслаждайся себе UI и вызывай свои функции из кода.
Смысл комментировать то, чего не понимаешь? Вот и придумай, если для тебя все так просто.
посоветуйте, на чем написать кроссплатформенное гуйное приложение, если не собираюсь тратить 20 лет на изучение плюсов (не вижу смысла в плюсах, когда есть няшная сишка для низкоуровневых задач, и управляемые языки для высокоуровневых). Сейчас предо мной три варианта:1) супер-гипер-тормозной Electron, язык - JavaScript, ну вы понели (вспомнити npm leftpad);
2) супер-гипер-мега-тормозной питон с GIL и никакущей параллелизацией, в качестве тулкита Qt, который, как известно, нетороплив;
3) сопоставимая по скорости с плюсами божественная Java™, в качестве тулкита божественный GTK+ как бэкенд для не менее божественного SWT + JFace как бонус.
Смотря какой функционал, могу предложить Nuklear.
>в качестве тулкита божественный GTK+Дуплик, залогиньтесь.
Если это гуйня, то для начала определитесь, заметны ли будут на ней тормоза реализации языка и тулкита.
Electron в первую очередь довольно требователен к памяти, а что касается тормозов (я так понимаю, имеется в виду отзывчивость ui?), то здесь довольно много зависит от квалификации программиста. Если взять, например, visual studio code, то работает он достаточно шустро. Чего нельзя сказать о некоторых программах, написаных на java (Eclipse, Android Studio).
Лично я бы брал Qt (QML для описания GUI и логика на плюсах).
Ничего лучше QtQuick пока не придумали. Внутри js, можно реализовывать логику на нем, в свою очередь всегда можно воспользоваться сишкой для низкоуровневых задач. Полная свобода отрисовки чего угодно, встроенный mvc. В отличие от электрона летает крайне быстро и потребляет довольно мало ресурсов, а так же попросту более удобен.
А что будешь делать, если тебе еще и внешние библиотеки нужны? В QT есть не все.
В C++ есть всё и даже больше
Так весь смысл именно в том, чтобы C++ не использовать.
Там будет несколько десятков строк. Это такая проблема? Или не использовать C++ - это из принципа?
А какие проблемы совместно с Qt истользовать ещё и другие библиотеки?
Проблема в рекламных лозунгах,- "Смотрите, какой QtQuick офигенный. Вы можете писать логику на JS". Нет, не можете, если вам нужны внешние библиотеки. Как и сказал тред-стартер сидеть осваивать кресты, чтобы написать относительно простую гуевину для личных нужд - удовольствие ниже среднего.
Вообще то нет.
> Как и сказал тред-стартер сидеть осваивать кресты, чтобы написать относительно простую гуевину
> для личных нужд - удовольствие ниже среднего.JS тоже используют не от хорошей жизни.
По опыту заявляю что в qt есть все что нужно.
>в качестве тулкита Qt, который, как известно, нетороплив;А мне это совершенно не известно.
считай повезло. Я до знакомства с Qt-приложениями этого тоже не знал.
Может и меня просветите? Только один нюанс знаком и с Qt приложениями и Gtk и с чем только ещё не знаком.
Проблема далеко не всегда в тулките и API. Если взять винду(как пример с большим набором всякого добра и не очень) и её нативный гуи, то можно найти как тормозные поделия(которых не мало) так и работающие быстрее чем любое приложение на любом тулките и при этом состоящие не из двух кнопочек.
Увы, нет альтернатив. Либо QT, либо Electron. Низкое потребление ресурсов или скорость и удобство разработки, выбирай.
По-моему, у тебя мозг рака.
Tcl/Tk
> GTK+GTK тот еще тормоз. Если нужен производительный GUI - только QML.
Lazarus же. Ничего удобнее для быстрого создания гуйни пока не придумали.
Который в linux использует те же Qt или GTK.
> Qt, который, как известно, неторопливЕдинственное, что в Qt неторопливо - виджеты (QWidget), которые уже очень давно объявлены устаревшими, но продолжают применяться повсеместно, разработчиками, не читающими ни новости, ни даже доки. Те же виджеты, кстати, в расхваливаемом Вами GTK.
В остальным Qt - это хорошо оптимизированные либы на c++. Ничего быстрее быть не может.
В плане интерфейса, QML в Qt - стандарт. Ничего быстрее, легче и гибче QML для отрисовки интерфейсов Вы не найдете.
Кто объявил QWidgets устаревшими? Ссылку пожалуйста. QtCreator не выдает об этом предупреждений.
На форуме у них такой ответ:
> Though there's a lot of movement around QML widgets are still supported and AFAIK there are
> no official statements or plans to retire them in foreseeable future. The status of the
> module is "Done" i.e. it's maintained and tweaked but no revolutions are planned. It's
> been so from the beginnings of Qt 5 around 5 years ago.Т.е. одним словом забили они на виджеты. Использовать можно, но оптимизации, новые технологии и фишки будут только в QML.
Одним словом ты подменяешь понятия.
> Одним словом ты подменяешь понятия.Вы всех анонимов в кучу сгребли. Официально/технически виджеты deprecated не объявлены. Но! Я ниже ответил такому же выскочке - виджеты устарели морально, и вот это как раз заявляется разработчиками кьюта в каждой поднятой по ним теме.
Объявлять их deprecated, с последующим удалением, нет смысла. Они никому не мешают, и обеспечивают обратную совместимость. Но и использовать их в новых проектах так же не имеет никакого смысла.
Отвечаю "такому же выскочке". Разработчики нигде не говорят что виджеты устарели, а говорят, что это законченная (доделанная) технология. _Параллельно_ с виджетами начали развивать Qt Quick по двум причинам: нужна анимация, нужна адаптация под мобильные устройства. Анимацию сложно добавить в виджеты (нужна новая концепция программирования), поэтому решили не ломать стройную модель виджетов и сделать что-то новое. Из-за потребности в анимации вытекает потребность в аппаратном ускорении графики. Если анимация не нужна, то и аппаратное ускорение не нужно. Зачем аппаратное ускорение для кнопок? Нет ведь текстур, освещения, теней, трансформации. 20 лет назад компьютеры были в десятки раз медленнее, графические интерфейсы нормально работали без аппаратного ускорения. Так что для десктопа виджеты не устарели. Если бы устарели, их бы обязательно пометили как deprecated. Делается это не просто так, а чтобы предупредить разработчиков, которые "не читают форумы и доки" (при сборке выдается предупреждение).
Где написано, что виджеты устаревшие?
Нигде. Они морально устарели.
> посоветуйте, на чем написать кроссплатформенное гуйное приложение, если не собираюсь тратить 20 лет1) FOX toolkit
2) FLTKОбвязки есть на разных языках. API стабилен десятилетиями.
JavaFx - вполне себе неплохой вариант. имхо
у меня на JavaFx в прямом (буквальном) смысле тормозил даже скопипащенный хелловорлд. Да и контролы управления он отрисовывает с нуля, в итоге в любой ОС JavaFx-приложение будет выглядеть так, словно оно было написано в другой галактике. Вот SWT самое то: везде нативные контролы, в линуксе в качестве натива был верно подобран GTK+. Swing отметаем: копаясь в исходниках IntelliJ IDEA, я увидел тысячи самописных классов, приводящих Swing к какому-нибудь более-менее симпатичному, не слишком противоречивому в отношении целевой платформы виду.
1. У диалоговых программ нужно различать время запуска и скорость работы. Если время запуска, в общем, критично, то скорость работы уже не так.Поэтому Электрон и Ява - некошерные варианты. Хотя работают быстро, но запускаются - мама не горюй.
2. У GUI программ огромное кол-во состояний, поэтому с интерпретируемыми языками приходится жить как-то очень аккуратно. Т.е. проблема Питона не в тормозах (интерпретатор запускается быстро, всего в 10 раз медленнее bash), а в том, что он интерпретируемый => нужно писать тесты на каждый чих.
Если достаточно Gtk2, то можно перейти на "компилируемый Питон с линейным синтаксисом", т.е. Ocaml. Гибкость при разработки та же, а тестов нужно писать на порядок меньше - всю программу можно откомпилировать. Да, скорость запуска интерпретатора та же, что и у Питона.
3. Для небольших диалоговых программ классика - это Tcl/Tk. Очень просто и удобно. Проблемы те же, что и у питона.
Сишка няшнее плюсов, неторопливый Qt, божественная java это в каком мире?
Берешь Qt и спокойно пишешь интерфейс на управляемом QML, а все тяжелые вычисления выносишь на плюсы, которые по таким вычислениям не хуже сишки.
под каким именем его искать в пакетах?
Кликны по первой ссылке в новости: на их сайте есть команда для pip.
Интересно, PyKDE в дальнейшем на него перейдёт или на PyQt останется?
А зачем они выпустили это для Python 2.7?
> А зачем они выпустили это для Python 2.7?потому что 2.7 ещё много кого переживёт
Потому что ещё поддерживается.
Они бросают спасательный круг туда, где больше народа.
чугунный
Для Python 2.7 и 3.5+
Вот собрать стандартный Python (например, 3.6) + только PyQt (например, 5.10) в PyInstaller и cxFreeze - проще простого! Геморрой начинается там, где надо добавлять всякие matplotlib, numpy+mkl, scipy, sympy и т.д. Да, это минус, что нормального сборщика переносимых дистрибутивов с вменяемым размером нету. Был хорош cxFreeze, пока не выкатили 5-тую версию и поломали архивы (а то, что есть != что было, да и собирает вместо полминуты теперь 10 мин., если с тем же numpy+mkl), да удалили, по их мнению, дублирующие параметры сборки. Хоть cx_Freeze и тянул лишнее (часто приходилось удалять вручную), но зато надежно, не то, что куча геморроя с PyInstaller (например, для matplotlib надо ставить одну с девелоперских веток на GitHub). Так вот, Python + Qt очень даже хорош в разработке научного ПО. А сабж позволяет закрывать исходники, так как под LGPL, а не под GPL, как PyQt.