LINUX.ORG.RU
ФорумTalks

[Qt][QML]радость-тред

 ,


0

2

На днях наконец-то добрался до докуменатции по Qt/QML. Пришлось потратить несколько часов, чтоб разобратся в основных понятиях, но я совсем не жалею об этом.

Естественно, что по хорошему поиспользовать я его еще не успел, но вот мои первые впечатления.

Что мне понравилось:
1. Простой синтаксис.
2. Никаких проблем с выделением памяти.
3. Неполхая поддержка всяких выравниваний и расположений виджетов.
4. Достаточное количество настраиваемых свойств для объектов, что позволяет строить оригинальный интерфейс не тратя на его разработку много времени.
5. Должен понравится дизайнерам, а это значит, что всяких «свистящих и пердящих» интрфесов станте больше, что не может не обрадовать хомячков.
6. Никакого С++.
7. Все созданные элементы интерфейса с легкостью добавляются в С++ приложение.

Возможно, что кто-то уже успел поработать с QML более плотно и сможет рассказать о его недостатках, которые я пока что проворонил.

P.S.
-Что сказать то хотел?
-Да ничего не хотел, чужое отношения к этому хотел послушать. Можно даже подискутировать.

P.P.S Модераторы, если не понравится, что это в Talks, перенесите, пожалуйста в Development

★★★★★

P.S. -Что сказать то хотел? -Да ничего не хотел, чужое отношения к этому хотел послушать. Можно даже подискутировать.

Надо было это не в P.S. а в Q&A писать. И так с каждым постом/новостью на ЛОРе отныне =)

NoMad ★★
()
Ответ на: комментарий от Deleted

> Зато жабаскрипт.
Словно что-то плохое.

Еще к плюсам QML можно отнести простоту расширения его собственными компонентами, в том числе и реализованными на C++.

rival ★★
()
Ответ на: комментарий от Deleted

Не так уж это и плохо (правда у меня уже есть некоторый опат работы с JS). В реальности же получается значительно меньше кода.
Да и используется этот JS только в очень небольших метах для описания поведения компонента.

trex6 ★★★★★
() автор топика
Ответ на: комментарий от trex6

Да пока в состоянии прототипа. :)
Немного негибко с графикой, но это или еще тупим или просто глаза замылены.

zJes ★★
()

Давно читал про него, все хотел попробовать, да руки не доходили. На днях в обновленном креаторе увидел наконец строки про прокты на нем, обязательно потрогаю.

Zhbert ★★★★★
()

НУ и попутно вопрос - может кто кинется примером QML приложения, код там заценить, посмотреть его вживую, прежде чем начать изучать.

Zhbert ★★★★★
()

если я клепаю интерефейс мышью в QCreator и юзаю все аля ui->treeView,
мне трудно будет перенести приложение на сабж?

VladimirMalyk ★★★★★
()
Ответ на: комментарий от rival

Плохое, ибо нужно ещё и это слаботипизированное чудище тащить :}

Deleted
()
Ответ на: комментарий от LucidFox

>И чем этот недо-JavaScript лучше PyQt4?

PyQt4 ЕМНИП то де самое, что и просто Qt, но на пистоне, а кумл что-то типа трехмерной ерунды и каких-то там перделок. В общем, разница между ними как между велосипедом и самолетом.

Zhbert ★★★★★
()
Ответ на: комментарий от trex6

Стоит ли оно лишних зависимостей? Хотя если это позволит перетыкать морды без перекомпиляции…

Deleted
()
Ответ на: комментарий от LucidFox

> И чем этот недо-JavaScript лучше PyQt4?

Тем, что он декларативный?

Manhunt ★★★★★
()
Ответ на: комментарий от VladimirMalyk

Гуй придется заново делать. Никаких конвертеров нет, насколько я знаю. Было вроде что-то вроде Gimp -> QML, но это вряд ли тебе поможет.

