Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 44
Обнадеживает.
C QML не работал, но видимо что-то типа WPF XAML, с декларативной разметкой и аппаратным ускорением.
C QML не работал, но видимо что-то типа WPF XAML, с декларативной разметкой и аппаратным ускорением.
Интересно, начнется ли KDE 5 с выходом Qt 5…
Судя по обозначенным направлениям, KDE так или иначе придётся перекладывать на QML.
Не менее интересный вопрос — как принятие 0x повлияет на новые версии Qt.
В коде Qt есть макросы для использования некоторых фич из нового стандарта, если компилятор их поддерживает
Можно привести пример этих макросов и указать где можно посмотреть такой код в qt?
Например:
вот отсюда
# define Q_COMPILER_RVALUE_REFS
# define Q_COMPILER_INITIALIZER_LISTS
# define Q_COMPILER_AUTO_TYPE
# define Q_COMPILER_LAMBDAвот отсюда
KDE4 ещё далёк от совершенства (чёрт побери, Akonadi полноценно начали использовать только с 4.6!), так что о KDE5 никто ещё не думает.
С другой стороны, KDE 4.7.4 (последний багфикс-релиз в новой ветке) планируется аж на начало декабря (!), когда уже, судя по статье, планируются беты Qt 5; а судя по тенденциям, KDE 4.8 будет. Так что скорее всего дело будет как с KDE 4.0, которая базировалась толи на Qt 4.2, толи на 4.3… :)
С другой стороны, KDE 4.7.4 (последний багфикс-релиз в новой ветке) планируется аж на начало декабря (!), когда уже, судя по статье, планируются беты Qt 5; а судя по тенденциям, KDE 4.8 будет. Так что скорее всего дело будет как с KDE 4.0, которая базировалась толи на Qt 4.2, толи на 4.3… :)
> о KDE5 никто ещё не думает.
Вы явно не читаете KDE Planet: aseigo.blogspot.com/2011/05/qt5-kde5.html
Вкратце с опеннета:
Релиз KDE 5 будет иметь эволюционный характер, напоминая по своей сути переход от KDE 2 к KDE 3. По мнению Аарона, в Qt 5 ожидаются слишком большие изменения, которые не позволят без нарушения совместимости интегрировать в KDE 4 новые технологии Qt. Тем не менее, работа по переводу приложений на использование технологии декларативного описания интерфейса Qt Quick уже достаточно давно ведется в KDE. В частности, на базе подобных технологий уже развиваются проекты libplasma2 и Plasma Active.
Положительным моментом также является то, что основная часть платформы KDE базируется на собственных библиотеках и runtime-компонентах, которые не потребуется переписывать, как было сделано в случае подготовки KDE 4. Несмотря на то, что в процессе создания KDE 5 не придется проводить глобальный реинжиниринг архитектуры проекта, у разработчиков появится шанс еще раз проанализировать и оптимизировать связь всех компонентов платформы. Из подсистем, которые потребуют значительной переработки, отмечаются библиотеки для формирования пользовательского интерфейса (libkdeui) и KIO. Более подробно вопросы перехода KDE на Qt 5 будут рассмотрены на ближайшем саммите разработчиков проекта.
Вы явно не читаете KDE Planet: aseigo.blogspot.com/2011/05/qt5-kde5.html
Вкратце с опеннета:
Релиз KDE 5 будет иметь эволюционный характер, напоминая по своей сути переход от KDE 2 к KDE 3. По мнению Аарона, в Qt 5 ожидаются слишком большие изменения, которые не позволят без нарушения совместимости интегрировать в KDE 4 новые технологии Qt. Тем не менее, работа по переводу приложений на использование технологии декларативного описания интерфейса Qt Quick уже достаточно давно ведется в KDE. В частности, на базе подобных технологий уже развиваются проекты libplasma2 и Plasma Active.
Положительным моментом также является то, что основная часть платформы KDE базируется на собственных библиотеках и runtime-компонентах, которые не потребуется переписывать, как было сделано в случае подготовки KDE 4. Несмотря на то, что в процессе создания KDE 5 не придется проводить глобальный реинжиниринг архитектуры проекта, у разработчиков появится шанс еще раз проанализировать и оптимизировать связь всех компонентов платформы. Из подсистем, которые потребуют значительной переработки, отмечаются библиотеки для формирования пользовательского интерфейса (libkdeui) и KIO. Более подробно вопросы перехода KDE на Qt 5 будут рассмотрены на ближайшем саммите разработчиков проекта.
Забавно. KDE Planet я читаю, и этот пост Аарон опубликовал уже после моего сообщения (буквально через час, если верить таймстампу в моём RSS-ридере) :)
Ну а до этого про KDE 5 упоминался только вскользь — да и то, только в виде «может быть, когда-нибудь, в следующей жизни, это запилим, и это будет примерно в KDE5».
Ну, и я считаю, что это набор мыслей одного (хоть и весомого) разработчика. Хотя и он сам говорит, что «The short answer is that we don't know yet» :)
Но вы правы, о KDE5 таки думают. Но пока ничего ведь конкретного.
Ну а до этого про KDE 5 упоминался только вскользь — да и то, только в виде «может быть, когда-нибудь, в следующей жизни, это запилим, и это будет примерно в KDE5».
Ну, и я считаю, что это набор мыслей одного (хоть и весомого) разработчика. Хотя и он сам говорит, что «The short answer is that we don't know yet» :)
Но вы правы, о KDE5 таки думают. Но пока ничего ведь конкретного.
Инициатива из серии: «А давайте испортим единственный вменяемый десктопный native GUI-framework и сделаем еще один WPF».
Страшновато.
Страшновато.
Разработчики Qt пытаются/хотят идти «в ногу со временем».
И я бы сказал не «ещё один WPF», а его кросс-платформенная альтернатива.
Простите, что в этом плохого?
Всё новое всегда страшновато и это не значит, что нужно топтаться на месте.
И я бы сказал не «ещё один WPF», а его кросс-платформенная альтернатива.
Простите, что в этом плохого?
Всё новое всегда страшновато и это не значит, что нужно топтаться на месте.
Существует масса критики в адрес WPF, в качестве примера как правило вспоминают историю с клиентом Evernote.
Посмотрим, что получится у Qt.
Посмотрим, что получится у Qt.
У каждого фреймворка есть специфика, нельзя один и тот же инструмент применять во всех сферах. Для большинства десктоп-приложений WPF удобен и красив как с точки зрения разработчика, так и с точки зрения пользователя.
Опять же, насколько я помню, Evernote критиковали не столько скорость работы приложения, сколько время его запуска. Это критично в основном для приложений, стоящих в автозагрузке. Для всех остальных приложений уже давно придуманы Splashscreen.
Тем более, что Qt имеет одно преимущество. В тех узких местах, где не устраивает производительность QML — используй всю мощь C++ и QWidgets.
Опять же, насколько я помню, Evernote критиковали не столько скорость работы приложения, сколько время его запуска. Это критично в основном для приложений, стоящих в автозагрузке. Для всех остальных приложений уже давно придуманы Splashscreen.
Тем более, что Qt имеет одно преимущество. В тех узких местах, где не устраивает производительность QML — используй всю мощь C++ и QWidgets.
А что за история с Evernote? Я не в курсе :) Интересно.
Учитывая, что «Separate all QWidget related functionality into its own library», все-таки оставят старый способ. Вопрос нативности внешнего вида при отрисовке новым способом(QWidgets will be layered on top of the scene graph (not the scene graph on top of QWidgets as is currently done with Qt 4) остается открытым.
Качество 2D отрисовки OpenGL/DirectX заметно хуже программной. Особенно это заметно на шрифтах.
Не очень понятно как они собираются с этим боротся, или же они надеются что к моменту релиза все мониторы будут с разрешением 200-300 dpi.
Не очень понятно как они собираются с этим боротся, или же они надеются что к моменту релиза все мониторы будут с разрешением 200-300 dpi.
Да, только теперь это будет не true way.
На моём «атомном» нетбуке с NVIDIA ION2, начиная с версии Qt 4.7.2, QML начал подтормаживать на анимациях, хотя версия 4.7.1 работает на ура. Ну а вообще для графического интерфейса и интерпретация неплохо работает. В любом ведь случае за qml-компонентами фактически стоят С++-классы. Когда Qt Quick ещё был в beta-стадии, я уже под Symbian его пытался юзать, и ничего не тормозило.
Кстати, согласен. Не знаю как другим, мне-таки немного неприятен код на QML. Во всяком случае сейчас. Когда смотришь на код где только C++ становится приятно. Может я просто мало работал с QML, Но вот ассоциации закрепились.
Тоже пишу формочки на QWidget
Кстати посмотреть как собирать Qt, чтобы писать под одноплатники можно тут https://habr.com/ru/post/549886/
интерпретатор в QtQuick'е довольно реактивный, но у вас же не вся логика приложения находится в гуе?) и наиболее затратная часть по процессорному времени — отрисовка, полностью возложенна на C++, так что потерь в скорости почти нет, по крайней мере они незаметны обычным пользователям
Интересно увидеть HTML5 в качестве еще одной платформы.
Сколько времени удивляюсь зачем они привязались к JavaScript? Есть QT-шные бинды и под Java и под Python, но тянут JavaScript…
потому что уже давненько QtScript входит в состав Qt, а раз он туда входит — то почему бы не заюзать?
при этом стоит заметить, что QtScript не тянет за собой внешние зависимости, как это делали бы биндинги для Java/Python/Ruby/etc.
далее, QtScript базируется на JavaScript движке WebKit, который тоже с версии Qt 4.5 входит в состав платформы, так что все логично и предсказуемо — новое решение (QtQuick) базируется на ранее созданных (QtScript)
при этом стоит заметить, что QtScript не тянет за собой внешние зависимости, как это делали бы биндинги для Java/Python/Ruby/etc.
далее, QtScript базируется на JavaScript движке WebKit, который тоже с версии Qt 4.5 входит в состав платформы, так что все логично и предсказуемо — новое решение (QtQuick) базируется на ранее созданных (QtScript)
Зачем человеку, который писал все время на С++ переходить на JavaScript, несмотря на его бурное развитие? Как писали выше это уже будет не «true way». Таким образом привлекаем web developers, но отпугиваем старых приверженцев.
Лично я, не вижу четких причинно-следственных связей почему выбрали развитие именно в этом направлении, сам я писал еще на первых версиях QT, а потом сразу под Symbian, переход к QML как концепции c декларативным описанием порадовал(хотя есть же XAML как в WP7, XML как в Android).Несмотря на это остался приверженцем С++.
Создается ощущение, что больше контролируешь процесс и можешь допилить функционал именно как тебе надо.Еще одна надстройка скрывает зависимости.
Лично я, не вижу четких причинно-следственных связей почему выбрали развитие именно в этом направлении, сам я писал еще на первых версиях QT, а потом сразу под Symbian, переход к QML как концепции c декларативным описанием порадовал(хотя есть же XAML как в WP7, XML как в Android).Несмотря на это остался приверженцем С++.
Создается ощущение, что больше контролируешь процесс и можешь допилить функционал именно как тебе надо.Еще одна надстройка скрывает зависимости.
Так никто же Вам не запрещает использовать С++. Пользуйтесь на здоровье. Я вот тоже ярый адепт С++ (что видно хотя бы по моей аватарке), но QML мне понравился, в частности тем, что он отлично расширяется из С++.
тогда, к слову, мне непонятно притягивание сюда биндингов для Java/Python — зачем они C++ программисту?
Qt Markup Language — это лишь способ задания интерфейса, по аналогии с уже существующими *.ui файлами, никто не заставляет вас реализовывать в ней логику — это преподносится как «плюшка», никто не заставляет вас описывать интерфейс именно на QML — все классы, или почти все, доступны через C++ API и являются банальными наследниками уже известного QGraphicsObject — пользуйтесь на здоровье.
По сути использование QML должно сводиться к описанию самого интерфейса (где и как должны распологаться кнопки/поля) в QML — что можно сделать и через QtDesigner, и описанию логики приложения в C++, что совершенно никак не противоречит современному положению дел с описанием интерфейсов через *.ui файлы
P.S. «QT» — это «QuickTime», мб вы имели в виду все таки «Qt», которое не является аббривиатурой?
Qt Markup Language — это лишь способ задания интерфейса, по аналогии с уже существующими *.ui файлами, никто не заставляет вас реализовывать в ней логику — это преподносится как «плюшка», никто не заставляет вас описывать интерфейс именно на QML — все классы, или почти все, доступны через C++ API и являются банальными наследниками уже известного QGraphicsObject — пользуйтесь на здоровье.
По сути использование QML должно сводиться к описанию самого интерфейса (где и как должны распологаться кнопки/поля) в QML — что можно сделать и через QtDesigner, и описанию логики приложения в C++, что совершенно никак не противоречит современному положению дел с описанием интерфейсов через *.ui файлы
P.S. «QT» — это «QuickTime», мб вы имели в виду все таки «Qt», которое не является аббривиатурой?
Я прекрасно понимаю, что такое декларативные языки и в частности QML. Вопрос в том, зачем логику реализовывать в файле описания? Это может стать камнем преткновения, особенно для начинающих программистов.
Опять же, в оригинале текста, четко прослеживается мысль, что это не «плюшка», это настоятельная рекомендация к действию.
Биндинги я привел потому, что на мой взгляд, такой поддержкой JavaScript пытаются привлечь разработчиков из среды web development.Сделайте бинды для JavaScript и не внедряйте его внутрь, кто захочет тот разберется как использовать, а то так можно намешать много чего.
P.S: Да, я знаю различия между «QT» и «Qt».
Опять же, в оригинале текста, четко прослеживается мысль, что это не «плюшка», это настоятельная рекомендация к действию.
Биндинги я привел потому, что на мой взгляд, такой поддержкой JavaScript пытаются привлечь разработчиков из среды web development.Сделайте бинды для JavaScript и не внедряйте его внутрь, кто захочет тот разберется как использовать, а то так можно намешать много чего.
P.S: Да, я знаю различия между «QT» и «Qt».
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Мысли по поводу Qt 5