Qt позволяет разрабатывать приложения при помощи C++ и декларативного языка программирования QML, поддерживает все основные десктопные и мобильные платформы, а также некоторые встраиваемые и имеет открытый исходный код. Существует коммерческая версия Qt, содержащая дополнительные проприетарные модули.
По сравнению с предыдущей версией, в 5.5 было внесено около 1500 исправлений и добавлен новый функционал. За подробностями прошу под кат.
Изменения в поддержке платформ
- Добавлена поддержка Windows 10.
- Версия для Linux теперь собирается с поддержкой RHEL 6.
- Для MacOS X и iOS добавлен SSL-бекенд на основе Secure Transport, который станет по уполчанию в Qt 5.6.
- Для Windows теперь собирается один набор библиотек, умеющий использовать OpenGL и ANGLE (реализация OpenGL средствами DirectX).
- Добавлена поддержка GStreamer 1.0 (по умолчанию пока используется 0.10).
Новый функционал
- Полноценная поддержка Bluetooth и Bluetooth Low Energy для платформ Android, iOS, Linux (BlueZ 4.x/5.x) и OS X.
- Новый модуль Qt Canvas 3D, позволяющий использовать код, написанный для WebGL в QtQuick.
- Предварительная версия модуля Qt 3D — высокоуровневого API для работы с 3D-графикой, доступного как в C++ так и в QML. Ролик в начале статьи показывает новую версию демо Cinematic Experience, выполненную при помощи Qt 3D. Еще одно демо с использованием Qt Canvas 3D и Qt 3D:
- Новый модуль для геолокации и работы с картами Qt Location. В настоящий момент поддерживаются карты из Nokia Here, Mapbox и Openstreetmap.
- В QML добавлена поддержка типизированных массивов JavaScript и значимых типов (value type) из C++.
- Открыт код компонентов для QtQuick из ранее проприетарного модуля Enterprise Controls — компоненты теперь доступны как QtQuick.Extras. Также в QtQuick.Controls добавлен TreeView.
- Добавлен новый фреймворк для видеофильтров, позволяющий осуществить обработку видео в реальном времени. Например, можно выполнять обработку видео помощи OpenCL/CUDA, а также использовать OpenCV для распознавания образов. Демо, использующее OpenCV для распознавания дорожных знаков на видео:
. - Движок Chromium в Qt WebEngine обновлен до версии 40. Добавлены API для управления загрузкой файлов, кэшем, куками и настройками. Добавлена поддержка Qt WebChannel.
Изменения в структуре продуктов
Помимо версии с открытым кодом, теперь будет доступно две коммерческих версии:
- Qt for Application Development — для разработки приложений;
- Qt for Device Creation — для встраиваемых устройств.
Устаревшие модули
Объявлены устаревшими Qt WebKit, Qt Quick 1 и Qt Script. Все они доступны в Qt 5.5, но настоятельно рекомендуется перейти на более нове альтернативы: Qt WebView и QML.
Дополнительная информация
Комментарии (37)
VioletGiraffe
02.07.2015 08:13+1Поддержка Qt не внушает оптимизма. Мой серьёзный, но редкий баг на Mac OS уже 8 месяцев не чинят. Приходится собирать Мак-версию моего приложения с древней Qt 4.
oYASo
02.07.2015 09:26+4Тут вопрос — какая поддержка? Если платная, то печаль, а если Community, то ее как бы и нет же. Если кто-то захочет, то поправит, ну или поправьте сами.
midday
02.07.2015 10:37А можно ссылку на багрепорт? Ато ваши слова выглядят как некий очень «важный баг», исправление которого нужно только вам. Вы же ни рубля небось не заплатили за продукт. Если баг так важен для вас, то спокойно исправляйте и реквестируйте коммит, помогите другим. Qt довольно легко поддается исправлениям вручную =) все исходники довольно прозрачны и легко читаются.
VioletGiraffe
02.07.2015 10:48+1Я же сказал — редкий баг. Мне на форуме так и ответили: «Нам неинтересно его исправлять, мало голосов под репортом» (11 голосов уже, сколько же им нужно?). Насчёт легко читающихся исходников — хорошая шутка.
https://bugreports.qt.io/browse/QTBUG-43299
midday
04.07.2015 16:06Проголосовал тоже. Будем ждать исправления. Сталкивался с этим багом.
Вообще хороший был бы вариант, если подсадить на Qt какую-нибудь «взрослую» контору, которая бы была заинтересованно в развитии Qt и сталкивалась с багами на своем производстве. Но пока я не вижу такого и врятли это будет.VioletGiraffe
04.07.2015 16:18Спасибо.
Моя контора вполне взрослая, просто оочень маленькая :)
Мой друг работает в существенно более взрослой немецкой аутсорсинговой конторе с офисами по всей Европе, тоже используют Qt в некоторых проектах.midday
04.07.2015 17:06Ну надеюсь она вырастит такой большой =), что сможет либо выделять человекочасы на исправление багов в самом Qt либо проталкивать тикеты с помощью денег.
0xd34df00d
02.07.2015 13:02+6Когда я во времена 4.8.5, кажется, починил в QtMultimedia зависание при получении списка устройств при незапущенном PulseAudio и спросил на #qt, что мне теперь с этим патчем делать, мне дали сссылку на какой-то гайд по работе с их процессом принятия коммитов, где я должен выкачать все сорсы Qt (что для меня тогда было проблематично), но приободрили, что Qt 4 уже и не очень разрабатывается, поэтому мой патч скорее всего не примут.
Энтузиазм поутих, извините.
iroln
02.07.2015 13:16Qt довольно легко поддается исправлениям вручную =) все исходники довольно прозрачны и легко читаются.
И что с того, если патч всё равно не примут или надо будет приложить очень серьёзные усилия, чтобы его приняли? Я когда-то делал багрепорт и патч для QGraphicsView Framework в 4 ветке, ну и никто баг так и не исправил. Держать и поддерживать свои локальные сборки со своими патчами? Мне такой подход не кажется правильным.
BlackRaven86 Автор
02.07.2015 13:33+1Если он исправляет баг и с ним нет никаких проблем, то почему же не примут? Мои патчи, по большей части, принимали.
Тут есть другой момент, что надо разобраться, как в Qt эти патчи слать, как работать с gerrit и т.п. Ну а в каких крупных проектах не так?midday
03.07.2015 14:48+1Если и бывают такие проекты, где это не так, то заканчивается это все плачевно.
А еще же нужно прогнать тесты, может даже дописать тесты. Людям просто лень все это читать, разбираться и т.п. Одного не пойму, за что меня заминусовали, вроде все правильно сказал.BlackRaven86 Автор
03.07.2015 15:13Так и есть. Самому бывает очень лень, когда отправляешь свой код, а тебе в ответ: «Все классно, но вот тесты бы еще...» :)
crackedmind
02.07.2015 09:35> Объявлены устаревшими Qt WebKit, Qt Quick 1 и Qt Script.
Дак и какая альтернатива Qt Script?
EuroElessar
02.07.2015 10:48+2QtQml, несмотря на название он не зависит от QtGui и в нем есть QJSEngine, который уже частично догнал по возможностям QtScript.
e_asphyx
02.07.2015 09:41+2Объясните, неужели QML удобнее для создания интерфейсов, чем традиционные виджеты?
UndeadDragon
02.07.2015 09:52+3Считается да, но я годами не могу себя заставить его использовать, быстрее уже на плюсах натыкиваю.
e_asphyx
02.07.2015 10:54+1Та же фигня. Мне фактически C++ только для Qt и нужен. Я потому даже с STL особо глубоко не разбирался, в Qt всё равно всё своё.
Renzo
02.07.2015 10:05Долгое время использовал виджеты и вот недавно все-таки взялся за QML и начал писать интерфейсы на нем. Нет, он не удобнее, чем виджеты. Но результат при этом отличается на порядок — на QML можно сделать в несколько строк такие анимации, которые на Qt/C++ займут тонны кода
tangro
02.07.2015 10:28Значительно короче путь от «чистого листа» до «о, вот у меня уже по клику на кнопке из интернета загружается картинка и результат REST-запроса». Это привлекает новичков. При этом написание действительно сложного приложения рано или поздно приводит к граблям, которые на виджетах решить было бы проще.
tzlom
02.07.2015 10:46+1Смотря какие интерфейсы, анимации и сложные компоновки — гораздо легче. Если хорошо знаете как готовить MVC в Qt то всё становится вообще хорошо, если плохо — увы и ах, на чистых плюсах вам будет проще. QML гораздо проще для людей далёких от программирования. Но следует понимать что это отдельный язык и другая парадигма, если строить логику интерфейса как вы делаете это на С++ в QML можно пройтись по граблям.
e_asphyx
02.07.2015 17:56Это тот MVC, который QAbstractItemModel? Он же чудовищен. Особенно QAbstractItemView, применимость которого фактически ограничена табличными представлениями.
tzlom
02.07.2015 20:06Приблизительно это я и имел ввиду — если вы не разобрались как оно работает и зачем там что нужно — перебрасывать данные в QML прийдётся топорными способами которые могут доставить много проблем.
Он не чудовищный, он сложный и непонятно документированный (т.е. дока то на уровне Qt но вот прочтя её пользоваться этим не научишься)
Просто для затравки — QTreeView наследует QAbstractItemView, делайте выводы на сколько хорошо вы знаете Qt MVC :)e_asphyx
02.07.2015 20:24Я изучал исходники Qt на эту тему. Мне однажды надо было сделать адресную книгу в стиле Outlook (карточки с полями). Поля — это в терминах Qt MVC столбцы, а карточки — строки. Выполнить отрисовку можно без проблем. Там были сложности с обработкой выделений. Выделения в MVC — это списки диапазонов, устроенные таким образом, что они получаются привязанными к прямоугольной сетке. Я детали забыл, к сожалению.
Riateche
03.07.2015 03:18+2Я много работал с Qt Model/View и делал на нем разные нетривиальные вещи. Чудовищным я бы его не назвал. Он достаточно сложен в понимании и требует вдумчивого чтения документации, но свою задачу — отделение представления от данных — в определенных рамках выполняет хорошо. Опять же, нужно понимать, что этот фрагмент Qt сделан не для глобальных универсальных применений Model/View, а для обеспечения возможности его применения в существующих виджетах (в том числе и табличных), предоставляемых Qt. Без этого отделить представление от данных было бы просто невозможно.
BlackRaven86 Автор
02.07.2015 15:12Зависит от того, какой интерфейс вам нужен. Если нужен классический десктопный интерфейс, чтобы выглядело «как на виджетах» и вело себя точно так же, то лучше на виджетах и писать, скорее всего :) А если требуемый вид отличается от стандартных виджетов или приложение пишется под мобильные платформы или это вообще игра — то на QML может быть сильно проще.
QtRoS
02.07.2015 17:16Пишу под мобильные платформы с использованием Qt\QML — да, легче. Притом намного. Научился получать довольно слабую связность компонентов, инкапсулировать логику в отдельные компоненты, получается неплохо)
1vertus1
03.07.2015 14:57По моему опыту, если есть красивый дизайн приложения, возможно с анимацией — конечно Qt Quick быстрее.
Если дизайна нет, и что то сам пытаешься сделать из стандартных контролов, то быстрее Qt Widgets.
0xd34df00d
02.07.2015 13:03+2А в WebEngine до сих пор нельзя управлять загрузкой внешних ресурсов с сайтов (картинок, скриптов, и так далее). Полноценный адблок не сделаешь так. Печально :(
В остальном — отличные новости, да.
evocatus
02.07.2015 23:14-4Прямо сзади от меня сидит коллега и пытается сделать GUI на Qt 5.2. Глядя на это всё действо я зарёкся связываться с этим фреймворком. Javascript который не Javascript, жутко тормознутые и большие приложения на выходе, корявые биндинги между C++ и QML, наличие альтернативного велосипеда практически для всего начиная со строк и массивов, судорожные попытки довести JS до ума и научить его хотя бы открывать файлы с диска и т.д.
По моим ощущениям у Qt 5.х плюс один — выглядит красиво. Всё остальное — один большой минус.
Wedmer
04.07.2015 06:17+1Похоже на рассуждения дорожного рабочего об инструментах ювелира.
evocatus
04.07.2015 10:27-1Конечно, раз я смею говорить о недостатках Qt я «дорожный рабочий». Он идеален, у него нет никаких проблем, на Qt надо перейти всем немедленно.
Wedmer
04.07.2015 11:34+2Просто, судя по вашему комментарию, предмет вы знаете, мягко говоря, поверхностно.
midday
04.07.2015 15:46+1Особенно порадовало «Javascript который не Javascript» =) Где это написано, что это не Javascript?
oYASo
Очень вкусный релиз, молодцы ребята. За Qt Location отдельный большой респект!