rival ★★
()
Ответ на: комментарий от LucidFox

К сожалению с питоном (а соответственно и с PyQt) не знаком.

trex6 ★★★★★
() автор топика
Ответ на: комментарий от Deleted

Да, позволит. На лету, правда, еще не пробовал, но при перезапуске все срабатывает. Это тоже заметный плюсь технологии для создания приложений, поддерживающих т.н. «скины».

trex6 ★★★★★
() автор топика
Ответ на: комментарий от VladimirMalyk

Гуй придется писать самому (или писать свой конвертер, но это не так просто, в QML многих компонентов, которые бы соответствовали виджетам, просто нет).

Вообще зависит от того, почему был выбран способ построения интерфейсов на UI. Если для избавления от сложности С++ кода - тогда да, поможет.
Если просто неудобно интерфейсы описывать и нужен именно WYSIWYG, тогда не поможет.

trex6 ★★★★★
() автор топика
Ответ на: комментарий от rival

конвертер и не нужен. нужно чтобы напр существующие модели и селекторы без лишнего геморроя вкатывались в гуй на QML

VladimirMalyk ★★★★★
()
Ответ на: комментарий от trex6

Ну, я как раз о перезапуске. В принципе, даже может быть удобным. Стоит, пожалуй, поковыряться.

Deleted
()
Ответ на: комментарий от trex6

UI облегчает поддержку кода и способствует внятному разделению представления и логики.
собственно, я бы ругал тех, кто не пользует UI когда его возможностей вполне хватает.

VladimirMalyk ★★★★★
()

> Возможно, что кто-то уже успел поработать с QML более плотно и сможет рассказать о его недостатках, которые я пока что проворонил.

На здоровье:

Тормозит при загрузке пропорционально размеру QML-кода, который загружается целиком со всеми зависимостями. Если объём кода вырос до сотен килобайт (что вполне нормально для среднего проекта), то GUI-процесс зависнет на несколько секунд при старте. Если это какой-нибудь мелкий плазмоид, то инициализация JavaScript-движка и разбор QML может, мягко говоря, раздражать подвисаниями при открытии.

Жрёт как не в себя и фрагментирует память как дуршлаг. При сложных сценах огромный оверхед на биндинги между элементами.

Куча хардкода, включая прибивание координат элементов абсолютными значениями. Видимо рассчитано было, что эти значения относительные, к которым нужно применять трансформации, чтобы растянуть окно под нужный размер.

Отсутствие лейоутов как таковых (привет, каменный век), всё приходится хардкодить руками. Row, Column и склеивание элементов друг за другом жалкое подобие функционала на основе QLayout.

Повсеместная векторная графика, превращающаяся в дикие тормоза при более-менее нагруженном интерфейсе, развёрнутом на большой полный экран 1920x1200.

Интеграция с интерфейсом, основанным на QWidget слабенькая. В частности, QML-код не реагирует на потерю фокуса, хочется верить, что это просто ошибки, которые в ближайшее время исправят.

Ну и, конечно же, отсутствие множества стандартных всеми любимых элементов, таких как банальное поле ввода, которые хочется модифицировать под свои нужды. Практически на любой чих приходится или а) наследовать уже готовый контрол, чтобы его доработать (при этом увеличение QML-кода неуклонно ведёт к тормозам и откусыванию памяти), или б) форкать контрол на C++ из private-классов Qt, негативные последствия чего, я думаю, рассказывать не нужно.

Вобщем, QML — хорошая штука, но применять его стоит дозированно и исключительно там, где это нужно. Фанатизм а-ля «переписать всё на QML» может привести к печальным результатам.

Dendy ★★★★★
()

Возможно, что кто-то уже успел поработать с QML более плотно и сможет рассказать о его недостатках, которые я пока что проворонил.

Сделай мне копипаст в элементе text... Или сделай мне хождение по ссылкам в элементе textedit. Сделай мне отображение в виде дерева, сделай мне таблицу а не grin. На самом деле, вот таких мелочей там пока хватает. Ждем Qt Quick 1.2

Gorthauer ★★★★★
()
Ответ на: комментарий от VladimirMalyk

конвертер и не нужен. нужно чтобы напр существующие модели и селекторы без лишнего геморроя вкатывались в гуй на QML

QAbstractItemModel просто так без каких-либо вообще телодвижений прокидывается в qml. Сложности лишь в деревьях будут, их пока не реализовали, но списки на ура закидываются. Причем у класса можно все слоты из qml'я дергать и коннектится на сигналы класса.

Gorthauer ★★★★★
()
Ответ на: комментарий от Dendy

> Отсутствие лейоутов как таковых (привет, каменный век), всё приходится хардкодить руками.

Ужас, почему мы, как дураки, используем вложенность элементов с анчерами?

zJes ★★
()
Ответ на: комментарий от Dendy

>Тормозит и жрет
Очень жаль, надеюсь в будушем поправят. Что-то слышал о том, что туда какой-то новый движек для JS собирались прикрутить. Это уже с ним или без него?

Куча хардкода, включая прибивание координат элементов абсолютными значениями. Видимо рассчитано было, что эти значения относительные, к которым нужно применять трансформации, чтобы растянуть окно под нужный размер.

Отсутствие лейоутов как таковых (привет, каменный век), всё приходится хардкодить руками. Row, Column и склеивание элементов друг за другом жалкое подобие функционала на основе QLayout.


Думал, что склеиванием компонентов можно будет поправить и дергать только изменения размера основоного элемента в resizeEvent у виджета, который это все отображает.

Компоненты, думаю, со временем появятся в избытке, но вот насоклько они будут хороши...

В любом случае, спасибо за подробный и развернутый комментарий.

trex6 ★★★★★
() автор топика
Ответ на: комментарий от zJes

> Ужас, почему мы, как дураки, используем вложенность элементов с анчерами?

Якоря достаточно просты, они позволяют только приклеить один элемент к другому. Вот, к примеру, простая задачка: 3 элемента в ряд, один фиксированной (но заранее неизвестной) ширины, а два других должны делить оставшееся пространство поровну. Как это сделать на QML?

Dendy ★★★★★
()
Ответ на: комментарий от zJes

> анчерами
Всегда думал, что читается «анкор», но вообще да, согласен. По-моему, Денди просто не осилил QML'ные «layoutы».

rival ★★
()
Ответ на: комментарий от trex6

> Что-то слышал о том, что туда какой-то новый движек для JS собирались прикрутить. Это уже с ним или без него?

Всё что я описал проявляется на родном Qt 4.7.1. Новый JS-движёк и JIT были бы очень кстати. Я сказал «очень»? Были бы нереально очень кстати.

Dendy ★★★★★
()
Ответ на: комментарий от rival

По-моему, Денди просто не осилил QML'ные «layoutы».

Вполне возможно и так. Прямо над вашим комментарием лежит тривиальная задачка, если можно — приведите ваш вариант её реализации на QML.

Кстати, я написал отдельный набор QML-элементов на C++, которые используют под капотом родной движок на QLayout'ах со всем его функционалом. Решение на нём будет выглядеть примерно так:

MyHorizontalLayout {
    spacing: 8

    MyItem {
        fixedWidth: 40
    }

    MyItem {
        horizontalSizePolicy: "expanding"
    }

    MyItem {
        horizontalSizePolicy: "expanding"
    }
}
Dendy ★★★★★
()
Ответ на: комментарий от Dendy

Вот, к примеру, простая задачка: 3 элемента в ряд, один фиксированной (но заранее неизвестной) ширины, а два других должны делить оставшееся пространство поровну. Как это сделать на QML?

import QtQuick 1.0

Item {
    id: item
    width: 200; height: 200

    Row {
        id: xrow
        property int xwidth: 40

        height: 100
        width: 200

        spacing: 0
        Rectangle { color: "red"; width: (parent.width - parent.xwidth) / 2; height: parent.height }
        Rectangle { color: "green"; width: parent.xwidth; height: parent.height }
        Rectangle { color: "blue"; width: (parent.width - parent.xwidth) / 2; height: parent.height }
    }

    MouseArea {
        anchors.fill: parent
        onClicked: xrow.xwidth = 100
   }
}

Делаю такое в первый раз, разбирался по докам после того, как прочитал твое задание.

rival ★★
()
Ответ на: комментарий от Dendy

Насколько я понял, должно быть что-то типа такого:
1-ый элемент: левый якорь к левому краю родителя, задать ширину
2-ой элемент: левый якорь к первому элементу
3-ий элемент: левый якорь ко второму элементу, правый якорь - к правому краю родителя.

Так не будет рабоать?
Если у кого-нибудь под рукой есть Qt/QML, буду благодарен за проверку в действии.

trex6 ★★★★★
() автор топика

Никакого С++.

Вот она, киллерфича, остальные по сравнению с ней малы. Wait a minute...

vertexua ★★★★★
()
Ответ на: комментарий от Dendy

Кстати, я написал отдельный набор QML-элементов на C++, которые используют под капотом родной движок на QLayout'ах со всем его функционалом.

Ну вот и здорово же. А я писал обвязку для QNAM, чтобы его можно было напрямую использовать в Qml.

rival ★★
()
Ответ на: комментарий от rival

> Делаю такое в первый раз, разбирался по докам после того, как прочитал твое задание.

А теперь сделайте, чтобы место делилось не между 2-мя, а 3-мя или 4-мя элементами. А если нужно будет добавить зазор между ними? А если одно из них будет динамически показываться и прятаться? Тогда размещение превращается в сплошную головную боль с кучей флагов, математики и возможностью выстрелить себе в ногу.

Dendy ★★★★★
()
Ответ на: комментарий от Dendy

А что насчет этого Qt Components говорят? Кстати, видел тут на qt-apps вполне себе живую реализацию нативных виджетов (точнее нативных стилей) на qml. Очень даже проникся. Можно на QStyle'ах легко и быстро нахренячить любые нативные виджеты. Короче потенциал у технологии очень и очень большой, но пока это скорее игрушка.

Gorthauer ★★★★★
()
Ответ на: комментарий от trex6

> Так не будет рабоать?

Не-а. Напишите сами пример, проверьте, попробуйте минимизировать, чтобы оставить лишь важный функционал. Потом сравните с примером, который запостил я.

Dendy ★★★★★
()
Ответ на: комментарий от Dendy

> А теперь сделайте, чтобы место делилось не между 2-мя, а 3-мя или 4-мя элементами.
2 меняется на n.

А если нужно будет добавить зазор между ними?

Уже есть spacing же, я его выставил на 0.

А если одно из них будет динамически показываться и прятаться?

Не пробовал, но наверняка есть решение.

Тогда размещение превращается в сплошную головную боль с кучей флагов, математики и возможностью выстрелить себе в ногу.

Ну, понятное дело, что придется реализовывать математику, как ее кто-то реализовал в QLayout.

rival ★★
()
Ответ на: комментарий от rival

> Ну, понятное дело, что придется реализовывать математику, как ее кто-то реализовал в QLayout.

В QLayout это сделано один раз и для всех, в своём коде достаточно задать политику размещения, остальное будет сделано автоматически.
Семейство QLayout'ов — довольно сложная штука. Вы правда думаете, что каждый новый программист сядет и напишет собственную реализацию лейоутов на QML? Этот фантастический сценарий под силу единицам, а речь идёт о реальной ситуации, которая есть какая есть — с якорями и примитивными Row, Column и Grid.

Dendy ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.